I have an enterprise application which needs to synchronise user information from the centralised source. We have been so far been integrating using LDAP with AD using a daemon process.
However, In our next deployment we need to integrate with PeopleSoft HRMS (9.1). The application needs to periodically synchronise users with the PeopleSoft HRMS.
I wanted to check how to proceed on implementing this?
Is there a standard module which would expose these details or does it allow LDAP communication?
Any direction on how to consume user records will be helpful.
Webservices can be implemented with Integration Broker: https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tibr/concept_IntroductiontoPeopleSoftIntegrationBroker-076593.html
A more low-level approach could be done with an Application Engine.
Your enterprise application could generate an XML/csv.
You would make a record in peopletools that corresponds with the fields in the XML/csv file. Then you make a fileLayout. If you drag this fileLayout into the Application Engine peoplecode window, you get a template of what your code should be and you'd have to complete it with some paths to files and minimal logic to process and import the data into your user tables.
Remember you can schedule Application Engines with reccurence, so after setting this up all you need to worry about is that the file gets updated.
If you require validation you should also look into feeding the data to a Component Interface after reading it in via Application Engine.
Related
I need some help understanding how I should architect an application. Basically it has two parts.
The web app (asp mvc): A user logs into the app, records some data and logs off. The data (login info, user recorded data) is stored locally on my server. It is very simple.
The background process: I need a service to receive and send data that is connected with this web app (from #1). I have a 3rd party server that will send user login information (in real time) to my server in which I need to use to update my local DB (this is the same DB that the web app uses for login info). Secondly, I need to run a timed interval process to query the user recorded data plus perform simple logic on it and then send the outcome to this 3rd party server. These steps are all via xml docs.
I am not exactly sure how to attack this problem. I figured I could build a separate web service to do this (it would live on the same server as the web app). Or I could run some sort of webbackgrounder (https://github.com/NuGet/WebBackgrounder) task solution that is attached to my web app. Or lastly I could create a SSIS package to do this. Which route should I go? Thank you for the advice.
I am working with an e-commerce platform, and I have a task to synchronize with some remote accounting software. The task requires syncing orders, products, inventory...etc. With large amounts of data being synced,the process can take awhile. So, I don't think asp.net application would be the best place to handle this. So, the requirements are:
To be able to schedule this process to run overnight
To be able to manually fire off this process and pass into it some variables like order numbers to export.
Possibly get back status info when fired off manually.
Has to work on .net 3.5
Issues: Can't use a windows service because the site is hosted remotely on a shared service, and the host won't allow a service.
Ideas: I'm having a really hard time finding the best way to handle this outside asp.net that fits all requirements, but I do have access to their FTP and thought possibly a console app that hosts a web-service may work, and I can put Quartz scheduler in global file to fire off service from the site.
Anyway, please offer some thoughts and experiences if you have them on which methods have worked for you.
Can't use a windows service because the site is hosted remotely on a shared service, and the host won't allow a service.
That might be a problem. Does this hosting service provide any other kind of scheduling functionality? If not then you may need to consider changing your hosting services.
You're correct in that ASP.NET is not the tool you'd use for scheduling tasks. A web application is a request/response system (and is very much at the mercy of the hosting process, IIS usually for ASP.NET). So you need some way to schedule the task to execute at regular intervals. Windows Services, Windows Task Scheduler, or some other task scheduling tool.
As for the requirement to be able to invoke the process manually, that's a simple matter of separating the invocation of the logic from the logic itself. Picture the following components:
A module which performs the logic, not bound to any UI or any way of invoking it. Basically a Class Library project (or part of one).
A Windows Service or Console Application which references the Class Library and invokes the logic.
A Web Application which references the Class Library and invokes the logic.
Once you've sorted out how to schedule the Console Application, just schedule it and it's all set. If the process returns some information then the Console Application can also perform any notifications necessary to inform people of that information.
The Web Application can then also have an interface somewhere to invoke the process manually. Since the process "can take a while" then of course you won't want the interface to wait for it to complete. This can result in timeouts and leave the system in an unknown state. Instead you'd want to return the UI to the user indicating that the process has started (or been queued) and that they will be notified with the results when it completes. There are a couple of options for this...
You can use a BackgroundWorker to actually invoke the process. When the process completes, send a notification to the user who invoked it.
You can write a record to a database table to "queue" the process and have something like a Windows Service or scheduled Console Application (same scenario as above) which regularly polls that table for queued tasks, performs the task, and sends the notification. (Of course updating the status in the table along the way so it doesn't perform it twice.)
There are pros and cons either way, it's really up to you how you'd like to proceed. Ultimately you're looking at two main things here:
Separate the logic itself from the scheduling/invocation of the logic.
Utilize a scheduling system to schedule tasks. (If your hosting provider doesn't have one, find one that does.)
We have an ASP.NET website where user adds items to database.
There are several sites on same server, each with its own database.
I need to implement a mechanism to check database for the state of each item.
If item is unprocessed, submit it to a third party web-service.
I see two options:
put the code in a webapp
put the code in a Windows service
The first option has the advantage that the code knows which database to connect to.
With Windows service, it has to be aware of all databases, so it's harder to maintain. Also, if I have only one Windows service, it will have to use threads to process items in each database in parallel.
Maybe there's another way beside these two?
What are the other issues, and what would you recommend?
Please explain your choice.
This sounds like a good place for a message queue to be involved. Each item would be wrapped into a message and placed in the queue. The "item processor" (a service?) would subscribe to the queue and perform some work using each item as it arrives. How the messages get placed on the queue is up to you, but for an example you could have each site publish the "new item" message to the queue.
Queues can be a bit of an intimidating concept at first, but frameworks such as MassTransit can help. Well worth learning.
I believe Windows Service is a good option compared to a web app, mainly because a web app would have to be triggered manually by someone, while a Windows Service can be running at all times, checking for updates.
There's another option, if you have access to each of the existing site's code. Why not write a Web Service that will submit data to your third party web service. Then in each of the existing web sites, modify the logic that stores changes in the database to also post the changes to your custom Web Service (or even skip the custom WS and call the third party directly).
I have an Access Application that is split into a back-end where the data tables are stored, and a front-end where the UI and business logic resides. I what to distribute the application without allowing the end-user to view the data tables in the back-end through the front-end.
I compile the front-end into an .accde file and disable "Display Navigation Pane" and the "Use Access Special Keys" options. Further, I have a VBA code that executes to disable these options on exit so that if the end-user enables them, then they get disabled by the code. However, if the user enables the options then kills MS Access from the task manager, then when the front-end is launched again, the user can view the Navigation Pane.
What is the best way to protect my application so that the user can only access forms and reports and not the underlying data?
Do not know whether this might be the answer you are looking for but you might consider migrating your data to MSDE/SQL Server Express. They offer user-level security on tables and queries.
If you disable the shift-key for opening the database, the user should not be able to change your settings. Note that it is possible to lock you yourself out of the db this way.
See also: MS Access Start up Properties
If proctecting your data is critical, you may need t look at a database other than Access, with Access, you can protect from accidental tampering, but really malicious tampering will get through.
I have a c# window form application (which is basically a game).
And an ASP.NET Website. the window form application has a database with a table that contains the username and his cash. The asp.net database has a table that contains the username and his cash.
Now I want to sync between to the two servers. Once I get point in my game, It'll also update the database of the asp.net site.
You could expose a web service endpoint in the web app which the Windows app can call to post updated user stats.
Likewise a web service could return updated stats to the Windows client for synchronization into the Windows app database.
As Uwe Keim mentions, the web app can only expose a service or data feed that the Windows client must poll regularly. There is no feasible way that the web app can call the Windows app directly.
Why not host the database on one location and let the game/website connect to your DB through a web service? This way you only need one database with all the relevant data compared to two. You'll have to recode some parts of your website and game but in the long run this is more optimal than two databases with the same data.
More information regarding web services can be found here.
You can develop some kind of an API (Service) in the web application and do the sync between the two apps. You are talking about two servers at the end of your post. What kind of servers are you talking about? Is the game available in standalone also? If not, can't you think of having a single DB for both of them?