Background

The OpenEAI PeopleSoft Service was originally proposed and developed by Emory University & Emory Healthcare in 2010 to expose data in PeopleSoft to Emory's enterprise service bus (ESB) integration infrastructure. This allows other Emory applications to access this data as well as authorized external applications, whose access is granted, managed, and audited using Emory's ESB infrastructure. The goal of this initiative is to provide a pattern for exposing all PeopleSoft data needed for each new integration project, both request/reply and synchronization events. Another goal is to leverage PeopleSoft application logic wherever possible. This has proven to be a realistic goal for request/reply messaging. The team working on the service also demonstrated an approach that triggers sync messages from within PeopleSoft application logic, and that approach is documented here. However, that approach has been problematic for Emory, because Emory allows a number of applications access to the PeopleSoft database. This means that Emory's primary approach for PeopleSoft sync event detection and production must look directly at the PeopleSoft database. Both approaches to sync event detection and production are documented here.

Overview

The OpenEAI PeopleSoft Service consists of two major components:

1. an ESB or Web Service that exposes PeopleSoft data to other applications using the Web Service Description Language (WSDL), and
2. internal PeopleSoft Integration Broker (IB) messages and PeopleCode to handle and produce these PeopleSoft IB messages.

Both of these components are needed to integrate well with other applications and other integration infrastructure, because most PeopleSoft IB messages are not easily produced and consumed directly by other applications or integration infrastructure. For example, most contemporary service-oriented architecture (SOA) or enterprise application integration (EAI) infrastructure expects to consume a description of a web service to generate client code to invoke that service. While PeopleSoft IB has all of the infrastructure and plumbing to consume and produce messages, even XML messages, as we use in the approach described below, it does not come with an overarching service facade with a definition and domain object model with which to build integrations. This work is all left to developers of individual integrations.

The OpenEAI PeopleSoft Service attempts to solve this set of problems once for all future data objects and operations exposed through PeopleSoft IB. It provides a standard WSDL-described web service with a domain model of all data objects exposed. Whenever new data and operations are exposed in PeopleSoft, the service definition is regenerated to include these new objects. In this way, the PeopleSoft service can be used effectively by web service clients and ESB infrastructure that is designed to build web service clients and orchestrations with standard web services. The Web Service transforms requests into an internal PeopleSoft IB message format that is more suitable for use within PeopleTools. The abstraction provided by this service also faciliates the division of labor. For example, mobile and web application developers need not know anything about PeopleSoft, IB, PeopleTools or anything else to develop application that operate on data in PeopleSoft. All they need to know is the structure of the data and the service operations, all of which are described in the WSDL of the PeopleSoft Service. On the other hand, the PeopleSoft experts don't need to know anything about SOAP, WSDL, SOA, or ESB protocols and tools. The PeopleSoft developers need only to implement a specific set of artifacts using PeopleTools to implement their piece of each integration. Figure 1 below illustrates these components and the separation of technologies and responsibilities that can be achieved using this architecture.

Figure 1. High-level PeopleSoft Service Architecture

The ESB/Web Service can run as a standalone Java application or as an ESB service or Web Service within an application service container. To date it has been run as a standalone Java application, an Apache AXIS2 web service, and as an ESB Service withing the OpenEAI Toolkit Console. It could easily be adapted and run in many other Java application contexts. The ESB/Web Service can communicate with PeopleSoft IB using either of the two methods supported by PeopleSoft IB: the Java Message Service (JMS) and HTTP.

The integration flow within PeopleSoft begins when the JMS or HTTP listening process, which runs on the PeopleSoft web server, detects a message on the message transport queue. The configuration for the listening process is managed in the Integration Gateway properties file. When a message is detected, the message is routed by the specified Routing, based on the message name, to the appropriate Handler (after any defined message aliasing has been applied). The defined Routing delivers the message to the appropriate Handler PeopleCode, which runs on the application server. The Handler PeopleCode can either issue a stored SQL statement or a series of them to query for data to populate a response object, which it returns via the JMS or HTTP process running on the Webserver. The Handler PeopleCode can also take the incoming message and issue SQL to apply the data to the PeopleSoft database. For additional assurance that business rules are applied, the Handler PeopleCode can use the incoming message to populate an existing Component Interface and apply the data to PeopleSoft. The messaging transactions that flow through this process can be logged and tracked through the Service Operations Monitor. Figure 2 illustrates these integration architecture details internal to PeopleSoft IB.

Figure 2. PeopleSoft Service Architecture: Integration Broker Components

The development work and setup on the PeopleSoft side is typically a shared responsibility. The setup of Integration Broker artifacts is often split between developer and administrator. The administrator is typically responsible for setting up the Integration Gateway properties, based on what is developed by the developer. The administrator is also the person who is responsible for verifying and maintaining the default gateway, starting and stopping the Listening processes, and setting the appropriate logging levels. The developer is typically responsible for defining the Messages, Message aliasing, defining Routing, defining Service Operations, defining the Service, and most importantly, creating the Handler PeopleCode, Component Interfaces, or Application Engines to handle the incoming request.

Quick Links

The following are links to important PeopleSoft Service artifacts:

• The current stable release source, binary, and example package
• The most recent source, binary, and examples package
• The Getting Started Guide

Part 1: The ESB/Web Service

The PeopleSoft ESB/Web Service is an OpenEAI service like any other. It can be configured to handle incoming requests, incoming synchronization messages, and publish outbound synchonization messages to ESB infrastructure or other applicaitons directly. The goal of the ESB/Web service is to provide a standard ESB/Web service interface to PeopleSoft data and allow SOA/EAI analysts to use the XML artifacts they are familiar with to define and manage PeopleSoft data exposed by the service. The steps for exposing new PeopleSoft data using the ESB/Web Service are:

1. Define the new data object to be exposed
2. Provide sample messages
3. Regenerate the PeopleSoft Message Object API
4. Configure the PeopleSoft Service message mappings to support the new object
5. If you are exposing the PeopleSoft Service as a WSDL-described web service, regenerate the web service facade

Defining a New Data Object

Defining a new data object to expose in the PeopleSoft Service is like defining any other OpenEAI service object---just add the definition of the new object to the appropriate DTDs in the PeopleSoft message definitions. For example, to expose PeopleSoft course data one would add the following to Segments.dtd and Fields.dtd. This data is what one would need to expose, for example, a course catalogue to an external application. In this specific case, Emory University expose PeopleSoft course (CLASS_TBL) objects, so that the course catalogue could be browsed and searched from within the Emory Mobile application.

<!-- CLASS_TBL added 2010/03/05 -->
<!ELEMENT CLASS_TBL (CRSE_ID, CRSE_OFFER_NBR, STRM, STRM_DESC?, STRM_DESCRSHORT?, SESSION_CODE, CLASS_SECTION, SUBJECT?, SUBJECT_DESCR?, CATALOG_NBR?, ACAD_GROUP?, ACAD_GROUP_DESCR?, ACAD_CAREER?, ACAD_CAREER_DESCR?, DESCR?, CRSE_TOPICS_DESCR?, CLASS_NBR?, ENRL_STAT?, CLASS_STAT?, START_DT?, END_DT?, CRSE_CATLG_DESCR?, CLASS_ASSOC_UNITS_MAXIMUM?, CLASS_ASSOC_UNITS_MINIMUM?, CRSE_CATLG_GRADING_BASIS?, CRSE_CATLG_SSR_COMPONENT?, CRSE_CATLG_COURSE_TITLE_LONG?, CRSE_CATLG_DESCRLONG?, CLASS_MTG_PAT*)>
<!-- CLASS_TBL_LIST added 2010/04/26 -->
<!ELEMENT CLASS_TBL_LIST (CLASS_TBL*)>
<!ELEMENT CLASS_TBL_QUERY (SearchBox?, CRSE_ID?, CRSE_OFFER_NBR?, STRM?,SESSION_CODE?,CLASS_SECTION?, SUBJECT?, SUBJECT_DESCR?, CATALOG_NBR?, ACAD_GROUP?, ACAD_CAREER?, DESCR?)>
<!-- CLASS_INSTR added 3/31/2010 for BlackboardMobile -->
<!ELEMENT CLASS_INSTR (INSTR_ASSIGN_SEQ, EMPLID?, INSTR_ROLE?, FIRST_NAME?, LAST_NAME?, MIDDLE_NAME?, NAME_PREFIX?, NAME_DISPLAY?)>
<!-- ClassMeetingPattern added 3/5/2010 for BlackboardMobile-->
<!ELEMENT CLASS_MTG_PAT (CLASS_MTG_NBR, FACILITY_ID?, BLDG_TBL_BLDG_CD?, BLDG_TBL_DESCR?, BLDG_TBL_DESCRSHORT?, FACILITY_TBL_ROOM?, FACILITY_TBL_DESCR?, FACILITY_TBL_DESCRSHORT?, LOCATION?, MEETING_TIME_START?, MEETING_TIME_END?, MON?, TUES?, WED?, THURS?, FRI?, SAT?, SUN?, CLASS_INSTR*)>

As a brief refresher, Segments.dtd is where complex objects are defined and Fields.dtd is where fields within those objects are defined. For more general details on defining service objects using the OpenEAI method see the OpenEAI Message Definition document. The fields contained in these object are:

<!-- Acad_Career added 3/5/ 2010 for BlackboardMobile -->
<!-- Acad_Career is what we mean by “school” (i.e UCOL Undergraduate Emory College) -->
<!ELEMENT  ACAD_CAREER %STRDOM; >
<!-- ACAD_CAREER_DESCR  added 4/5/2010 for BlackboardMobile-->
<!ELEMENT  ACAD_CAREER_DESCR %STRDOM;>
<!-- ACAD_GROUP  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  ACAD_GROUP %STRDOM;>
<!-- ACAD_GROUP_DESCR  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  ACAD_GROUP_DESCR %STRDOM;>
<!--  BLDG_TBL_BLDG_CD added 4/6 for BlackboardMobile -->
<!ELEMENT BLDG_TBL_BLDG_CD %STRDOM; >
<!--  BLDG_TBL_DESCR added 4/6 for BlackboardMobile -->
<!ELEMENT BLDG_TBL_DESCR %STRDOM; >
<!--  BLDG_TBL_DESCRSHORT added 4/6 for BlackboardMobile -->
<!ELEMENT BLDG_TBL_DESCRSHORT %STRDOM; >
<!-- Catalog_Nbr added 3/5/ 2010 for BlackboardMobile -->
<!-- Catalog_Nbr is part of Blackboard course name (ie the 101 in ANT 101) -->
<!ELEMENT  CATALOG_NBR %STRDOM; >
<!--  CLASS_ASSOC_UNITS_MAXIMUM added 5/21/2010 for BlackboardMobile -->
<!ELEMENT CLASS_ASSOC_UNITS_MAXIMUM %STRDOM; >
<!--  CLASS_ASSOC_UNITS_MINIMUM added 5/21/2010 for BlackboardMobile -->
<!ELEMENT CLASS_ASSOC_UNITS_MINIMUM %STRDOM; >
<!-- Class_Mtg_Nbr added 3/5/ 2010 for BlackboardMobile -->
<!-- Class_Mtg_Nbr references class meeting pattern table where you can predefine meeting patterns (ie Mon./Wed./Fri) -->
<!ELEMENT CLASS_MTG_NBR %STRDOM;>
<!-- ClassNbr added 3/5/ 2010 for BlackboardMobile -->
<!-- ClassNbr is desired for Blackboard (unique ID attached to class section) -->
<!ELEMENT CLASS_NBR %STRDOM; >
<!-- ClassSection added 3/5/ 2010 for BlackboardMobile -->
<!-- ClassSection is unique id attached to class section (ie ANT 101 section 00P)  -->
<!ELEMENT CLASS_SECTION %STRDOM; >
<!-- ClassStat added 3/5/ 2010 for BlackboardMobile -->
<!-- ClassStat is used in Blackboard (status of class, ex: Active, Closed, Cancelled) -->
<!ELEMENT CLASS_STAT %STRDOM; >
<!--  CRSE_CATLG_COURSE_TITLE_LONG added 4/6 for BlackboardMobile -->
<!ELEMENT CRSE_CATLG_COURSE_TITLE_LONG %STRDOM; >
<!--  CRSE_CATLG_DESCR added 4/6 for BlackboardMobile -->
<!ELEMENT CRSE_CATLG_DESCR %STRDOM; >
<!--  CRSE_CATLG_DESCRLONG added 4/6 for BlackboardMobile -->
<!ELEMENT CRSE_CATLG_DESCRLONG %STRDOM; >
<!--  CRSE_CATLG_GRADING_BASIS added 4/6 for BlackboardMobile -->
<!ELEMENT CRSE_CATLG_GRADING_BASIS %STRDOM; >
<!--  CRSE_CATLG_SSR_COMPONENT added 4/6 for BlackboardMobile -->
<!ELEMENT CRSE_CATLG_SSR_COMPONENT %STRDOM; >
<!-- CrseId added 3/5/2010 for BlackboardMobile -->
<!--  CrseId is a unique ID attached to Course -->
<!ELEMENT CRSE_ID %STRDOM;>
<!-- CRSE_OFFER_NBR added 2010/03/05 for CLASS_TBL -->
<!-- CRSE_OFFER_NBR xeo:desc="usually '1' but is sometimes higher (looks like cross-listing)" -->
<!ELEMENT CRSE_OFFER_NBR %STRDOM;>
<!-- CRSE_TOPICS_DESCR added 5/21/2010 for BlackboardMobile -->
<!ELEMENT CRSE_TOPICS_DESCR %STRDOM;>
<!-- Descr added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  DESCR %STRDOM; >
<!-- EMPLID added 3/31/2010 for BlackboardMobile -->
<!ELEMENT EMPLID %STRDOM; >
<!-- EndDt added 3/5/ 2010 for BlackboardMobile -->
<!-- For Class: EndDt is the class end date (ie when class meeting ends, usually tied to last day of classes for career but not always) -->
<!ELEMENT END_DT %STRDOM; >
<!-- ENRL_STAT added 4/16/2010 for BlackboardMobile -->
<!ELEMENT ENRL_STAT %STRDOM; >
<!-- FacilityId added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  FACILITY_ID %STRDOM; >
<!--  FACILITY_TBL_DESCR added 4/6 for BlackboardMobile -->
<!ELEMENT FACILITY_TBL_DESCR %STRDOM; >
<!--  FACILITY_TBL_DESCRSHORT added 4/6 for BlackboardMobile -->
<!ELEMENT FACILITY_TBL_DESCRSHORT %STRDOM; >
<!--  FACILITY_TBL_ROOM added 4/6 for BlackboardMobile -->
<!ELEMENT FACILITY_TBL_ROOM %STRDOM; >
<!--  FIRST_NAME added 4/14 for BlackboardMobile -->
<!ELEMENT FIRST_NAME %STRDOM; >
<!-- Fri added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT FRI %STRDOM; >
<!--  INSTR_ASSIGN_SEQ added 3/31/2010 for BlackboardMobile -->
<!ELEMENT INSTR_ASSIGN_SEQ %STRDOM; >
<!-- INSTR_ROLE added 4/16/2010 for BlackboardMobile -->
<!ELEMENT INSTR_ROLE %STRDOM; >
<!--  LAST_NAME added 4/14 for BlackboardMobile -->
<!ELEMENT LAST_NAME %STRDOM; >
<!-- Location added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  LOCATION %STRDOM; >
<!-- MeetingTimeEnd  added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  MEETING_TIME_END %STRDOM; >
<!-- MeetingTimeStart added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  MEETING_TIME_START %STRDOM; >
<!--  MIDDLE_NAME added 4/14 for BlackboardMobile -->
<!ELEMENT MIDDLE_NAME %STRDOM; >
<!-- Mon added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  MON %STRDOM; >
<!--  NAME_DISPLAY added 4/14 for BlackboardMobile -->
<!ELEMENT NAME_DISPLAY %STRDOM; >
<!--  NAME_PREFIX added 4/14 for BlackboardMobile -->
<!ELEMENT NAME_PREFIX %STRDOM; >
<!-- Sat added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT SAT %STRDOM; >
<!-- SearchBox added 2010/03/11 for CLASS_TBL_QUERY -->
<!-- SearchBox xeo:desc="Fan-out search parameter" -->
<!ELEMENT SearchBox %STRDOM;>
<!-- SESSION_CODE added 2010/03/05 for CLASS_TBL -->
<!-- SESSION_CODE xeo:desc="The SESSION_CODE is '1' for Fall and Spring offerings, but for the Summer it denotes which six week sesson (first or second) {1, 6W1, 6W2} -->
<!ELEMENT SESSION_CODE %STRDOM;>
<!-- StartDt added 3/5/ 2010 for BlackboardMobile -->
<!-- used in Blackboard,Class Start Date (ie when class meeting begins, usually tied to first day of classes for career but not always) -->
<!ELEMENT START_DT %STRDOM; >
<!-- Strm added 3/5/ 2010 for BlackboardMobile -->
<!-- term (ie, 5101, etc) -->
<!ELEMENT STRM %STRDOM; >
<!-- STRM_DESC  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  STRM_DESC %STRDOM;>
<!-- STRM_DESCRSHORT  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  STRM_DESCRSHORT %STRDOM;>
<!-- SUBJECT  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  SUBJECT %STRDOM;>
<!-- SUBJECT_DESCR  added 4/2/2010 for BlackboardMobile-->
<!ELEMENT  SUBJECT_DESCR %STRDOM;>
<!-- SUBMIT_DATE added 3/18/2013 for Emory Commons -->
<!ELEMENT SUBMIT_DATE %STRDOM;>
<!-- Sun added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT SUN %STRDOM; >
<!-- Thurs added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT THURS %STRDOM; >
<!-- Tues added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  TUES %STRDOM; >
<!-- Wed added 3/5/ 2010 for BlackboardMobile -->
<!ELEMENT  WED %STRDOM; > 

Provide Message Constraint and Sample Messages

After the structure of the new message objects have been defined, one provides the message constraint and samples messages for each action that will be supported. These messages serve three purposes. First, they help analysts and developers communicate and refer to the service operations by providing one example of each action performed on each object. Second, they are read by the Message Object API Generation Application (MoaGen) in the next step of the process to automatically generate the Java Message Object API. Third, they are used at runtime by the PeopleSoft service as templates for message, which significantly accelerates the process of building XML messages as opposed to building entire XML documents from scratch for each message. Here are links to the sample messages for the CLASS_TBL object. For more details on precisely where these artifacts would be placed within a message definition tree or MOA archive see the OpenEAI Message Definition document.

Regenerate the PeopleSoft Message Object API

Configure the PeopleSoft Service Message Mappings

Regenerate the Web Service Facade

Part 2: PeopleSoft Integration Broker and PeopleSoft Development Practices

PeopleSoft Integration Broker

Overview

When integrating any third party ESB with a PeopleSoft source system, one is primarily looking to implement two types of integration: sync publication and request reply.  PeopleSoft delievers several different connection methods.  This documentation is primarily focused on utilizing the delivered PeopleSoft JMS Connector.  We also will add addtional info about utilizing the PeopleSoft HTTP Connector.  In the next section, we will give a brief overview of how the Request Reply and Sync Publication is set up.  When finished with Part 2, a developer should be able to have a good understanding of the steps needed to implement both of these types of integration utilizing the PeopleSoft Integration Broker with some concrete real world examples.

Request/Reply

While doing Request Reply integrations with PeopleSoft Integration Broker, the overall flow of the process is:

• Requets are sent to a queue on the designated Message Transport
• The JMS Listening Connector is setup to Listen to that specific queue, and consumes the request message

Figure 3. PeopleSoft Request/Reply: ESB PeopleSoftService

Sync Publication

When publishing Sync messages from PeopleSoft, several methodologies can be used.  

• PostSaveChange PeopleCode can be created to create messages to be published when changes are made within the PeopleSoft components.
  • This method utilizes an IB Node that is set up to publish to a specific topic on the message transport.
  • This method is potentially not 100% if the data being input into PeopleSoft does not utilize the PeopleCode. (SQR, App Engine, SQL)

Figure 4. PeopleSoft Sync Publication: Component PeopleCode

• App Engine programs can be utilized to baseline specific data and publish out sync messages.
  • This method also utilizes an IB Node that is set up to publish to a specific topic on the message transport.
  • This method uses a scheduled process to call the App Engine.  The schedule is set based on need and performance.

Figure 5. PeopleSoft Sync Publication: Application Engine

• ESB driven RdbmsConnector process can detect changes, then generate sync messages by going directly against a source table or view.
  • This utilizes a direct connection to the database.
  • PeopleSoft database triggers can be utilized to maintain audit tables that are used to trigger sync publication.

Figure 6. PeopleSoft Sync Publication: ESB RdbmsConnector with Database Triggers

Integration Broker Setup

Add Jars to Classpath in PeopleSoft

• In order to properly setup the JMS Connector, Jar files for the Message Transport must be added to the classpath on the Webserver.
• For example, the jar files for Sonic MQ are:  mfcontext.jar,  sonic_Client.jar,  sonic_Crypto.jar,  sonic_XA.jar
• The files need to be dropped in the example path: /u01/app/psoft/SA/sa849/webserv/sa/applications/peoplesoft/PSIGW/WEB-INF/lib
• The Webserver will need to be rebooted to take advantage of these Jar files.

Set up Integration Gateway

Set Up Local Gateway

Under Integration Broker > Configuration > Gateways

• Add Gateway ID: LOCAL
• Check Local Gateway checkbox
• Add a URL such as:  https://sa.cc.yourserver.edu/PSIGW/PeopleSoftListeningConnector 
• Click button to Load Gateway Connectors
• For ID of JMSTARGET, with Class name of JMSTargetConnector, Click on Properties link and set according to next section

Setting Up JMS Target Properties 

• Set initial Properties as below

Configuring Integration Gateway Properties File

The JMS Properties will need to be configured in the Gateway Properties File under the Gateway Setup Properties link.  Fill in the properties in the JMS Section noted below:

• Fill in the JMSProvider as in examples below:

  • ig.jms.JMSProvider.JNDIFactory.SonicMQ=com.sonicsw.jndi.mfcontext.MFContextFactory

    ig.jms.JMSProvider.JNDIFactory.Weblogic=weblogic.jndi.WLInitialContextFactory

    ig.jms.JMSProvider.JNDIFactory.MQSeries=com.sun.jndi.fscontext.RefFSContextFactory
    
    

• Fill in the Queues with the number of Queues setup (in our example it is just one)

  • ig.jms.Queues=1
    
    

• Fill in the Queue properties for the queue you just noted above (example below)

  • ig.jms.Queue1=cn=ExternalQueueNameGoesHere

    ig.jms.Queue1.Provider=ProviderNameGoesHere

    ig.jms.Queue1.JMSFactory=cn=QueueConnectionFactoryGoesHere

    ig.jms.Queue1.Url=tcp://servername1.cc.youruniversity.edu:2506,tcp://servername2.cc.youruniversity.edu:2506

    ig.jms.Queue1.SecurityPrincipal=SecurityPrincipalGoesHere

    ig.jms.Queue1.SecurityCredentials=EncryptedPasswordGoesHere

    ig.jms.Queue1.MessageName=ServiceOperation1GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation2GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation3GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation4GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation5GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation6GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation7GoesHere

    ig.jms.Queue1.MessageName=ServiceOperation8GoesHere

Create Node

Add New JMS Sending External Node at PeopleTools > Integration Broker > Integration Setup > Nodes

• Add Description
• Node Type: External
• Active Node: Checked
• Authentication Option: None
• Default Userid: Needs to be valid User in the system dedicated to IB functions
• Under Connectors Tab:
  • Gateway ID: LOCAL
  • Connector ID: PSFTTARGET
• Under WS Security Tab:
  • Athentication Token Type: Username Token
  • Check Use External User ID

Create PeopleSoft Messages

• During the creation of the SOA Integration Service, we decided to try to keep things as close to the way PeopleSoft operates as possible. 
  • One of the things we decided to do is to utilize the Rowset Message as much as possible. 
  • With the Rowset Message, we are able to use the PeopleSoft delivered rowset functions, easily utilize Component Interfaces, and leave a smaller footprint of code.
• Once a message has been actually used by Integration Broker, it is inserted into the runtime tables. 
  • Once this happens, any changes require updating the version and reapplying the new version to the Service Operation.
• Because the OpenEAI framework utilizes patterns of messaging and processes, it was important to be able to have two rowsets at the level zero in a message to show baseline and new states of the data. 
  • The only way to implement this in PeopleSoft is using container rowset messages. 
  • Container messages are needed for Sync publication.
• Request Response messages can be simple Rowset messages.

Figure 7. Example Rowset Message

Figure 8. Example Container Message

Figure 9. Example Part Message

• Using Aliases for Records
  • It is possible that you need to have a name on your external object that is longer than what PeopleSoft supports
  • Under this circumstance, you may add an alias to your PeopleSoft record name that reflects what the external object name is
  • The transformation of names is automatic and you do not need to do anything more to make this transformation happen

• Using Aliases for Record Elements
  • It is possible that you may map fields of the same name, from multiple tables in PeopleSoft to different elements in your object
  • In this instance, you will need to alias your field element in PeopleSoft
  • This happens a lot with the DESCR field in PeopleSoft, which is used to house descriptions of a variety of fields, and shows up in many tables

Figure 10. Example Alias of Record or Field

Create PeopleSoft Integration Broker Services

• The Service is pretty easy to set up.  It is the high level grouping of all Service Operations.
• The screenshot for setup of SOA_INTEGRATION_SERVICE is below.

Figure 11. Example Service Inbound

Figure 12. Example Service Outbound

Create PeopleSoft Integration Broker Service Operations

• When setting up Service Operations, three main items need to be set up: Messages, Handlers, and Routers.
• Only inbound messages will have Handlers.
• Service Operation Security must also be setup or the Service Op will not work properly, and nothing will be accessible in the Service Operations Monitor.
• If a message definition changes for the Service Operation, a new version of the Service Operation will need to be created.

Figure 13. Example Service Operation General

Figure 14. Example Service Operation Handler

Figure 15. Example Service Operation Handler Detail

Figure 16. Example Service Operation Routing

Create PeopleSoft Routing

• Routings are attached to the Service Operations. 
• The Routing has to be set up properly for the message to be routed to the Service Operation by the JMS Listening Connector on the inbound messaging.
• Logging is controlled in the Routing Definition.
• Sender and Receiver nodes are specified in the Routing definition.
• Once a Routing has been used, a new version must be created in order to actually modify them.
• When adding the Parameters tab, it is REQUIRED to take the version number off of the External Alias.  The Messages WILL NOT BE DELIVERED IF THIS IS NOT DONE.
• I am attaching screen snapshots of inbound and outbound Routings below.

Figure 17. Example Service Operation Routing Definition (Outbound)

Figure 18. Example Service Operation Routing Definition (Outbound)

Figure 19. Example Service Operation Routing Definition (Outbound)

Figure 20. Example Service Operation Routing Definition (Inbound)

Figure 21. Example Service Operation Routing Definition (Inbound)

Create PeopleSoft Handlers

Insert steps to create the handler

Create PeopleSoft OnRequest PeopleCode

Insert PeopleCode considerations and some examples

PeopleSoft Development Practices

Overview of Approach

High level about what we have learned

PeopleSoftService Basics

Schematic of what happens in PeopleSoftService

Mapping PeopleSoft IB Messages to PeopleSoftService Messages

Give detailed instructions on mappings required by PeopleSoftService