Implementing PeopleSoft Integration Broker
This section provides information to consider before you begin to use PeopleSoft Integration Broker.
Planning the Integration Architecture
The two major components of PeopleSoft Integration Broker are the integration gateway and the integration engine. The integration gateway is a platform that manages the receipt and delivery of messages passed among systems through PeopleSoft Integration Broker. The integration engine is an application server process that routes messages to and from PeopleSoft applications as well as transforms the structure of messages and translates data according to specifications that you define.
When planning the integration architecture, evaluate historical integration data, current data, as well as expected growth and increased traffic. Consider the number of interfaces you have in production and how much system resources they use. Also consider how many of the interfaces will be nightly batch file loads, versus how many will be real-time service-based integrations. Devise simulated real-life integration scenarios where you can estimate the volume and the size of the transactions to a certain degree. Then use this information for benchmarking and stress testing–which should lead to performance tuning, hardware sizing, and so on.
In planning the integrations to develop and execute, consider the following:
Real-time integrations or scheduled integrations.
Determine if your business needs are best served with real-time integration or scheduled integrations.
Scheduled batch processing and file loads are discussed in other PeopleTools subjects.
Inventory the integrations to develop.
Determine the systems and applications that will participate in each integration.
Consider dependencies on other systems owned by other groups having concurrent releases, and data dependencies within the context of synchronizing data between systems. Also consider if you will need permission from business owners to integrate with their systems.
Consider if you can develop generic integrations. Perhaps in your current environment only two systems need to exchange information and they do so in a proprietary way. But consider that one day perhaps additional systems in your enterprise may also need to exchange that information with the source system. Will you need to develop transformations for systems that will be integrating later on? Can you develop the integration in a way so that other systems will be able to consume the service or subscribe to the information without requiring complex transformations?
Determine the integrations that will require synchronous messaging and those that will asynchronous messaging.
In PeopleSoft Integration Broker synchronous integrations, all processing stops until a response is received. In PeopleSoft Integration Broker asynchronous integrations, each request is placed in a queue and is processed as soon as the system can accommodate the request.
Perhaps you may need to stop the processing of fulfilling an order until the system verifies that all requested items are available in inventory. In such a case, a synchronous integration is needed.
However the processing of support tickets probably should not stop if a system uses integration to add a new ticket to a queue. In such a scenario, an asynchronous integration might be appropriate.
Prioritize integration development.
Plan to develop mission-critical integrations first, standard integrations next, and nice-to-have integrations last.
Determine if data will need transformation or translation.
Plan on using integration simulation tools.
Plan on using simulation tools such as PeopleSoft Send Master to simulate integrations with external systems that are not under your control. Even when you do control all systems that are being integrated, if you can’t get the integration to work using Send Master, you definitely won’t be able to get it working from the external system. Test integrations using Send Master before spending hours debugging a system.
Unlike a public web service on the internet that retrieves a stock quote for a given ticker symbol, the web services and integrations in your PeopleSoft applications can expose sensitive information such as financial data. PeopleSoft Integration Broker facilitates transfer of information between systems; however, a security analyst must evaluate security requirements for each individual integration.
For example, security requirements might differ when interfacing with credit card processing vendors, versus publishing salary information out of human resources, versus synchronizing business units between applications, and so on.
Perhaps certain information should be available to the public, including systems outside of your company, such as how many inventory items are available for sale. Other information might be restricted to internal employees only, internal application systems only, or perhaps only certain users of a particular application system.
PeopleSoft Integration Broker allows you to secure each individual integration to the level of security required, as well as all integration data flowing over the wire.
Planning for Support
Develop a support plan for after “go-live.” In doing so, consider the following:
Determine who in your organization will support integration development and administration.
Determine the type of error-notification and exception handling to implement to meet your support requirements. Consider that while system administrators can resolve communication failure between machines, they may not be able to resolve errors resulting from one system transmitting bad data to another. Analyst intervention may be required to correct the data. Stronger validation at point of data entry will result in fewer calls to a functional analyst to resolve integration issues.
Assessing Staff Skills
Assess the skills of the people who will perform development and administrative functions.
Developers working on the implementation of PeopleSoft Integration Broker should have familiarity, training or experience in the following PeopleSoft areas:
In addition, developers should have an understanding and research capabilities in:
Extensible Markup Language (XML).
Simple Object Access Protocol (SOAP).
Hypertext Transfer Protocol (HTTP).
Web Services Description Language (WSDL).
Web Application Description Language (WADL).
Universal Description, Discovery and Integration (UDDI) standard.
Java programming language.