1.

Gateway
a) Make sure the gateway is up and the connectors are loaded

1
 b) Open the integrationGateway.properties file by clicking on “Gateway
Setup Properties” link on the Gateway page. Provide your credentials
when prompted. Make sure that both the Default Application Server
and the Default Local Node (in the case below it’s E881G20P) have an
entry containing the app server URL, UserId and Pwd, tools release,
etc. as shown in the screenshot below. Note that the screenshot below
was taken from another system

c) Click on the Advanced Properties link on the above page to open the
integrationGateway.properties file (screenshot below). Locate the ig.log.level
setting, set the value to 5, and save the change. This will allow the “msgLog.html”
to be generated. This file provides additional troubleshooting information, and can
be found in the same directory as the errorLog.html
(<PS_HOME>\webserv\<PIA_DOMAIN>\applications\peoplesoft\PSIGW).

2
2. Service Configuration Page - Click on the Service Configuration Link and enter
the PeopleSoftServiceListeningConnector URL and save. Also avoid changing the
service and schema namespaces unless you have a valid location where you store
them.

NOTE: The screenshot below was taken from another environment than the previous screenshots.

3
3. Expose the CI as a Web Service (part 1)
a) Navigate to PeopleTools > Integration Broker > Web Services > CI based
Services.
b) Enter the name of the CI you want to expose as a Web Service, and select
the CI as shown below.
c) Click on the Review CI status.

4
d) If the Service and Service Operations don’t exist, press the “Display
Selected Actions” button, and the Service and Service Operations will be created.
The screenshot below was taken after the Service and Service Operations were
created.

5
6
7
3. The next step is to “Provide the Web Service”. To perform this step navigate to
PeopleTools > Integration Broker > Web Services > Provide Web Service as shown
below.
NOTE: If you want to force the soap request to provide the Userid/password, it’s a good idea to open each
of the service operation(s), selecting the “User/Password Required” checkbox on the service operation’s
General tab, and saving the change before “Providing the Web Service” (steps below). Performing this step
prior to “Providing the Web Service” means that when the WSDL is generated at the end of the steps
below, the WSDL file will show this parameter to be required.
a) Enter the name of the Service and click Search. If the Service is found, it
will show up in the bottom portion (Search Results) as shown in the screenshot
below.
b) Select the checkbox next to the Service name and click Next.

8
c) Select the checkboxes next to the Service Operation names and click
“Next” as shown below. The Service Operations you select here will be make up
the WSDL file that is generated at the end of this task.

9
d) Press Next again

10
e) Press “Finish”. If you have a UDDI server already configured, you can
also publish to it.

11
 f) The URL in the screenshot below can be used by 3rd party tools to
discover the web service and import the wsdl, etc.

NOTE: Some 3rd party tools may force you to include the message schema files in
the WSDL itself prior to importing the WSDL. If so, you’ll need to open the message
definitions associated with each of the Service Operations in the WSDL, and
copy/paste the schemas into the WSDL file.

Below is the text

Service: CI_STATE has been exported.

Inserted WSDL: CI_STATE.1 in the repository

Generated WSDL URL:

http://gsplas144.us.oracle.com:7061/PSIGW/PeopleSoftServiceListeningConnector/CI_S
TATE.1.wsdl

12
If you copy the above URL into a browser you should be able to view the wsdl. Here’s a
sample (on the next page).

13
NOTE: Prior to trying to open the wsdl in a browser as shown above open the
GETWSDL service operation (part of the IB_UTILITY service), make sure it is active,
and the Routing on the Routing tab (see below) is Active. If the routing is inactive,
activate it and save the setting.

GETWSDL Service Operation

Routing tab of the GETWSDL Service Operation

14
4. Service Operation Security (see PeopleBooks for additional security options)
a) If you want UserId and password to be required in the request, select the
“User/Password” checkbox to the right of the Operation Description.

b) Click on the “Service Operation Security” link to the right of the ”Operation
Alias” edit box (in the above screenshot) to bring up a new window as shown
below. Add Service Operation permissions to the appropriate Permission Lists
(sample shown below).

15
5. Generating a SOAP template for initial testing – To perform initial testing using
SendMaster utility you can generate a SOAP template by either (a) pressing the
“Generate SOAP Template” button on the last page of Providing the Web Service
(see page 12 for a sample screenshot of that page); or (b) clicking on PeopleTools >
Integration Broker > Service Utilities and supplying the Service Name. Using either
(a) or (b) above should take you to the page shown below. Click on the Service
Operation link to get a sample SOAP request for the Service Operation you want to
test.

16
Here’s a sample Find request from a PT 8.49 system

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance/">
<soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsse="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>PTDMO </wsse:Username>
<wsse:Password>PTDMO</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<Find__CompIntfc__STATE>
<COUNTRY>USA</COUNTRY>
<STATE>CA</STATE>
</Find__CompIntfc__STATE>

17
 </soapenv:Body>
</soapenv:Envelope>

Below is a sample of the WSDL file content

<?xml version="1.0"?>
<wsdl:definitions name="CI_STATE.1"
targetNamespace="http://xmlns.oracle.com/Enterprise/Tools/services/CI_STATE.1"
xmlns:M221555.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/M221555.V1"
xmlns:M500768.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/M500768.V1"
xmlns:M760694.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/M760694.V1"
xmlns:M953815.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/M953815.V1"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://xmlns.oracle.com/Enterprise/Tools/services/CI_STATE.1"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:UsagePolicy wsdl:Required="true"/>
<plnk:partnerLinkType name="CI_STATE_PartnerLinkType">
<plnk:role name="CI_STATE_Provider">
<plnk:portType name="tns:CI_STATE_PortType"/>
</plnk:role>
</plnk:partnerLinkType>
<wsdl:types>
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/M760694.V1"
schemaLocation="M760694.V1.xsd"/>
<xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/M953815.V1"
schemaLocation="M953815.V1.xsd"/>
<xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/M221555.V1"
schemaLocation="M221555.V1.xsd"/>
<xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/M500768.V1"
schemaLocation="M500768.V1.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="M760694.V1">
<wsdl:documentation>M760694</wsdl:documentation>
<wsdl:part element="M760694.V1:Find__CompIntfc__STATE" name="parameter"/>
</wsdl:message>
<wsdl:message name="M953815.V1">
<wsdl:documentation>M953815</wsdl:documentation>
<wsdl:part element="M953815.V1:Find__CompIntfc__STATEResponse" name="parameter"/>
</wsdl:message>
<wsdl:message name="M221555.V1">
<wsdl:documentation>M221555</wsdl:documentation>
<wsdl:part element="M221555.V1:Get__CompIntfc__STATE" name="parameter"/>
</wsdl:message>
<wsdl:message name="M500768.V1">
<wsdl:documentation>M500768</wsdl:documentation>
<wsdl:part element="M500768.V1:Get__CompIntfc__STATEResponse" name="parameter"/>
</wsdl:message>
<wsdl:portType name="CI_STATE_PortType">
<wsdl:operation name="CI_STATE_F">
<wsdl:documentation>CI_STATE_F</wsdl:documentation>
<wsdl:input message="tns:M760694.V1" name="M760694.V1"/>
<wsdl:output message="tns:M953815.V1" name="M953815.V1"/>
</wsdl:operation>
<wsdl:operation name="CI_STATE_G">
<wsdl:documentation>CI_STATE_G</wsdl:documentation>

18
 <wsdl:input message="tns:M221555.V1" name="M221555.V1"/>
<wsdl:output message="tns:M500768.V1" name="M500768.V1"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CI_STATE_Binding" type="tns:CI_STATE_PortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="CI_STATE_F">
<soap:operation soapAction="CI_STATE_F.V1" style="document"/>
<wsp:Policy wsu:Id="UsernameTokenSecurityPolicyPasswordOptional" xmlns:wsu="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:ExactlyOne>
<wsp:All>
<wsse:SecurityToken wsp:Usage="wsp:Required" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd">
<wsse:TokenType>wsse:UserNameToken</wsse:TokenType>
<Claims>
<SubjectName MatchType="wsse:Exact"/>
<UsePassword wsp:Usage="wsp:Optional"/>
</Claims>
</wsse:SecurityToken>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl:input name="M760694.V1">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"/>
</wsdl:input>
<wsdl:output name="M953815.V1">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="CI_STATE_G">
<soap:operation soapAction="CI_STATE_G.V1" style="document"/>
<wsp:Policy wsu:Id="UsernameTokenSecurityPolicyPasswordOptional" xmlns:wsu="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:ExactlyOne>
<wsp:All>
<wsse:SecurityToken wsp:Usage="wsp:Required" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd">
<wsse:TokenType>wsse:UserNameToken</wsse:TokenType>
<Claims>
<SubjectName MatchType="wsse:Exact"/>
<UsePassword wsp:Usage="wsp:Optional"/>
</Claims>
</wsse:SecurityToken>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl:input name="M221555.V1">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"/>
</wsdl:input>
<wsdl:output name="M500768.V1">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="CI_STATE">
<wsdl:documentation>CI_STATE</wsdl:documentation>
<wsdl:port binding="tns:CI_STATE_Binding" name="CI_STATE_Port">
<soap:address location="http://gsplas144.us.oracle.com:7061/PSIGW/PeopleSoftListeningConnector"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

19
6. Testing from SendMaster – We strongly recommend that you test using
SendMaster utility before integrating with the 3rd party system. This will help ensure
that the PeopleSoft system is set up correctly. Below are two sample messages, one is
from a PT 8.48 system, and the second one is from a PT 8.49 system.

Below is a sample from a PT 8.48x system.

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<soapenv:Body>
<Find__CompIntfc__STATE xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/M760694.V1">
<COUNTRY>USA</COUNTRY>
<STATE>CA</STATE>
</Find__CompIntfc__STATE>
</soapenv:Body>
</soapenv:Envelope>

Below is a sample SOAP message from a PT 8.49x system.

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance/">
<soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>PTDMO </wsse:Username>
<wsse:Password>PTDMO</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<Get__CompIntfc__STATE>
<COUNTRY>USA</COUNTRY>
<STATE>CA</STATE>
</Get__CompIntfc__STATE>
</soapenv:Body>
</soapenv:Envelope>
7. Start SendMaster. You can do this either by executing StartSendMaster.bat found
in <PS_HOME>\sendmaster folder or the one in the PIA domain directory. To use
the standalone version <PS_HOME>\sendmaster folder set the PS_HOME
environment varilable to the PeopleTools root installation directory. You can do this
in the command line used to start SendMaster (see example below).

20
8. Create a new Input File type SendMaster (File > New Project)
a) Server URL needs to point to the PeopleSoftServiceListeningConnector, and it
comes from the WSDL file. For example,
http://gsplas144.us.oracle.com:7061/PSIGW/PeopleSoftServiceListeningConnector

21
 b) Header Section – Ensure that the SOAPAction is included in addition to the
Content-Type and charset settings. Unless you created an Alias for the Service
Operation the SOAPAction will default to the Service Operation name. The
WSDL file contains the SOAPAction entry for each Service Operation. Ensure
that the SOAPAction entry in SendMaster matches the entry in the WSDL file.

SOAPAction:CI_STATE_F.V1

c) Paste the sample SOAP request into the Input file window, press the format
(right-most) button to ensure the XML is well formed. Below is a sample after
posting the request.

URL that you’re posting to comes from the generated wsdl:

http://gsplas144.us.oracle.com:7061/PSIGW/PeopleSoftServiceListeningConnector

Header (second line comes from the wsdl file, and the end point URL come from wsdl
file). Note that the SOAPAction value also comes from the wsdl file.

22
Content-type: text/xml; charset=UTF8
SOAPAction:CI_STATE_F.V1

Request
<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<Find__CompIntfc__STATE
xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/M760694.V1">
<COUNTRY>USA</COUNTRY>
<STATE>CA</STATE>
</Find__CompIntfc__STATE>
</soapenv:Body>
</soapenv:Envelope>

Response
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body>

<Find__CompIntfc__STATEResponse
xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/M953815.V1"><STATE><C
OUNTRY>USA</COUNTRY><STATE>CA</STATE></STATE></Find__CompIntfc
__STATEResponse></soapenv:Body> </soapenv:Envelope>

9. If you want to view the synchronous inbound messages in the Message Monitor,
do the following.
a) Open the Service operation, click on the Routing tab. On the Routing tab click on
the Routing definition link to open the Routing definition.
b) Specify the level of logging you want on the Routing definition. There are three
levels, None (Default), Header, and Header and Details. Below is a screenshot of
what the Routing definition would look like.

23
c) Below is a screenshot of the Message Monitor showing one of the inbound
messages. The second screenshot below shows the Details page (result of clicking
on the Details link below).

24
d) Note on monitoring SOAP requests: SOAP requests will go to an Error status if
an error occurs at the IB infrastructure level. Otherwise the request will go to a
DONE status. This is unlike typical Asynchronous messages, in which the DONE
status means that the transaction was successful. Using the Monitor to see
whether a request went to an Error or DONE status is inadequate. The calling
application needs to check the response message to determine whether the request
was successful or not. Below are two examples, one in which the request goes to
an Error status, while the other goes to a DONE status. So, it is important for the
calling application

25
i) Example of a request that went to an Error status – The system could not
determine the CI name or method to be used. Below are two screenshots of
the Monitor.

26
 ii) Below is an example of a request that went to DONE status even though the
request was not successful (logic error) – The request attempted to create a
duplicate record.

Below is a copy of the response message:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Component Interface API.</faultstring>
<detail>
<IBResponse type="Error">
<DefaultTitle>Integration Broker Response</DefaultTitle>
<StatusCode>20</StatusCode>
<MessageSetID>91</MessageSetID>
<MessageID>49</MessageID>
<DefaultMessage>Row already exists with the specified keys. {STATE} (91,49)</DefaultMessage>
<MessageParameters>
<keyinformation>
<COUNTRY>USA</COUNTRY>
<STATE>MZ1</STATE>
</keyinformation>
</MessageParameters>
</IBResponse>
<IBResponse type="Error">
<DefaultTitle>Integration Broker Response</DefaultTitle>
<StatusCode>20</StatusCode>
<MessageSetID>91</MessageSetID>
<MessageID>61</MessageID>
<DefaultMessage>Failed to create the Component Interface</DefaultMessage>
<MessageParameters>
<keyinformation>
<COUNTRY>USA</COUNTRY>
<STATE>MZ1</STATE>
</keyinformation>
</MessageParameters>

27
 </IBResponse>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

10. Notes on the new WSDLs – The WSDLs in PT 8.48 and later, unlike the pre –
PT 8.48 WSDLs, reference external xsd (schema) files instead of including the
schemas in the WSDL. They also refer to “WS-SecurityPolicy” instead of explicitly
spelling out the specifics of the security portion of the soap header. It appears that
PeopleSoft uses and supports ws- security policy version 1.0. Given this you may not
see the username token automatically generated in the client stub code. In some cases
it may be simply a configuration change to get it generated, while in other cases your
web service client code needs to explicitly call certain functions/methods (provided
by the tool vendor) that will do this.

The following is information provided by internal sources regarding .NET and

whether it supports WS-SecurityPolicy, etc. You'll want to do some additional
research and work with your vendor as well, even if you’re not using .NET. If
using .NET, depending on the version of the .NET framework being used, .NET may
or may not be able to handle or simply ignore WS-SecurityPolicy references in the
WSDL. For example, if you're using .NET framework 2.0, it doesn't handle ws-
security policy. Later versions of .NET (3.0+) handle ws- security policy back to v.
1.2 (not 1.0). .NET version 3.0+ generates policy assertion code in the client stub
code, and the client application still needs to invoke a certain function, which in turn
invokes the assertion code to include the username token. PeopleSoft uses ws-
security policy to describe the ws-security username token in the soap header. This
means that even even if the ws-policy is ignored by .NET (or another application
vendor when importing the WSDL), you're not really losing any functionality as far
as the username token goes. Your client program still needs to call a specific .NET
function (or other vendor’s function) to set the security credential if you want a
security token to be used when invoking the PeopleSoft web service. Below are a
couple of helpful links.

.NET v2.0 (with WSE v3) – See

http://msdn.microsoft.com/en-us/library/aa528757.aspx
Note: When the document in the above link refers to “policy”, it is specific to
Microsoft. It is not refering to WS-SecurityPolicy. Also see topic, "How to: Secure a
Client Without Using a Policy File".

.NET 3.0+ - See

http://msdn.microsoft.com/en-us/library/ms732362.aspx
Aso see topic "Message Security with a User Name Client"

11. Considerations when re-deploying the web service after making changes to the CI or
its underlying component – The following are steps you usually need to peform after
making changes to the CI and/or its underlying component.

28
a. If changes were made to the component, ensure there are no validation errors
when opening or testing the CI. If records and/or field names were modified or
deleted, you will need to "re-synchronize" the component fields to the CI's
properties. Then test the CI using CI tester in 3-tier (where you log into
Application Designer through the Application Server’s WSL port). If changes
were made to the component, it’s also a good idea to test the component online to
ensure it works as expected.

b. Delete Application Server cache, and restart the Application server. This is a
necessary step because the Application Server caches the CI’s Meta Data.

c. You should delete the web service (service operations, service, WSDL, etc.).
After this, expose the CI's methods again by going through the “CI-Based
Service” Wizard, and then re-generating the WSDL by going through the
“Provide Web Service” Wizard.

29