PeopleTools 8.51 PeopleBook: PeopleSoft Integration Broker

Providing Services

This chapter discusses how to:

Provide services.
Access generated WSDL documents.
Delete WSDL documents.

Understanding Providing Services

PeopleSoft Integration Broker features a Provide Web Service wizard that steps you through the task of providing web services.

Understanding the Provide Web Service Wizard

This section provides an overview of the Provide Web Service wizard.

Features of the Provide Web Service Wizard

The Provide Web Service component (IB_WSDL_EXPORT) features a wizard you can use to provide web services. You can publish WSDL documents to the WSDL repository in the PeopleSoft system or publish WSDL documents to external UDDI repositories.

After you generate a WSDL document, the Provide Web Service wizard displays a WSDL URL for each document you generated. This enables you to access the WSDL document content using the WSDL URL. In addition, PeopleSoft Integration Broker provides a WSIL URL which lists the provided services and corresponding WSDL URLs.

You can use the Provide Web Service wizard to select one or more services for which to generate WSDL documents. The system generates a separate WSDL document for each service.

Other features include:

Supports WS-interoperability standards for WSDL.
Provides WSDL version 1.1 documents.
Provided WSDL documents include WS-Addressing header elements for asynchronous request/response operation types.
Provided WSDL documents include WS-Security elements . UsernameToken and SAMLToken types are supported.
Provided WSDL documents include PartnerLinkType elements, which are used when consumed by a BPEL application.

Operation Types Supported

The Provide Web Service wizard can create WSDL documents for service operations having the following operation types:

Synchronous.
Asynchronous one-way.
Asynchronous request/response.

Requirements for Nonrowset-Based Message Schemas

This section discusses requirements and considerations for creating nonrowset-based message schemas for service operations in order to generate WSDL documents using the Provide Web Service wizard.

Note. The PeopleSoft system automatically generates message schemas for rowset-based messages.

Target Namespace

Nonrowset-based message schemas must contain a target namespace. If no target namespace exists in the schema an error occurs when the system generates the WSDL document.

You may define multiple schema imports to the same target namespace, but different schema locations must be defined.

Multiple Root Element and Complex Type Tags

If the PeopleSoft system finds multiple root <element> or <complexType> tags in nonrowset-based message schemas, only the first one is referenced in the WSDL document or container message schema.

In addition, the WSDL would allow schema imports to the same target namespace but different schema locations and use <xsd:include> when the schema Namespace is same as the WSDL namespace.

See Also

Prerequisites for Providing Services

Locations for Publishing WSDL Documents

Using the Provide Web Service wizard, you can publish WSDL documents to the follow locations:

PeopleSoft WSDL repository. (Application database.)

The PeopleSoft WSDL repository is the default publishing location. All generated WSDL documents are published to the PeopleSoft WSDL repository. You may publish WSDL documents to a UDDI repository in addition to the WSDL repository.
Universal Description, Discovery, and Integration (UDDI) repositories.

Services published to UDDI repositories are available to other PeopleSoft and external systems. If another PeopleSoft system wants to invoke an exported service from UDDI, it can consume the WSDL document from the UDDI reference into its system to create a service and routing definition.

UDDI Repositories and Endpoints

When publishing a WSDL document to a UDDI repository, the PeopleSoft system publishes the current endpoint value defined in the Target Location field in the Service Configuration page.

The endpoint value in the actual WSDL document is a dynamic one, since you can change the target location value, for example, when you move from development to production.

If you change the target location you should change the endpoints of previously published WSDL documents, either manually in the UDDI registry or by republishing the WSDL documents to your UDDI repository using the changed endpoint.

WSDL URL Formats

After you a publish a WSDL document using the Provide Web Service wizard, the system displays a WSDL URL. The URL provided is the path to the WSDL document location in the WSDL repository in the PeopleSoft Pure Internet Architecture. The URL is used by external systems that will be invoking a PeopleSoft service.

The default URL format is path style. The following example shows a WSDL URL in path format:

http://localhost/PSIGW.war/PeopleSoftServiceListeningConnector/PT_WORKLIST.1.wsdl

The path style URL is generated by appending the WSDL document name to the target location value specified in the Service Configuration page.

PeopleSoft Integration Broker also supports a query parameter format. The following example shows a WSDL URL in query parameter format:

http://PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=PT_WORKLIST.1

The query parameter style URL is generated by passing either the WSDL document name or service name.version or service alias.version as a query parameter.

PeopleSoft still supports the query parameter format, however path format is preferred. Note that if using query parameter format, manual intervention may be required if the schema target location is changed.

Provided WSDL Documents

Every WSDL document you generate using PeopleSoft Integration Broker is divided into sections. This section describes the WSDL document sections and provides an example of the WSDL template that the PeopleSoft system uses to generate WSDL, as well as example WSDL documents for each of the supported operation types.

Sections of Provided WSDL Documents

WSDL documents that you provide using PeopleSoft Integration Broker contain the following sections:

Section	Description
<definitions>	Specifies the namespaces for the WSDL document, W3C XML Schema and SOAP. A unique namespace will be captured from the Service definition, which will be used to define the WSDL namespaces. The format of this namespace is as follows: http://xmlns.oracle.com/Enterprise/<App Name>/<Service Name>. When a service is defined within an application database, the namespace field is defaulted to the service namespace defined on the Service Configuration page.
<partnerLinktype>	A partnerLinkType defines the role of services and the port Type.
<types>	Captures the simple and complex types required by the schema of the request and response message definitions of the service operations. For services with component interface handlers, some of the system methods, such as Create and Get, will require complex message types resembling the structure of the component interface buffer.
<message>	Defines the abstract messages required for the selected operations. The data types for these are obtained from the Types section of the WSDL document.
<portType>	Features a named set of abstract operations and the abstract messages involved. This section includes all operations of the service selected for export.
<binding>	Specifies the network protocol and data format of messages used for a specific port type. For providing web services PeopleSoft utilizes SOAP packaging and HTTP transport protocols. The data format of messages is the Document style format.
<operation>	This is an abstract definition of a service operation, which specifies request/response/fault messages.
<service>	A service groups together endpoints that implement a common interface.

Note. In WSDL documents generated by the PeopleSoft system, WS-Security policies are assigned to the bind operation section.

Example 1: WSDL Template

The following example is the WSDL document template that the PeopleSoft system uses when it generates WSDL documents. The elements in bold are WSDL document sections discussed in the previous section:

definitions name="DefinitionsName"
  targetNamespace="NamespaceURI"
  xmlns:prefix="NamespaceURI"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.xmlsoap.org/wsdl/">
  <plnk:partnerLinkType name="PartnerLinkTypeName">
    <!-- Provider Role -->
       <plnk:role name="ProviderRoleName"> 
	      <plnk:portType name="ProviderPortTypeReference">
        </plnk:role>
  <!-- In case of Async Request/Response this role is also required -->
  <plnk:role name="RequestorRoleName"> 
	   <plnk:portType name="CallbackPortTypeReference">
     </plnk:role>
    </plnk:partnerLinkType>
<types>
    <!-- One or more schemas -->
  </types>
  <message name="MessageName">
    <part name="PartName" type="TypeNameReference"/>
  </message>
  <portType name="PortName">
    <operation name="OperationName">
      <input message="MessageNameReference"/>
      <output message="MessageNameReference"/>
      <fault message="MessageNameReference"/>
    </operation>
  </portType>
  <binding name="BindingName" type="PortNameReference">
    <soap:binding style="rpc|document"
      transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="OperationName">
      <soap:operation soapAction="ActionValue"/>
      <input>
        <soap:body
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace="TargetNamespace"
          use="encoded"/>
     </input>
     <output>
      <soap:body
        encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
        namespace="TargetNamespace"
        use="encoded"/>
     </output>
    </operation>
  </binding>
  <service name="ServiceName">
    <port name="PortName" binding="BindingNameReference">
      <soap:address location="URL"/>
   </port>
  </service>
</definitions>

Example 2: Synchronous WSDL Example

The following example shows a synchronous WSDL document provided by the PeopleSoft system:

<?xml version="1.0" ?> 
<wsdl:definitions name="PT_WORKLIST.1" 
  targetNamespace="http://xml.namespace.oracle.com/services" 
  xmlns:GetWorklistEntryStatusRequest.v1="http://xmlns.oracle.com/
   Enterprise/Tools/schemas/PT_WL_GET_INSTANCE_REQ_CONT.v1" 
  xmlns:GetWorklistEntryStatusResponse.v1="http://xmlns.oracle.com/
   Enterprise/Tools/schemas/PT_WL_GET_INSTANCE_RESP_CONT.v1" 
  xmlns:OperationFault.V1="http://xmlns.oracle.com/schemas/Fault" 
  xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" 
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http:
   //xml.namespace.oracle.com/services" 
  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="PT_WORKLIST_PartnerLinkType">
    <plnk:role name="PT_WORKLIST_Provider">
      <plnk:portType name="tns:PT_WORKLIST_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/PT_WL_GET_INSTANCE_REQ_CONT.v1" schemaLocation="Get
        WorklistEntryStatusRequest.v1.xsd" /> 
      <xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/
        schemas/PT_WL_GET_INSTANCE_RESP_CONT.v1" schemaLocation="
         GetWorklistEntryStatusResponse.v1.xsd" /> 
      <xsd:import namespace="http://xmlns.oracle.com/schemas/Fault" 
       schemaLocation="OperationFault.V1.xsd" /> 
     </xsd:schema>
    </wsdl:types>
  <wsdl:message name="GetWorklistEntryStatusRequest.v1">
    <wsdl:part element="GetWorklistEntryStatusRequest.v1:GetWorklist
     EntryStatusRequest" name="parameter" /> 
  </wsdl:message>
  <wsdl:message name="GetWorklistEntryStatusResponse.v1">
    <wsdl:part element="GetWorklistEntryStatusResponse.v1:GetWorklist
     EntryStatusResponse" name="parameter" /> 
  </wsdl:message>
  <wsdl:message name="OperationFault.V1">
    <wsdl:part element="OperationFault.V1:OperationFault" name="parameter" /> 
  </wsdl:message>
  <wsdl:portType name="PT_WORKLIST_PortType">
  <wsdl:operation name="GetWorklistEntryStatus">
    <wsdl:documentation>Get worklist keys and status</wsdl:documentation> 
    <wsdl:input message="tns:GetWorklistEntryStatusRequest.v1" name=
     "GetWorklistEntryStatusRequest.v1" /> 
    <wsdl:output message="tns:GetWorklistEntryStatusResponse.v1" name=
     "GetWorklistEntryStatusResponse.v1" /> 
    <wsdl:fault message="tns:OperationFault.V1" name="OperationFault.V1" /> 
   </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="PT_WORKLIST_Binding" type="tns:PT_WORKLIST_PortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/
      soap/http" /> 
    <wsdl:operation name="GetWorklistEntryStatus">
      <soap:operation soapAction="GetWorklistEntryStatus.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="GetWorklistEntryStatusRequest.v1">
       <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
        use="literal" /> 
     </wsdl:input>
     <wsdl:output name="GetWorklistEntryStatusResponse.v1">
       <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
        use="literal" /> 
     </wsdl:output>
     <wsdl:fault name="OperationFault.V1">
       <soap:fault encodingStyle="http://schemas.xmlsoap.org/soap/
         encoding/" name="OperationFault.V1" use="literal" /> 
     </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="WorklistServices">
    <wsdl:documentation>Peopletools Worklist</wsdl:documentation> 
    <wsdl:port binding="tns:PT_WORKLIST_Binding" name="PT_WORKLIST_Port">
      <soap:address location="http://sbandyop-pc/PSIGW.war/PeopleSoftService
       ListeningConnector" /> 
      </wsdl:port>
    </wsdl:service>
  </wsdl:definitions>

Example 3: Asynchronous Request/Response WSDL Document

The following example shows an asynchronous request/response WSDL document provided by the PeopleSoft system:

<?xml version="1.0"?>
<wsdl:definitions name="PT_WORKLIST.1" 
targetNamespace="http://xml.namespace.oracle.com/services" 
xmlns:CreateWorklistEntryRequest.v1="http://xmlns.oracle.com/Enterprise/
  Tools/schemas/PT_WL_CREATE_REQUEST_CONT.v1" 
xmlns:CreateWorklistEntryResponse.v1="http://xmlns.oracle.com/Enterprise/
  Tools/schemas/PT_WL_CREATE_RESPONSE_CONT.v1" 
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://xml.
  namespace.oracle.com/services" xmlns:wsa="http://schemas.xmlsoap.org/ws/
  2003/03/addressing" 
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="PT_WORKLIST_PartnerLinkType">
    <plnk:role name="PT_WORKLIST_Provider">
      <plnk:portType name="tns:PT_WORKLIST_PortType"/>
    </plnk:role>
    <plnk:role name="PT_WORKLIST_Requester">
      <plnk:portType name="tns:PT_WORKLIST_CallbackPortType"/>
    </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/PT_WL_CREATE_REQUEST_CONT.v1" schemaLocation="CreateWorklist
        EntryRequest.v1.xsd"/>
      <xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/
        schemas/PT_WL_CREATE_RESPONSE_CONT.v1" schemaLocation="CreateWorklist
         EntryResponse.v1.xsd"/>
      <xsd:import namespace="http://schemas.xmlsoap.org/ws/2003/03/
        addressing" schemaLocation="http://schemas.xmlsoap.org/ws/2003/
        03/addressing/"/>
    </xsd:schema>
  </wsdl:types>
  <wsdl:message name="CreateWorklistEntryRequest.v1">
    <wsdl:documentation>Create worklist item Request</wsdl:documentation>
    <wsdl:part element="CreateWorklistEntryRequest.v1:CreateWorklist
      EntryRequest" name="parameter"/>
  </wsdl:message>
  <wsdl:message name="CreateWorklistEntryResponse.v1">
    <wsdl:part element="CreateWorklistEntryResponse.v1:CreateWorklist
      EntryResponse" name="parameter"/>
  </wsdl:message>
  <wsdl:message name="InitiateHeader">
    <wsdl:documentation>SOAP Header message for correlating Asynchronous 
       callback</wsdl:documentation>
    <wsdl:part element="wsa:MessageID" name="MessageID"/>
    <wsdl:part element="wsa:ReplyTo" name="ReplyTo"/>
  </wsdl:message>
  <wsdl:message name="CallbackHeader">
    <wsdl:documentation>SOAP Header message for callback Asynchronous 
       operation
    </wsdl:documentation>
    <wsdl:part element="wsa:RelatesTo" name="RelatesTo"/>
  </wsdl:message>
  <wsdl:portType name="PT_WORKLIST_PortType">
    <wsdl:operation name="CreateWorklistEntry">
      <wsdl:documentation>Create worklist Entry. This is the Request Operation 
        in a Asynchronous Request/Response pair. Callback Operation : 
          CreateWorklistEntry_CALLBACK</wsdl:documentation>
      <wsdl:input message="tns:CreateWorklistEntryRequest.v1" name="
         CreateWorklistEntryRequest.v1"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:portType name="PT_WORKLIST_CallbackPortType">
    <wsdl:operation name="CreateWorklistEntry_CALLBACK">
      <wsdl:documentation>Create worklist Entry - Callback. This is the 
         Callback Operation in a Asynchronous Request/Response pair.
      </wsdl:documentation>
      <wsdl:input message="tns:CreateWorklistEntryResponse.v1" name=
        "CreateWorklistEntryResponse.v1"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="PT_WORKLIST_Binding" type="tns:PT_WORKLIST_PortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.
      org/soap/http"/>
    <wsdl:operation name="CreateWorklistEntry">
      <soap:operation soapAction="CreateWorklistEntry.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="CreateWorklistEntryRequest.v1">
        <soap:header encodingStyle="" message="tns:InitiateHeader" part=
          "MessageID" use="literal" wsdl:required="false"/>
        <soap:header encodingStyle="" message="tns:InitiateHeader" part=
          "ReplyTo" use="literal" wsdl:required="false"/>
        <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
          use="literal"/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:binding name="PT_WORKLIST_CallbackBinding" type="tns:
     PT_WORKLIST_CallbackPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.
      org/soap/http"/>
    <wsdl:operation name="CreateWorklistEntry_CALLBACK">
      <soap:operation soapAction="CreateWorklistEntry_CALLBACK.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="CreateWorklistEntryResponse.v1">
        <soap:header encodingStyle="" message="tns:CallbackHeader" 
           part="RelatesTo" use="literal" wsdl:required="true"/>
        <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
           use="literal"/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="WorklistServices">
    <wsdl:documentation>Peopletools Worklist</wsdl:documentation>
    <wsdl:port binding="tns:PT_WORKLIST_Binding" name="PT_WORKLIST_Port">
      <soap:address location="http://ORACLE_ENDPOINT"/>
    </wsdl:port>
  </wsdl:service>
  <wsdl:service name="WorklistServices_Callback">
    <wsdl:documentation>Peopletools Worklist - Callback</wsdl:documentation>
    <wsdl:port binding="tns:PT_WORKLIST_CallbackBinding" name=
       "PT_WORKLIST_Callback_Port">
      <soap:address location="http://Client.EndPoint.Set.By.Caller"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Example 4: Asynchronous One-Way WSDL Document

The following example shows an asynchronous one-way WSDL document provided by the PeopleSoft system:

<?xml version="1.0" ?> 
<wsdl:definitions name="QEPC_FLO_MSG.1" targetNamespace="http://xmlns.
oracle.com/Enterprise/Tools/services/QEPC_FLO_MSG.1" 
   xmlns QEPC_FLO_MSG.VERSION_1="http://xmlns.oracle.com/Enterprise/
     Tools/schemas/QEPC_FLO_MSG.VERSION_1" 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/QEPC_FLO_MSG.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="QEPC_FLO_MSG_PartnerLinkType">
     <plnk:role name="QEPC_FLO_MSG_Provider">
       <plnk:portType name="tns:QEPC_FLO_MSG_PortType" /> 
     </plnk:role>
   </plnk:partnerLinkType>
   <wsdl:types>
     <xsd:schema elementFormDefault="qualified" 
       targetNamespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/
         QEPC_FLO_MSG.VERSION_1" 
       xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/
         QEPC_FLO_MSG.VERSION_1" 
       xmlns:xsd="http://www.w3.org/2001/XMLSchema">
       <xsd:element name="QEPC_FLO_MSG" type="xsd:string" /> 
     </xsd:schema>
   </wsdl:types>
   <wsdl:message name="QEPC_FLO_MSG.VERSION_1">
     <wsdl:part element="QEPC_FLO_MSG.VERSION_1:QEPC_FLO_MSG" name=
       "parameter" /> 
   </wsdl:message>
   <wsdl:portType name="QEPC_FLO_MSG_PortType">
   <wsdl:operation name="QEPC_FLO_MSG">
     <wsdl:documentation>Test</wsdl:documentation> 
     <wsdl:input message="tns:QEPC_FLO_MSG.VERSION_1" name="QEPC_FLO_
      MSG.VERSION_1" /> 
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="QEPC_FLO_MSG_Binding" type="tns:QEPC_FLO_MSG_
    PortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.
      org/soap/http" /> 
    <wsdl:operation name="QEPC_FLO_MSG">
      <soap:operation soapAction="QEPC_FLO_MSG.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="QEPC_FLO_MSG.VERSION_1">
          <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/
           encoding/" use="literal" /> 
        </wsdl:input>
      </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="QEPC_FLO_MSG">
      <wsdl:documentation>File Utilities Test</wsdl:documentation> 
      <wsdl:port binding="tns:QEPC_FLO_MSG_Binding" name="QEPC_FLO_MSG_Port">
        <soap:address location="http://sbandyop-pc/PSIGW.war/PeopleSoft
         ServiceListeningConnector" /> 
      </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

PartnerLinkType Support

A service may play a single or dual role in a partnership with a business process.

In a one-way partnership the service may play a single role of provider, whereas in a two-way partnership the service may play the roles of a provider as well as a requester (for callbacks). This type of partnership is termed by Business Process Execution Language (BPEL) as a PartnerLinkType.

A service may participate in different types of partnerships with a process or another service. In each of these partnerships, the service may play a single or dual role.

PartnerLinkType Structure

To ease the task of process developers consuming PeopleSoft services, a basic PartnerLinkType structure is provided in the PeopleSoft-provided WSDL. Process developers may or may not choose to use this PartnerLinkType structure.

The following table describes details of the PartnerLinkType structure for each service operation type:

Operation Type	PartnerLinkType Description
Synchronous	The PartnerLinkType has a single Provider role.
Asynchronous one-way	The PartnerLinkType has a single Provider role.
Asynchronous Request/Response	The PartnerLinkType has two roles for the Provider portType and the Requester Callback portType.

The following sections feature examples of the PartnerLinkType structures the PeopleSoft system generates for each service operation type.

Example 1: Synchronous PartnerLinkType Structure

The following example shows the PartnerLinkType structure that the PeopleSoft system generates for an inbound synchronous service operation:

<portType name="HelloWorldSync">
        <operation name="process">	
            <input message="client:HelloWorldSyncRequestMessage"/>
            <output message="client:HelloWorldSyncResponseMessage"/>
        </operation>
    </portType>

    <plnk:partnerLinkType name="HelloWorldSyncPLType">
        <plnk:role name="HelloWorldSyncProvider">
              <plnk:portType name="wsdl_target:HelloWorldSync"/>
        </plnk:role>
      </plnk:partnerLinkType>

Example 2: Asynchronous One-Way PartnerLinkType Structure

The following example shows the PartnerLinkType structure that the PeopleSoft system generates for an inbound asynchronous one-way service operation.

<portType name="UpdateOrderAsync">
        <operation name="UpdateOrder">
            <input message="client:OrderRequestMessage"/>
        </operation>
    </portType>

    <plnk:partnerLinkType name="UpdateOrderAsyncPLType">
        <plnk:role name="UpdateOrderAsyncProvider">
              <plnk:portType name="wsdl_target:UpdateOrderAsync"/>
        </plnk:role>
      </plnk:partnerLinkType>

Example 3: Asynchronous Request/Response PartnerLinkType Structure

The following example shows the PartnerLinkType structure that the PeopleSoft system generates for an inbound asynchronous request/response service operation:

<!--
  PortType definition
  -->

    <!-- portType implemented by the QuoteConsumer PeopleSoft service -->
    <portType name="QuoteConsumer">
        <operation name="GetQuote">
            <input message="tns:QuoteConsumerRequestMessage"/>
        </operation>
    </portType>

    <!-- portType implemented by the requester of QuoteConsumer PeopleSoft service
         for asynchronous callback purposes
         -->
    <portType name="QuoteConsumerCallback">
        <operation name="GetQuoteCallback">
            <input message="tns:QuoteConsumerResultMessage"/>
        </operation>
    </portType> <!--
  PartnerLinkType definition
  -->

    <!-- the QuoteConsumer partnerLinkType binds the service and
         requestor portType into an asynchronous conversation.
         -->
    <plnk:partnerLinkType name="QuoteConsumerPLType">
        <plnk:role name="QuoteConsumerProvider">
              <plnk:portType name="wsdl_target:QuoteConsumer"/>
        </plnk:role>
        <plnk:role name="QuoteConsumerRequester">
              <plnk:portType name="wsdl_target:QuoteConsumerCallback"/>
        </plnk:role>
      </plnk:partnerLinkType>   
</definitions>

WSDL Document Versioning

When the Service System Status in the Services Configuration page is set to Production and you attempt to regenerate a WSDL document for a service, PeopleSoft Integration Broker versions and stores the WSDL document in the WSDL repository under the following condition: You have previously generated a WSDL document for the same service and new service operations have been added that you selected to include in the new WSDL document.

In this case, the system appends a version number to the service namespace to enable unique qualification of elements and attributes in the new WSDL version. The new version number is also appended to the WSDL document name. The latest WSDL document version is marked as Default in the WSDL repository.

When the Service System Status in the Services Configuration page is set to Development and you regenerate a WSDL document for a service, the existing WSDL document is overwritten.

Multiple WSDL versions generated from the same service display in a grid on the Services page and include a timestamp and version for each generated WSDL document. Only one of these can be the default version.

Viewing WSDL Documents Generated for Services

Prerequisites for Providing Services

The following prerequisites exist for providing services:

The PeopleSoft system must be configured for handling services. Use the Services Configuration page to define the service namespace, schema namespace, target location and service system status.
If publishing services to a UDDI repository you must:
- Have the UDDI server set up, configured and running.
- Have business entities and categories set up on the UDDI server that you intent to query from the Provide Web Service wizard.
- Specify the UDDI server and other relevant information within the PeopleSoft system using the Services Configuration-UDDI Configuration page.
Service operations in services to provide must have any-to-local routing definitions defined.
There must be a minimum of one service operation associated with the service that you select for which to generate a WSDL document.
For services that contain service operations with nonrowset-based messages, schemas must exist. The message schema must contain a target namespace. If no target namespace exists an error will occur when the system attempts to generate the WSDL document.

PeopleSoft automatically generates schema for services that contain operations with rowset-based messages.

Specifying UDDI Repositories in PeopleSoft Systems for Providing and Consuming Services

Managing Service Operation Routing Definitions

Managing Service Operations

Building Message Schemas

Common Elements Used in This Chapter

Description	Description of the service, service operation or WSDL source.
Fault Message	Name of the fault message. Depending on how generated, the name of the fault message can include the version in the following format: MessageName.Version.
Operation Type andOperation	Type of service operation. See Service Operation Types.
Request Message	Name and version of the request message in the following format: MessageName.Version.
Response Message	Name and version of the response message in the following format: MessageName.Version.
Routing External Alias	External Alias from the routing definition for a service operation. Unless overridden, defaults to the format OperationAlias.Version.
Select	Check the box to select the WSDL service.
Service	Name of the service that contains the service operations to include in the generated WSDL documents.
Service Operation	Name of the service operations for which to generate WSDL documents.

Providing Services

This section discusses how to use the Provide Web Service wizard to:

Select services to provide.
Select service operations.
View WSDL documents.
Specify publishing options.
View the WSDL Generation Log.

Understanding Using the Provide Web Service Wizard

The Provide Web Service component (IB_WSDLEXP_SRCH) features a wizard you can use to provide web services. You can publish WSDL documents to the WSDL repository in the PeopleSoft system or external UDDI repositories.

After you generate a WSDL document, the Provide Web Service wizard displays a WSDL URL for each document you generated. This enables you to access the WSDL document content using the WSDL URL. In addition, you can modify the URL to access the WSDL document content using a WSIL URL.

Note. For a service to be available to provide, an any-to-local routing must exist for the service. In addition, there must be a minimum of one service operations associated with the service.

You can use the Provide Web Service wizard to select one or more services for which to generate WSDL documents. A separate WSDL document is generated for each service.

See Also

Prerequisites for Providing Services

Step 1: Select Services to Provide

Use the Select Services page (IB_WSDLEXP_SRCH) to search for and select the services that contain the service operations to include the WSDL documents that you generate. The following example shows the page:

You can search by the full or partial service name and service description. You can also search by object owner ID, if one is defined for the service. You can enter one or more of these criteria when performing your search.

To select services to provide:

Access the Provide Web Service Wizard – Select Services page (PeopleTools, Integration Broker, Web Services, Provide Services).
Enter search criteria for the services to provide by performing one or more of the following:
- In the Service Name field, enter a full or partial service name.
- In the Description field, enter the full or partial description of the service.
- From the Object Owner ID drop-down list box, select the object owner of the service to provide.
- Select no search criteria to retrieve a list of all services in the database for which any-to-local routing definitions have been generated.
Click the Search button.

A Services grid appears that contains the search results.

The search results only list services which have at least one service operation with an any-to-local routing.
Check the box next to each name of the services to provide.

To clear a selection, check the box again.
Click the Next button to proceed to the next step in the wizard, selecting service operations.

Step 2: Select Service Operations

The following graphic shows the Select Service Operations page (IB_WSDL_EXP_OPER):

Use the page to select the service operations from each service that you selected in the previous step to include in the WSDL document.

The Use Service Alias in WSDL option on the page enables you to specify that the system use the service alias name in the generated WSDL, rather than the actual service name.

The Use Secure Target Location option enables you to export the WSDL to the URL specified in the Secure Target Location field on the Service Configuration page. If you do not check this option, WSDL is exported to the URL specified in the Target Location field on the Service Configuration page.

To select service operations to include in a WSDL document:

Check the box next to each service operation to include.

To clear a selection, check the box again.
(Optional) Select the Use Service Alias in WSDL check box to include the alias name for the service in the generated WSDL instead of the actual service name.
Click the Next button to proceed to the next step in the wizard.

The next step to providing WSDL documents is previewing the WSDL document that will be provided.

See Also

Target Locations

Step 3: View WSDL Documents

After you select the service operations to include in a WSDL document, you can preview the WSDL before actually publishing it.

The following graphic shows the View WSDL page (IB_WSDLEXP_PVIEW). Use the page to preview a WSDL document before you actually generate it.

Each service for which a WSDL document will be generated is listed. Click theView WSDL link to view the WSDL document for each service that you have selected.

When you click the View WSDL link, the WSDL displays in the WSDL Viewer page (IB_WSDEXPPVIEW_SEC). The following example shows the WSDL document for the QE_PO service in the WSDL Viewer page.

To preview WSDL documents:

Click the View WSDL link for a service.

The WSDL document for the service appears in the WSDL Viewer.
Click the Return button to return to the View WSDL page.
Click the Next button to proceed to the next step in the wizard.

The next section discusses the next step to providing a service, selecting the location of where to publish the WSDL documents.

Step 4: Specify Publishing Options

After you preview the WSDL, use the Specify Publishing Options page (IB_WSDLEXP_LOC) to specify the publish location of the generated WSDL documents. The following graphic shows the page:

By default the system publishes all WSDL documents to the PeopleSoft WSDL repository.

Select the Publish to UDDI check box to publish the WSDL to a UDDI repository in addition to the PeopleSoft WSDL repository.

Providing WSDL Documents to UDDI Repositories

Before providing a WSDL document to a UDDI repository, you must configure the UDDI repository in the PeopleSoft system.

See Specifying UDDI Repositories in PeopleSoft Systems for Providing and Consuming Services.

When you select the Publish to UDDI check box, the Select UDDI Servers box appears where you specify the UDDI repository to which to publish the WSDL. The following graphic shows the Select UDDI Servers section:

To provide a WSDL document to a UDDI repository:

From the UDDI Name drop-down list box, select the UDDI server to which you are publishing the WSDL.
Click the Get Bus. Entities button.

The Select Business Entity section lists the business entities that are available to select for the UDDI server.
Check the box next to each business entity name to include.
Click the UDDI Category Name lookup button to display a list of UDDI categories and select a UDDI category. Click the OK button.
In the Category Value field, enter a value for the category.
To add additional categories, in the Select UDDI Categories section, click the plus button to add a row and repeat step 5 and step 6.
Click the Finish button.

The Results page appears and displays the WSDL generation log.

Step 5: View the WSDL Generation Log

Use the Results page shown in the following example to view the WSDL Generation Log:

The WSDL Generation Log provides the name of the services and URL for each WSDL document generated.

You can cut and paste the URL into a browser to access the WSDL document. You can also access the WSDL document using the WSDL repository.

To provide another service, click the Provide Another Service button and return to step 1 of the wizard.

You can also click the Generate SOAP Template button to access the Generate SOAP utility to generate SOAP message templates for request messages, response messages and fault messages found in the WSDL document. You can then use the templates to test SOAP messages in the Handler Tester, Transformation Test Tool and Send Master utilities.

Accessing Generated WSDL Documents

This section discusses how to:

Use WSDL URLs to access generated WSDL documents.
Use the WSDL repository to access generated WSDL documents.

Using WSDL URLs To Access Generated WSDL Documents

The last page of the Provide Web Service wizard, the Confirm Results page (IB_WSDLEXP_RSLTS), displays a WSDL generation log. The text box contains WSDL URLs for each WSDL document you generated.

To access the WSDL, copy a WSDL URL from the WSDL generation log and paste it into a browser of your choice to access the WSDL document.

Using the WSDL Repository to Access Generated WSDL Documents

Access the WSDL Repository page (PeopleTools, Integration Broker, Integration Setup, Services. Click the View WSDL link.)

The following example shows the WSDL Repository page:

The WSDL Repository page lists the WSDL documents that exist for a service.

The previous example shows the two WSDL documents, QE_PO_ASYNC and QE_ROUTE_ARR, that were exported using the Provide Web Service wizard.

The selected and disabledDefault check box indicates the default WSDL document for the service. The WSDL document last generated is the default version.

Note. Default WSDL documents for a service are used only when the service system status is Production.

To change the default version, you must provide the service again, and choose a different set of service operations to include in the new default version.

Descriptions of the other fields displayed on this page are discussed at the beginning of this chapter.

See Common Elements Used in This Chapter.

To access the WSDL document, click the View WSDL link. the WSDL Viewer page appears and displays the content of the WSDL document. The following example shows the WSDL Viewer displaying the QE_PO.1 WSDL document:

Click the Return button to return to the WSDL Repository page.

See Also

WSDL Document Versioning

Deleting WSDL Documents

This section discusses how to delete WSDL documents.

Understanding Deleting WSDL Documents

The service system status affects the ability to delete WSDL documents.

See Understanding Configuring PeopleSoft Integration Broker for Handling Services, Setting Service Configuration Properties.

Deleting a WSDL Document

Use the Service Administration-WSDL page to delete WSDL documents generated for a service. The following example shows the page:

To delete a WSDL document

Access the Services Administration - WSDL page (select PeopleTools, Integration Broker, Service Utilities, Service Administration).
Click the arrow next to the Delete section header to expand the section.
In the Service field, enter the name of the service that contains the WSDL document to delete, and click the Search button.

Search results appear in the results grid.
In the results grid, select the check box next to the WSDL document to delete.
Click the Delete button.

The Clear WSDL Export Status link that appears on this page is discussed elsewhere in this PeopleBook.

See Resolving Inconsistencies in Exported WSDL.