PS WS Project Documentation

PeopleSoft Web Services Project Documentation

Contents


Overview

Tasks

  • Setup JMS Connector in PeopleSoft Integration Broker.
    • STATUS: This task has been completed.
  • Demonstrate publishing PeopleSoft Integration Broker Sync Messages to the ESB PeopleSoftService.
    • STATUS: This task has been completed.
  • Demonstrate PeopleSoft Integration Broker consuming ESB PeopleSoftService Query Request messages and providing Response messages to ESB PeopleSoftService.
    • STATUS: This task has been completed.
  • Demonstrate PeopleSoft Integration Broker consuming ESB PeopleSoftService Create Request messages and providing Reply messages to ESB PeopleSoftService.
    • STATUS: This task has been completed.
  • Demonstrate PeopleSoft Integration Broker consuming ESB PeopleSoftService Update Request messages and providing Reply messages to ESB PeopleSoftService.
    • STATUS: This task has been completed.
  • Demonstrate PeopleSoft Integration Broker consuming ESB PeopleSoftService Delete Request messages and providing Reply messages to ESB PeopleSoftService.
    • STATUS: This task has been completed.
  • Document all steps needed to setup PeopleSoft and ESB Integration Service.
    • STATUS: This task is 90% complete and will be 100% completed soon.

PeopleSoft SOA Integration Setup

The purpose of this documentation is to give a solid overview of how to set up PeopleSoft to publish all four types of integration messaging to an ESB. For our example, we have an application we call the PeopleSoftService in the ESB that converts messages back and forth between the ESB and PeopleSoft framework messages. The documentation should walk through:

  •  What needs to be done for setting up the JMS Connector in PeopleSoft Integration Broker.
  •  What needs to be set up in PeopleSoft Integration Broker for the SOA Service and SOA Service Operations.
  •  What is required in terms of Message formats between PeopleSoft Integration Broker and the ESB.
  •  Some specific coding examples used to publish and consume messages.
  •  Some Important lessons learned with the Application Server, Web Server, and JMS Listening Connector.

Hopefully subsequent deployments of ESB/PeopleSoft integrations will be done more rapidly based on the patterns established in this documentation and these integrations.

Setting up IB Gateway Properties File for JMS

When setting up the gateway properties file, the only section that needs attention is the JMS section.  The main things to add for publishing or consuming messages from the JMS Node in PeopleSoft are:

  •  Set up the JMSProvider.  For Sonic, we add this line:  ig.jms.JMSProvider.JNDIFactory.SonicMQ=com.sonicsw.jndi.mfcontext.MFContextFactory
  •  Set up the number of Queue listeners: ig.jms.Queues=4;
  •  Set up specific properties for each Queue: # For each queue specify the following properties
    # Name
    # Provider
    # JMSFactory name (which is binded to the JNDI)
    # MessageSelector (optional Message Filter)
    # JNDI System File URL
    # JMS User
    # JMS Password
    # Example :
    ig.jms.Queue1=cn=PeopleSoftIntegrationBrokerQueue
    ig.jms.Queue1.Provider=SonicMQ
    ig.jms.Queue1.JMSFactory=cn=PeopleSoftIntegrationBrokerConsumerQCF
    ig.jms.Queue1.Url=tcp://intsonicdev1.cc.emory.edu:2506
    ig.jms.Queue1.SecurityPrincipal=PeopleSoftIntegrationBroker
     # Use the supplied encryption utility to provide an encrypted password for the entry below
    ig.jms.Queue1.SecurityCredentials=xxxxxxxxxxxx
    ig.jms.Queue1.MessageName=SOA_CLASS_TBL_1_QUERY.VERSION_2
    ig.jms.Queue1.RequestingNode=SOA_INTEGRATION_SERVICE
    ig.jms.Queue1.DestinationNode=PSFT_SACON
  •  The example above in 3 represents only ONE of the four Queues.  Things to consider are that the security credentials are encrypted with the utility on the Node page.  The MessageName is the Service Operation Name for the message coming in through this Queue.  The Queue name is the Queue on the Sonic MQ Message Transport.  The Security Principal is the ID from Sonic MQ for the ConsumerQCF.  Below are screenshots of the Encryption utility on the node page.

Adding Jar files to the Classpath

  • In order to properly setup the JMS Connector, Jar files for the Message Transport must be added to the classpath on the Webserver.
  • 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 following path: /u01/app/psoft/SACON/sa849/webserv/sacon/applications/peoplesoft/PSIGW/WEB-INF/lib
  • The Webserver will need to be rebooted to take advantage of these Jar files.
  • The Jar files have been added to this page as file attachments.

Setting up JMS Node

  • When setting up the JMS Node in Integration Broker, go to Integration Broker - Integration Setup - Nodes.
  • We have a node set up for publishing outgoing sync messages and one setup for inbound messaging tied to a specific message Queue on Sonic MQ.
  • The JMS Node is an External node. This is true for both inbound and outbound nodes.
  • The External User ID and password are set up on the Sonic MQ side.
  • On the Connector Properties page for the outbound messages (Node Name = PSFT_ESB), the main values to take note of are:  JMSFactory = cn=PeopleSoftConnectorConsumerTCF,  JMSSecurityCredentials=XXXXXXX, JMSSecurityPrincipal=PeopleSoftConnector, JMSTopic=cn=PeopleSoftDropOffTopic, JMSUrl=tcp://intsonicdev1.cc.emory.edu:2506
  • On the Connector Properties page for the inbound messages (Node Name = SOA_INTEGRATION_SERVICE), the main values to take not of are: JMSFactory=cn=PeopleSoftIntegrationBrokerConsumerQCF, JMSQueue=cn=PeopleSoftIntegrationBrokerQueue, JMSSecurityCredentials=XXXXXXX, JMSSecurityPrincipal=PeopleSoftInegrationBroker, JMSUrl=tcp://intsonicdev1.cc.emory.edu:2506, JMSReplyTo=TRUE
  • On the WS Security page, check the checkbox for Use External ID, and Authentication Token Type should be Username Token.
  • I am attaching screenshots of both PSFT_ESB and SOA_INTEGRATION_SERVICE node setups below.
  • PSFT_ESB_Node.pdf 
  • SOA_INTEGRATION_SERVICE_Node.pdf

Setting up Service

Setting up 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.
  • I will include the screenshots for one inbound Service Operation and one outbound Service Operation.
  • SOA_CLASS_TBL_1_CREATE_ServiceOperation.pdf 
  • SOA_CLASS_TBL_1_QUERY_ServiceOperation.pdf 
  • ESB_OUTBOUND_SYNC_ServiceOperation.pdf

Creating 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.  The only way to implement this in PeopleSoft is using container rowset messages.  I will include a screen snapshot of both the part messages and the containers as well as a regular rowset message that is NOT a container message.
  • I am attaching screen snapshots of several of our messages below.
  • SOA_CLASS_TBL_1_CREATE_VERSION_1_Message.pdf 
  • SOA_CLASS_TBL_1_UPDATE_VERSION_2_ContainerMessage.pdf 
  • SOA_CLASS_TBL_1_UPDATE_VERSION_1_PartMessage.pdf

Creating Routings

  • 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.
  • Once a Routing has been used, new versions 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.
  • SOA_CLASS_TBL_1_UPDATE_V3_RoutingInbound.pdf 
  • ESB_OUTBOUND_SYNC_RoutingOutbound.pdf

Creating Handlers

  • Handlers are associated with Service Operations and are used to process messages routed to the Service Operation by the Routers.
  • Each Inbound Service Operation has a handler.
  • In the setup of the Service Operation, you specify the Name, Type, and Application Package, Class, and Method for the Handler.
  • The Peoplecode that ingests the message and does the Query or Component Interface logic will reside in this Application Package and Application Class.
  • I am attaching screen snapshots of the Update Handler below along with some example PeopleCode to handle the incoming message.
  • SOA_CLASS_TBL_1_UPDATE_VERSION_3_Handler.pdf 
  • SOA_CLASS_TBL_1_UPDATE_VERSION_3_HandlerPeopleCode.txt

Modifying IB Gateway Properties File

  • To setup the JMS Properties, Change the Integration Broker Gateway Properties File.
  • When this file has been changed, a reboot of the Web Server and Application Server are required.
  • See the PDF below for the path to change the IB Gateway Prop file and also see example text of the actual file in SACON that is set up for the SOA Integration Service via JMS.
  • IB_Gateway_Properties_Change.pdf 
  • IB_Gateway_Properties_File.txt

Handler PeopleCode

  • Each of the different Service Operations has Handler PeopleCode associated with it.
  • The Application Classes are contained in one Application Package for the SOA Integratino Service.

Application Packages

  • At this time, we only have one Application Package for all of the Class Table Integration and it is SOA_INTEGRATION_SERVICE.

Application Classes

Example Messages

Message Structure

Sample Messages

JMS Message Properties

  • Query Request JMS Properties: MessageName=SOA_CLASS_TBL_1_QUERY; RequestingNode=SOA_INTEGRATION_SERVICE; DestinationNode=SOA_INTEGRATION_SERVICE (for these, the MessageName is the name of the Message in PeopleSoft which is also in the Message XML.  The Requesting and Destination nodes are set to the name of the Service in PeopleSoft.)
  • Create Request JMS Properties: MessageName=SOA_CLASS_TBL_1_CREATE; RequestingNode=SOA_INTEGRATION_SERVICE; DestinationNode=SOA_INTEGRATION_SERVICE (for these, the MessageName is the name of the Message in PeopleSoft which is also in the Message XML.  The Requesting and Destination nodes are set to the name of the Service in PeopleSoft.)
  • Update Request JMS Properties: MessageName=SOA_CLASS_TBL_1_UPDATE; RequestingNode=SOA_INTEGRATION_SERVICE; DestinationNode=SOA_INTEGRATION_SERVICE (for these, the MessageName is the name of the Message in PeopleSoft which is also in the Message XML.  The Requesting and Destination nodes are set to the name of the Service in PeopleSoft.)
  • Delete Request JMS Properties: MessageName=SOA_CLASS_TBL_1_DELETE; RequestingNode=SOA_INTEGRATION_SERVICE; DestinationNode=SOA_INTEGRATION_SERVICE (for these, the MessageName is the name of the Message in PeopleSoft which is also in the Message XML.  The Requesting and Destination nodes are set to the name of the Service in PeopleSoft.)

PeopleSoft Webserver

  • The webserver will need to be restarted when changes are made to the Integration Broker Gateway properties file.  The important information is listed below.
  • Log into the Webserver at the following hostname: pstsawb1
  • Username: sacon
  • To stop the Webserver go to this directory /u01/app/psoft/SACON/sa849/webserv/sacon/bin  and issue this command stopPIA.sh.
  • To start the Webserver go to this directory /u01/app/psoft/SACON/sa849/webserv/sacon/bin and issue the command startPIA.sh.

PeopleSoft Appserver

  • The appserver will need to be restarted when changes are made to the Integration Broker Gateway properties file.  The important information is listed below.
  • Log into the Appserver at the following hostname: pstsaap1
  • Username: sacon
  • The first thing to do when logging it is issue the command: setup SACON.
  • To start/stop the Appserver go to this directory /u01/app/psoft/SACON/sa849/appserv and issue the command psadmin.
  • I am attaching screenshots below to walk through the shutdown and startup in psadmin.
  • AppserverStart.pdf
  • AppserverStop.pdf

JMS Listening Connector

Renaming Service Operation in IB

  • To rename a service operation in Integration Broker, you will need to several tasks.  They are listed below.  This would typically be done if the object definition external to PeopleSoft was changed and the change required a restructuring of the message.  The system will still need to be able to handle both the new and the old version of the object, so the original Service Operation name will change and the version number in the naming will be incremented up by one.  The example is below.
  • First, archive all the runtime transactions in the Service Operations Monitor.  This can be done individually or in batch.  The individual is done by checking the archive button on the detail page. (see the pdf below)
  • ArchiveServiceOperationRunTimeTables.pdf 
  • Next, go to the Service Administration tab under the Service Utilities (path PeopleTools>IntegrationBroker>ServiceUtilities>ServiceAdministration) and rename the Service Operation and Routing.
  •  

SonicMQ JMS Test Client

PeopleSoft Application Designer Info

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.