PeopleSoft Integration Broker setup for Test Framework – Part V

How to get to the Integration Broker Error Log.

In our environment we use Windows as our web server OS.  So the paths I’m giving here may not be correct for a UNIX flavor environment.

In any event, to reach this log you need to have read access to the webserv directory on your web server.  The path should be something like:

<instance name>\webserv\<instance name>\applications\peoplesoft\PSIGW.war\errorLog.html

This log provides information in this general format:

• Time and Date of error
• Error Type
• Error Level
• Description of error
• Message Catalog Information
• Stack Trace
• Request
• Response

The Message Catalog information is from PeopleTools – and it points you in the general direction.  There may or may not be MessageParms which can further help with debugging.

Next, this is a Java web/servlet application.  So the stack trace is a Java exception log.  Sort of useful to read and get a handle on what is going on, but the other two panels may help more.

The Request part shows the SOAP XML request sent by PTF  to the Anonymous Node.  The listener for Integration Broker gets this HTTP request and attempts to route it to the correct node.

The Response part shows the SOAP XML message being returned by the listener.

So what is the usefulness of this?  Well – PTF is kinda dumb, but maybe in a smart way.  If it can’t make a connection to a node it makes you think you put in the wrong user name or password.  Good for a web login for security purposes – but come on!  This tool isn’t for the general user.

So the IB log can tell you things that the PTF login won’t.  I find it useful as I step thru the process of making changes in Integration Broker, attempt to log in, then look at the error log file.  As changes are made you should see different errors thrown until you get to that magic moment where PTF has logged into the node and the tool IDE opens up.

PeopleSoft Integration Broker setup for Test Framework – Part III

Earlier posts dealt with making sure the default local node was set up correctly and some basics on Quick Configuration.  In this post I’m going to talk about the Anonymous Node.

The Anonymous Node is used by Integration Broker.  You should have the following settings at a minimum:

On the Node Definition Tab – Node Type: External; Authentication Open: None; Default User ID: here the ID needs to have access to the PeopleTools roles as well as the PTF roles.  I’ll be covering security in later posts.  Active Tab should be selected as well as Segment Aware.

Connectors Tab – Leave the Gateway ID set to Local, you don’t need a Connector ID.  I have my Delivery Mode set to Guaranteed.  Don’t bother pinging – it should fail.

Portal Tab – I usually set mine up the same as the Default Local Node.

WS Security Tab – the Authentication Token Type needs to be None.

Routings Tab.  Here we run into the real meat of setting up the Anonymous Node for PTF.  I make sure the following routings and service operations are set up for the node:

• GENCOMPONENTURL_RT, uses the GENCOMPONENTURL_SO Service Operation
• PT_SOAPTESTER_ROUTE, uses the PT_SOAPTESTER Service Operation
• PTTST_CONFIG, uses the PTTST_CONFIG Service Operation

On all three of these the following properties should be seen on the page:

• OType – Synch
• Sender Node – ANONYMOUS
• Receiver Node – Your Current Correctly Configured Default Local Node
• Direction – Inbound
• Status – Active

The Receiver Node will be the tip off if you are having problems – most especially with a database that has been created from a refresh from production.  If there is anything else in the Receiver Node column outside of the default local node the Anonymous Node isn’t set up correctly, and PTF will fail.

You can try to inactivate a bad routing and or service operation and then recreate them – however what I’ve found is go thru the process of renaming the default local node.  I cover that in Part I of this PTF setup.

PeopleSoft Integration Broker setup for Test Framework – Part II

In this post I’m going to cover the rest of IB basic setup.

So right now we have a clean default local node, and behind the scenes PeopleTools App Engine has done some magic for us.  Service Operations have been set up with routings using our new node.  Still, we need to do a couple more housekeeping measures.

Get your cup of coffee?  Good.  Log into your instance, go to PeopleTools, Integration Broker, Integration Setup, Nodes, Your Default Local Node.

Authentication here should be Password.  Lets cover some roles this account should have, shall we?  At a minimum this role should have PeopleTools, and one of the three PTF roles – Admin, Editor, User.  The role I’m using has all three levels altho frankly I think we would do fine with just PTF Administrator.

Now click the Portal tab.  This tab seems to have mystical and magical powers – in only that it’s a toss-up as to how useful it is, what is it used for…

For now, and because I’m not a System Admin but have some background in how HTTP Nodes work – we are going to go the conventional route.  With a bit of an explanation.

We are dealing with a distributed computing environment here using HTTP as the communication and information transport protocol.  Which is a lot of techno geek leet speak for we’re using is a specific set of rules to get one point of our internet enabled network to talk to other points.

In any event our node needs to understand where home is.  Pick your Default Portal – my company uses Employee for its HRMS implementation.  Then fill in the Content URI Text and the Portal URI Text.  There is a template provided by PS above both boxes – in any event it’s http(s)://someserver/psc/pshome/ for the Content URI and http(s)://someserver/psp/pshome/ for the Portal URI.

Okay so right now we have the basics set up for our default node, let’s hit some other tasks.

Go up into Integration Broker, Configuration, Quick Configuration.  This page covers three areas – Gateway Setup, Integration Broker Domains and the Service Configuration.  Frankly these should be mostly set up, but I’ll cover them briefly with this caveat – I’m not a system admin.

The Gateway URL should be something like this: http(s)://PeopleSoft Server>/PSIGW/PeopleSoftListeningConnector.  If you were to copy and paste that address into a browser address bar you should connect to the Integration Gateway.  In fact that is what happens when you click the Ping button.

If this was a copy from Prod then the URL needs to be changed.  Get in touch with your System Admin and have him/her help you with this part.

Integration Broker Domains – that should display the machine name and the path for your PeopleSoft instance.  It should also display a status of Active.  You should have your Gateway set up first as well as your default local node.  There is a hyperlink to the Domain Status page – if what is listed isn’t the correct environment you can try to set the status to Inactive, then do a Purge Domain Status, followed with a Refresh.  If you run into trouble at this part, I would guess you have problems with your Gateway setup.

Last is Service Configuration.  The setup here directly affects PTF.  You can stay with the default/delivered Service Namespace and Schema Namespace – but you need to fill in the Target Location.  That is the URL to your ListeningConnecter java applet in your web server.  The URL  is

http://:/PSIGW/PeopleSoftServiceListeningConnector

– note this is http only.

For those who are running https the template is almost the same:

https://:/PSIGW/PeopleSoftServiceListeningConnector

Some good news for those who do have installations behind load balancers – this will work.  And if your PeopleSoft instance is set up in your networks DNS tables, you won’t have to provide a port number; that is created as part of the DNS listing for your application.

This service configuration must be correct or PTF will not work.  You should at the very least be able to get a SOAP response from the server if you enter your URL into a browser address bar.  The body of the response should have a line:Integration Broker Response – that tells you that you are indeed contacting the IB instance.

More to cover in later posts!

PeopleSoft Integration Broker setup for Test Framework – Part I

It has been a while since I’ve posted – busy with school and work, sorry!

PeopleSoft Test Framework – nice tool I guess; been thru the training but it’s not the easiest thing to set up.

First of all – some basic ground rules.  This is a client based application written in .NET.  Shocking I guess.  This means this runs only on a Windows machine.

Next, it makes connections thru the HTTP layer to an application server-based on node definitions that need to be set up properly in Integration Broker.

Oh – and by the way – the documentation for setting up PTF in Integration Broker consists of one line – ‘if you have an issue, contact your IB specialist’.

PTF depends on the ANONYMOUS Node to work.  And if that node isn’t set up right, heck if IB isn’t set up right then PTF ain’t gonna work.

So, after having to get it going in a couple of environments I’m going to get into what has worked for me – there may be steps you find redundant dear reader – my apologies ahead of time…

First of all – get yourself a copy of this document from Oracle: 

E-IB: How to Setup Integration Broker after Copying a Production Database on PeopleTools 8.48+ [ID 1115623.1]

This document has a lot of very useful information on setting up IB when copied from your Prod to another environment.  That seems to be the most difficult situation – and is where I had the most challenges.  Like me,  you are likely NOT going to be using PTF in your production environment – it will need to have connections to your development and QA sites.

So, let us get started.  This is going to take some time, so get yourself a cup of coffee.  And remember – just as in The Hitchhikers Guide – DON”T PANIC.

These steps work whether or not you have a fresh copy from your production environment – don’t worry if you are doing this in a database that has been around for a while.

Shut down your application server.  If you don’t know how to do that, now is the time to get your sys admin involved – and ask questions, pester him or her on how to do it.

Once that is complete, log into App Developer, and open Data Mover.  You want to run a script named appmsgpurgeall.dms. The script can be found in the PS_HOME\scripts directory on your file server – this does a purge of messages that were left over from the source location.

Once that is done clear the cache from the app server instance you are working in, then restart it.

Okay, the app server is now up and running.  Open up your database instance in your browser of choice.  Go to PeopleTools, Integration Broker, Integration Setup.  Open up Nodes – you should have a default Local Node that has been defined.  If this is a fresh copy from production this is the easiest – but if it isn’t I’ll also cover that.

Open the node – in any situation it will have the following checked off:

Default Local Node, Local Node, Active node.  You should also find the check boxes grayed out.

So far so good.  If this is a copy from production do a rename of this node to whatever it is you need to name it to for your environment.  If this is an older copy, your node has been already renamed but PTF does not work and you have decided it’s due to Integration Broker – guess what.  You are also going to be doing a rename.  But I’ll get to that one later…

For those with nice clean environments – do a rename, then save.  You should at this point exit out of your session – clean your browser cache and log back in.  Navigate back to Nodes, there is more work to do.

Those of us with buggered up environments – this is what I’ve done to set it right.  You need to know what the prior default node name was.  If you don’t know for sure look in this table: PSIBRTNGDEFN.  You need to look up values in these elements – RECEIVERNODENAME or SENDERNODENAME.  Don’t get tempted to do a SQL update in this table – the IB team at Oracle PeopleSoft advised that was not a best practice.

Armed with the prior name of the node – do a rename to the previous name.  Yes, it’s counterintuitive – but this does work.  Let’s cover the rest of the steps tho before you actually do it.  First you have found out the prior name of the node, and then rename the default node name back to what it was.  After that is saved you should just exit out of the session.  Shut down the app server, then with Data Mover run the appmsgpurgeall.dms script.  This part is critical – you need to purge any messages that were running in the background.  Clear out cache again in the App Server, then restart it.  Open up your browser – then do yourself a favor and clean out your local cache again.

Log into your database instance – go back to Nodes.  And now rename the node to what you want.  Yep, repeat the same steps again – log out, shut down app server, run the Data Mover script, clean out app server cache, clean out your browser cache, then log back in.

What is going on in the background are App Engine jobs resetting Routings and Service Operations.  Let PeopleSoft do this work for you – it is a lot cleaner than you doing it manually.

Okay, we’ve done a lot at this point.  This post is getting long and I think I’m going to cover the rest in another one.  Besides, at this point you probably need another cup of coffee so see you in the next one.

Next post(s) we cover the rest of IB basic setup, the awesome Anonymous node, and a few odds and ends of PTF security.