My Reports with No Reports?

You might have came this scenario, if you have worked on the My Reports Pagelet. When you use it for the first time, the reports might now appear here.

When you click on the Report Manager link beneath, it takes you to the Explorer tab, where again you will get the same message.

But the Administration tab might be having the reports but not in the Explorer tab.

To rectify this and to start posting the reports to teh Explorer tab, which will ultimately display the data in the My Reports pagelet, you have to check and activate the following Routing - Service Operations at the Default Local Node.

• PSRF_FOLDER_CREATE
• PSRF_REPORT_CREATE
• PSRF_REPORT_DATE_CHANGE
• PSRF_REPORT_DELETE

Once you set this up and bounced the server (if required), the My Reports Pagelet will start populating the reports.

Get a value from the XML

Okay so this is the scenario. You've got a response from the XML request you places via Integration Broker and you want to extract the data from a specific tag for further processing. The below code will help you to accomplish the same.

&lmsgGoRequest = CreateMessage(Operation.OPERATION_NAME, %IntBroker_Request);

&lmsgGoRequest.SetXmlDoc(&lxmlDoc);

&lmsgGoResponse = %IntBroker.SyncRequest(&lmsgGoRequest);

&MyDoc = CreateXmlDoc(&lmsgGoResponse.GenXMLString());

&field1List = &MyDoc.GetElementsByTagName("EMPLID");

WinMessage(&field1List [1].NodeValue);

&field1List is the array of the tags fetched from the XML (which you have specified) and NodeValue gives you the value of the tag.

Hope it helps!

Integration Broker Monitor

I find that users are often confused about how to look at the message monitor to determine if there are errors. 

The most common mistake is when a user just looks at one of the three message queues and ignores the rest. They may just look at the “Operation queue” or just the “publication queue” when in fact you need to look at the Operation, Publication, and Subscription queues to make sure they are all clear of errors.

I put together the following screenshot that I hope will help people understand how to properly look at the message monitor to see if there are any errors and see if all the messages have processed. 

Note: This is taken from an 8.49 Tools database.   There were major changes to the Integration Broker terminology starting in 8.48.  However, the concepts are really the same but the terminology has slightly changed starting in 8.48.

Overview of Integration Broker Publishing Steps

The Application Messaging / Integration Broker is a complicated PeopleSoft module and can be very confusing if you don’t know what to look for.

An application message goes from several stages in both the “publishing” system and the “subscribing” system before the integration message has completed is both publishing and subscribing systems. It also gets handed off between many different application server processes and at any point one of those processes can crash or be down and it can cause the message to not complete. This will result in passwords being out of synch for users between databases until that message can reach its destination and update the database. 

For some perspective the application message goes through these high level steps with each one being a failure point. Hopefully, this information will help when looking at the Message monitor.

Application Messaging Processing Steps 

• A user interacting with the application changes their password which triggers some “publication” PeopleCode that creates the message. 
• The integration broker receives the publication event and creates the message in the publishing broker. The message will now only be visible in the “Message Queue” on the message monitor. 
• If the Message Channel Is Paused the Publication will stop here until the channel is un-paused. 
• A second app server process wakes up and looks at the new message and determines where it needs to publish to and creates the “publication contracts.” The message contracts will now be visible in the “Publication Queue” in the message monitor. For the password synch mod, for each password change there is 3 contracts created, one for each destination database. 
• A third process wakes up and sees the new publication contracts and processes each publication to each database separately. For example if a user changes their password in Finance, you will see in the integration broker 3 publication contracts. One for SA, Portal and CRM. 

The password at this point is still not changed in the target systems yet. If the publishing database says that the messages published you need to verify that the subscribing database had completed processing the message.

The subscribing database broker receives the published message and creates the new message instance in the integration broker. The message will now be visible in only the “Message Queue” on the subscribing message monitor. 

• If the Message Channel is paused the process will stop here until the channel becomes un-paused. 
• A second subscribing process wakes up and sees the new message instance and determines what subscription contracts need to be created and they get created. The message contracts will now be visible on the “Subscription Queue” on the Message Monitor. 
• Once the subscription contracts are created another process wakes up and processes the subscription contract PeopleCode. 
• If all of the above contracts have been processed then the message is considered” completed and both database have been updated.

Setup Integration Broker for Web Services

By david.bain

If you venture to the PeopleSoft/Fusion Middleware best practice site, you'l also see that several of the Oracle-By Example or viewlets showcasing PeopleSoft interoperability with Fusion Middleware use web services provided by a PeopleSoft system through Integration Broker. Some of the examples go through some minor integration setup but don't explain what is going on and don't go through the entire setup. Many of you have taken the 8.48 integration broker class or have implemented web services in your production system so finding or setting up a test PSFT environment is not an issue. But not all of you . . .

More than once I've heard "I tried setting up integration broker but I couldn't get it to work so I gave up". Usually the problem is something simple like typing the wrong tools release when configuring the gateway connector for a target node (<ctl> j from a pia page gives you that info!). Making it through all the steps can be difficult, even for someone that is familiar with integration broker.

To help you out, weve created a viewlet that identifies all the steps you need to go through to set up a PeopleSoft environment that provides web services. Theres no sound, so you dont have to worry about bothering your neighbor, and its interactive, so you can select only the steps you need more information on.


Here's a link to the viewlet: IBSetup

What are the steps it goes through? Here they are:

1) Enable the pub/sub processes in the app server so there is support for asynchronous services.
The web services used by examples on the best practice site are all synchronous so this is not mandatory. But Im sure some of you will take what you see to the next level and before long start trying out asynchronous service requests. As soon as you try that, youll need these services enabled to provide queues for the gateway to store the service request.

2) Change the Default Local Node
Again, this is not required to run the samples provided. Youll only have to do this when you want to start testing more complex integration scenarios. But it is easy to do and a good idea. Youre much safer using a creative name for your PSFT system than sticking with the generic PSFT_HR thats delivered.
It is easy but theres a catch. You have to run a data mover script (appmsgpurgeall.dms) to clear out the message queue (the datas in database tables). If you dont do that, youll get a cryptic error message

3) Configure the PeopleSoft Listening Connector
Our first required step. This is necessary for a PSFT AppServer to communicate with an Integration Gateway. You get to test it right from the page you enter the URL so its pretty foolproof. Dont forget to load the rest of the connectors as part of this step.

4) Configure the PeopleSoft Target Connector
Step 3 told the AppServer where the Integration Gateway was located. This tells the Integration Gateway where the AppServer is located. Youll set up a default location and add a node specific for the default local node you changed (or left unchanged) in step 2.

5) Service Configuration
The final and very important step is to complete the service configuration. This is required for running web services. Youll enter some default naming information for services and schemas. Youll also identify where the PeopleSoft Service Listening Connector is. Its not required but a very good idea to change your Service System to Development. That way you wont have to worry about service versions each time you make a change.
Youre all set to go now. Try the examples provided on the best practice site and experiment with some of your own.

Oracle Blogs

Integration Broker Web Service Discovery Class

Use the Web Service Discovery class to:

• Find web services currently offered by the Integration Broker.
  
• Retrieve the web services description language (WSDL) for a given web service.
  

The methods in this class are intended to be used in pairs. First, use one of the "Find" methods to get the list of web services, then use one of the "Get" methods to retrieve the WSDL for the given service.

The PeopleSoft Integration Broker Web Service Discovery objects are declared as type

WebServiceDiscovery. For example,

Local WebServiceDiscovery &theDiscovery;

&theDiscovery = create WebServiceDiscovery();

A Web Service Discovery object can be instantiated from PeopleCode, from a Visual Basic program, from Java, COM and C/C++. This object can be used anywhere you have PeopleCode, that is, in an application class, Application Engine PeopleCode, record field PeopleCode, and so on.

The Integration Broker Web Service Discovery class is not a built-in class, like rowset, field, record, and so on. It is an application class. Before you can use this class in your PeopleCode program, you must import it to your program.

An import statement names either all the classes in a package or one particular application class. For importing the Integration Broker Web Service Discovery class, PeopleSoft recommends that you import all the classes in the application package, although you won't be using most of the classes in these application packages.

The import statements you should use are as follows:

import WEBSERVICES:*;

 

Integration Broker Web Service Discovery Class Constructor

import SOAPTOCI:*;

import WEBSERVICES:*;

 

Local WebServiceDiscovery &theDiscovery;

&theDiscovery = create WebServiceDiscovery();

 

Integration Broker Web Service Discovery Class Methods

• FindCIWebServices(CI_Name, Request_Node_Name, Descr)
  

Use the FindCIWebServices method, to get only the web services based on component interfaces available in the system Use GetCIWebServiceWSDL to get the WSDL for each web service found by this method. If you specify blank strings for all three parameters, the method tries to return all component interface based web services.

• FindMsgWebServices(Msg_Name, Node_Name)
  

Use the FindMsgWebServices method, to get only the message-based web services available on the system. Use the GetMsgWebServiceWSDL method to get the WSDL for each web service returned by this method.

• FindWebServices()
  

Use the FindWebServices methodto get all web services, both component interface and message. Use the method GetWSDL to get the WSDL for each web service returned by this method.

• GetCIWebServiceWSDL(Service_Descr)
  

Use the GetCIWebServiceWSDL method, in conjunction with the FindCIWebServices method, to get the WSDL for a given web service.

• GetMsgWebServiceWSDL(Service_Descr)
  

Use the GetMsgWebServiceWSDL method, in conjunction with the FindMsgWebServices method, to get the WSDL for a given message based web service

• GetWSDL(Service_Descr)
  

Use the GetWSDL method, in conjunction with the FindWebServices method, to get the WSDL for a given web service.

Integration Broker Basics

I don't consider myself an Integration Broker expert.  Far from it.  I can get messages to fly from one PeopleSoft instance to another, I can write a transformation if pressed, and I can get messages that are stuck in a "New" status working again.  So I thought I'd go out on a limb here and pass along my mental model of how I visualize Integration Broker working.  If you're an expert, you might find this article simplistic and inaccurate at times and I'm hoping you'll speak up and let me know of the glaring problems.  But if you're a new to IB or trying to support somebody else's integrations you might find something in here useful.

If you think about it, any messaging system needs some basic building blocks to work.  Think about an e-mail system.  You have a Sender and a Recipient.  E-mail addresses are made up of a user (the part before the @ sign) and a domain (the part after the @ sign).  You have an e-mail server that routes the e-mail to the Recipient’s domain.  A server on the Recipient’s domain then gets it to the recipient’s inbox.  When the Recipient opens it, a Return Receipt e-mail might be generated back to the Sender as an acknowledgement.

Integration Broker follows a lot of these same rules.  But since its messages are generated and consumed by machines, things are more structured.
 

Building Blocks of Integration Broker 

Nodes

If you think about the e-mail analogy, the Node would be like the Domain part of the e-mail addresses.  For PeopleSoft-to-PeopleSoft communication, Nodes are (usually) PSFT_EP for Financials, PSFT_HR for HRMS, PSFT_LM for LMS, and PSFT_CRM for CRM.  They basically tell which application a message belongs to.

The node definition is where you define what messages are valid for that node.  Prior to PeopleTools 8.48, you’d define them on the “Transaction” tab.  In 8.48 and above, you’d define them on the “Routings” tab.

Since you might not want just anybody being able to publish a message to a node, you’ll need to set a node password on the first page of the node definition.  This password will have to be the same in all of the environments.  For example, if you want to publish a message to PSFT_EP from HRMS, the PSFT_EP node password will have to be the same in both Financials and HRMS.

Messages

The message definition is where the developer specifies what data a message will contain.  It includes records and fields, and child records are nested under their parent records.

If you think of the e-mail analogy, the message name would be both the User part of the e-mail address, and the message itself would be the Body of the e-mail.  

Transformations

A transformation is a program that gets executed against a message either when it’s sent, or when it’s received.  If you think about it, this can be important because data structures are different with different PeopleSoft versions.  So if you’re sending a message with employee data from HRMS 8.8 back to Financials version 8.4, there’s a good chance that the message that HRMS sends is different from what Financials is able to receive.  So you need a transformation.

The transformation itself is a special type of Application Engine program that integration broker can execute by itself against the XML of a message.  It uses either PeopleCode, or XSLT (a special language for transforming XML) to put the message into the new format.

In the e-mail analogy, this would be like me sending an e-mail to someone who doesn’t speak English.  I'd either have to translate it before I sent it, or the recipient would have to translate it.

Prior to PeopleTools 8.48, you use “Relationships” to associate a Transformation program to a message.  In 8.48 and above, you can associate a Transformation to a Message with either a Service Operation or a Routing.

Gateways

The gateway is kind of like the e-mail server.  It knows the nodes – that is to say for a given node it knows the server name, app server port number, username and password so that it can connect to the node’s app server and push the message to the integration broker running in that environment.

The gateway runs as part of the PIA web server.  Integration Broker sends messages to it with a plain ‘ol Post HTTP request.  This makes talking to Integration Broker pretty easy for 3rd party applications since they don’t have to write any special protocols.  

Asynchronous versus Synchronous

Integration Broker can do either Synchronous or Asynchronous messages.  Synchronous messages are sent and the program waits for a successful response from the remote system before it will continue.

Asynchronous messages are more like the E-mail analogy – the message is sent and the program gets on with its life, assuming the message will be OK.

Most PeopleSoft EIP's are Asynchronous, and so I’ll only talk about Asynchronous messaging in this document.

Message Channels / Queues

PeopleSoft lets you group message definitions into queues.  Queues can be paused or running.  So if you want to keep messages with employee data from trying to go from HRMS to Financials when Financials is going to be down, you can pause the message queue.  When the maintenance is over, you can set the queue to running.

They have another normally unused feature:  You can change how many messages get posted to the integration broker at one time by chunking on specific combinations of fields.  Message Chunking is more of a developer topic, so that’s all I’ll say about it for now.

Prior to PeopleTools 8.48, Queues were called Message Channels.  I don’t believe there’s any real difference in what they are or what they do.

Service Operations

Service Operations were invented in PeopleTools 8.48.  I believe the intention was to create a single place where you can define which nodes a message is valid for and what transformations need to be applied to it.  

Steps in Integration Broker prior to Tools 8.48

1.    PeopleCode event creates and publishes a message

2.    Integration Broker looks to see if the message channel for that message is active.

3.    Integration Broker creates a message instance for the message

4.    Integration Broker looks to see what nodes the message is active for

5.    Integration Broker creates a publication contract for each message node.

6.    Integration Broker looks to see if any “relationships” exist for the source node/target node/message/version combination, and executes the transformation associated with the relationship if it exists.

7.    For each publication contract, Integration Broker publishes the message (in XML format) to the integration gateway.  This includes the Source and Target nodes.

8.    The Integration Gateway looks for the target node in its configuration file (integrationgateway.properties), connects to the application server, and passes the message off to the target integration broker.

9.    Integration broker creates a message instance for the message.

10.    Integration Broker looks to see if the message is set up as an inbound message on the source node.

11.    Integration Broker creates a subscription contract for the source node (if active).

12.    Integration Broker looks to see if any “relationships” exist for the source node/target node/message/version combination and executes the transformation program if applicable.

13.    Integration Broker inserts the message into the database based on the message definition.

Steps in Integration Broker 8.49

The process is basically the same, but the terminology has changed.

1.    PeopleCode event creates and publishes a message

2.    Integration Broker looks to see if the Queue for that message is active.

3.    Integration Broker creates a transaction for the message

4.    Integration Broker looks to see what nodes the message is active for

5.    Integration Broker creates a publication contract for each message node.

6.    Integration Broker looks to see if any transformations programs exist for the service operation routing or the node routing, and executes them if found.

7.    For each publication contract, Integration Broker publishes the message (in XML format) to the integration gateway.  This includes the Source and Target nodes.

8.    The Integration Gateway looks for the target node in its configuration file (integrationgateway.properties), connects to the application server, verifies the node passwords from the source and the target environments match, and passes the message off to the target integration broker.

9.    Integration broker creates a message instance for the message.

10.    Integration Broker looks to see if the message is set up as an inbound message on the source node.

11.    Integration Broker creates a subscription contract for the source node (if active).

12.    Integration Broker looks to see if any transformation programs exist for the service operation routing or the node routing, and executes them if found.

13.    Integration Broker inserts the message into the database based on the message definition.

Integration Gateway Considerations

Integration Broker got an overhaul in PeopleTools 8.48, and the older PeopleTools versions are no longer compatible with the newer PeopleTools versions.

So how can you actually make the old PeopleTools versions send and receive messages with the new PeopleTools versions?  You have to make the older versions use the new Integration Gateway.

So what the does that mean?  Well, you have to do is go to PeopleTools > Integration Broker >  Gateways, and select the LOCAL gateway.  Change the URL to be the same as the environment with latest copy of PeopleTools’ LOCAL gateway URL.

Now if you want to change any Gateway configuration, be sure to do it from the latest PeopleTools environment.  Its bad luck to edit Integration Gateway configuration using a version lower than the gateway is running.  Also older tools versions won’t encrypt passwords like the new ones will.

Also, if you shut down a shared Integration Gateway web server, it’s going to impact Integration Broker on all of the environments that share it.  Messages should catch up whenever you bring the Integration Gateway web server back up, as long as you go to Message Monitor and resubmit the ones in error.

Summary

I'm hoping this clears up some of the compexities of Integration Broker.  Please let me know if I didn't say something right or got something wrong or missed something that should have been covered.

 

Written by Brent Martin

 

PeopleSoft Integration Broker - FTP Files

This article explains how you can download files from FTP servers using Integration Broker. It is usually helpful because it becomes it's quite easy and you don’t have to hard code user id and passwords in SQR, Application Engine or PeopleCode.
We are going to use Integration Broker technology to FTP files. PeopleTools comes with FTPTARGET connector that can be used to GET and PUT the files. You can follow the steps below to play around with the files.

Download file from FTP server:

1. Create FTP GET node: This node will be used to download the file from FTP server. Setup the node using these instructions:

o    Go to PeopleTools , Integration Broker , Integration Setup, Nodes.
Add a new node called FILE_FTP_GET_NODE. Make sure that node type is ‘External’ and it’s an Active node.

o    Go to Connectors tab and enter Gateway Id ‘Local’. In Connector Id field, select ‘FTPTARGET’ by clicking magnifying glass. Connector properties will be populated automatically.

o    Enter all the required fields such as hostname, userid, password (encrypted), etc. Enter ‘GET’ for method property. This is to tell the node that we are downloading the file.

o    You may add other properties for example ‘DIRECTORY’ to mention the folder where file resides. You may also specify name of the file using ‘FILENAME’ property.

o    Save the node.

2. Create Service Operation: Now create a Synchronous Service Operation. It will use two Services. Let’s create two non-rowset services called: FTP_RQST_SVC and FTP_RESP_SVC. Now add a new synchronous Service Operation called: FILE_FTP_GET_OPR. Use the above services as Request and Response in your service operation. Save it.
3. Create Routing: Go to Routing tab of FILE_FTP_GET_OPR service operation and add a new routing called: FILE_FTP_GET_RTG. In the routing definition, specify ‘PSFT_EP’ or your local node as ‘Sender Node’ and ‘FILE_FTP_GET_NODE’ as your 'Receiver Node'. Make sure that the routing is activated.

Now your integration broker setup for FTP the file is ready. Write PeopleCode to use the above setup. You may write code in Application Engine or behind a push button. You can even write Request and Response handlers.

 

Integration Broker Basic SetUp for PeopleTools 8.48

While browsing through various sites to find some information on IB, I found the following executable. It is a nice tutorial on how to do basic setup for Integration Broker.

Just open the following link , save the exe and run it.

http://blogs.oracle.com/peopletools/gems/ibsetupws.exe