Providing Services

This chapter discusses how to:

Click to jump to parent topicUnderstanding Providing Services

This chapter describes how to provide services using the Provide Web Service wizard, access generated WSDL and WADL documents, and delete WSDL and WADL document.

The chapter also describes WSDL and WADL documents that the system generates.

Note. The code examples in this chapter are for illustrative purposes only and are not intended to be used in a production environment.

Click to jump to parent topicUnderstanding the Provide Web Service Wizard

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

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

After you generate a WSDL or WADL document, the Provide Web Service wizard displays a URL for each document you generated. This enables you to access the WSDL document or WADL document content using the 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 or WADL documents. The system generates a separate document for each service.

Click to jump to parent topicUnderstanding Providing WSDL Documents

This section provides an overview of provided WSDL documents provided by the Provide Web Service wizard.

Click to jump to top of pageClick to jump to parent topicWSDL Features

Provided WSDL documents include support WS-interoperability standards for WSDL and include:

In addition, provided WSDL document feature PartnerLinkType elements which are used when consumed by a BPEL application.

Click to jump to top of pageClick to jump to parent topicWSDL Document Specifications

Integration Broker can provide WSDL documents in WSDL 1.1 or WSDL 2.0 format. By default, the Provide Web Service wizard used to provide WSDL documents generates WSDL in 1.1 format and features and option to generate WSDL documents in WSDL 2.0 format.

See Step 1: Select Services to Provide.

The following graphic illustrates the differences between WSDL 1.1 and WSDL 2.0 documents at the abstract and concrete layers:

Abstract and concrete layers of WSDL 1.1 and WSDL 2.0 documents

Additional information about the elements in WSDL 1.1 documents and WSDL 2.0 documents is provided elsewhere in this chapter.

See Provided WSDL Documents.

Click to jump to top of pageClick to jump to parent topicSupported Operation Types for WSDL Documents

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

Click to jump to top of pageClick to jump to parent topicRequirements 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

Click to jump to top of pageClick to jump to parent topicLocations for Publishing WSDL Documents

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

Click to jump to top of pageClick to jump to parent topicUDDI 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.

Click to jump to top of pageClick to jump to parent topicWSDL 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.

Click to jump to top of pageClick to jump to parent topicProvided 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

WDSL 1.1 Description

WSDL 2.0 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.

NA.

The <description> element serves the same purpose in WSDL 2.0 documents.

See <description>.

<description>

NA.

The <definitions> element serves the same purpose in WSDL 1.1 documents.

See <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.

No change from WSDL 1.1.

See WSDL 1.1 description.

<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.

No change from WSDL 1.1.

See WSDL 1.1 description.

<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.

There are no <message> elements in WSDL2.0. Instead, the operations within the interface refer to the schema elements directly.

<portType>

Features a named set of abstract operations and the abstract messages involved. This section includes all operations of the service selected for export.

NA.

See <interface>

<interface>

NA

See <portType>

WSDL 2.0 features an <interface> element that replaces the <portType> element in WSDL 1.1.

Unlike the <portType> element in WSDL 1.1, the operations within the <interface> element do not point to messages, but instead point to the schema elements contained within the <types> element.

<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.

No change from WSDL 1.1.

See WSDL 1.1 description.

<operation>

This is an abstract definition of a service operation, which specifies request/response/fault messages.

No change from WSDL 1.1.

See WSDL 1.1 description.

<service>

A service groups together endpoints that implement a common interface.

No change from WSDL 1.1.

See WSDL 1.1 description.

<port>

In WSDL 1.1 the <port> element contains the definition of the address to which the client should request the service. The <port> element also has reference to binding used by the service

NA.

See <endpoint>.

<endpoint>

NA.

See <port>.

In WSDL 2.0 the <port> element is replaced by the <endpoint> element. The location attribute of endpoint contains the definition of the address to which the client should request the service. The <endpoint> element also has reference to binding used by the service

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>

Click to jump to top of pageClick to jump to parent topicPartnerLinkType 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>

Click to jump to parent topicUnderstanding WADL Documents

This section discusses WADL documents.

Click to jump to top of pageClick to jump to parent topicSupported Operation Types for WADL Documents

PeopleSoft Integration Broker provides WADL documents for REST services only. REST services are synchronous service operations.

Click to jump to top of pageClick to jump to parent topicLocations for Publishing WADL Documents

Using the Provide Web Service wizard, you can publish WADL documents to the PeopleSoft WSDL repository in the PeopleTools database.

You can access a WADL document in the WSDL Repository using the Services component or by using the URL generated by the Provide Web Service Wizard when you provide a REST service.

See Also

Accessing Generated WSDL Documents and WADL Documents

Click to jump to top of pageClick to jump to parent topicWADL URL Format

After you a publish a WADL document using the Provide Web Service wizard, the system displays a WADL URL. The URL provided is the path to the WADL document 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 WADL URL format is path style. The following example shows a WADL URL in path format where the service provided is QE_WEATHERSTATION:

http://<machine>:<port>/PSIGW/RESTListeningConnector/QE_WEATHERSTATION.1.wadl

Click to jump to top of pageClick to jump to parent topicProvided WADL Documents

Every WADL document you generate using PeopleSoft Integration Broker is divided into sections. This section describes the WADL document sections and provides an example of a WADL document generated by the system.

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

<?xml version="1.0"?>
<application xmlns="http://xmlns.oracle.com/Enterprise/Tools/services" 
xmlns:QE_FLIGHTPLAN_SYNC.VERSION_1="http://xmlns.oracle.com/Enterprise/
Tools/schemas/QE_FLIGHTPLAN_SYNC.VERSION_1" xmlns:WEATHERDATA.v1="http:
//xmlns.oracle.com/Enterprise/Tools/schemas/WEATHERDATA.v1" xmlns:
WEATHER_FAULT.v1="http://xmlns.oracle.com/Enterprise/Tools/schemas/
Weather.Weather_Fault.v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
  <grammars>
    <include href="WEATHERDATA.v1.xsd"/>
    <include href="WEATHER_FAULT.v1.xsd"/>
    <include href="QE_FLIGHTPLAN_SYNC.VERSION_1.xsd"/>
  </grammars>
  <resources base=" http://kcollins-t61/PSIGW/RESTListeningConnector/
   QE_LOCAL">
    <resource uri="WeatherStation.v1">
      <method href="#GETWeatherStation.v1"/>
      <method href="#HEADWeatherStation.v1"/>
      <method href="#POSTWeatherStation.v1"/>
      <method href="#PUTWeatherStation.v1"/>
      <method href="#DELETEWeatherStation.v1"/>
    </resource>
  </resources>
  <method id="DELETEWeatherStation.v1" name="DELETE">
    <request>
      <resource path="weather/{state}/{city}?forecast={day}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
        <param name="day" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}/{city}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}">
        <param name="state" required="true" style="template" type="xsd:string"/>
      </resource>
    </request>
    <response Status="200">
      <representation element="WEATHERDATA.v1:WeatherInfo" id="WEATHERDATA.v1.xsd" 
       mediaType="text/xml"/>
    </response>
  </method>
  <method id="GETWeatherStation.v1" name="GET">
    <request>
      <resource path="weather/{state}/{city}?forecast={day}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
        <param name="day" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}/{city}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}">
        <param name="state" required="true" style="template" type="xsd:string"/>
      </resource>
      <param name="Accept-Charset" style="header" type="xsd:string">
        <doc xml:lang="ENG">Character sets that are acceptable: utf-8</doc>
      </param>
      <param name="Accept-Language" style="header" type="xsd:string">
        <doc xml:lang="ENG">Acceptable languages for response en-US</doc>
      </param>
      <param name="If-Modified-Since" style="header" type="xsd:string">
        <doc xml:lang="ENG">Allows a 304 Not Modified to be returned if content is 
         unchanged</doc>
      </param>
      <param name="Authorization" required="true" style="header">
        <doc xml:lang="en">Web Service call must be autheticated using Basic HTTP 
        auth.</doc>
      </param>
    </request>
    <response Status="200">
      <representation element="WEATHERDATA.v1:WeatherInfo" id="WEATHERDATA.v1.xsd" 
       mediaType="text/html"/>
      <param name="Allow" style="header" type="xsd:string">
        <doc xml:lang="ENG">Valid actions for a specified resource.</doc>
      </param>
      <param name="Content-Language" style="header" type="xsd:string">
        <doc xml:lang="ENG">The language the content is in</doc>
      </param>
      <param name="Date" style="header" type="xsd:string">
        <doc xml:lang="ENG">The date and time that the message was sent</doc>
      </param>
      <param name="Expires" style="header" type="xsd:string">
        <doc xml:lang="ENG">Gives the date/time after which the response is⇒
 considered 
         stale</doc>
      </param>
      <param name="Host" style="header" type="xsd:string">
        <doc xml:lang="ENG">Transaction Server</doc>
      </param>
      <param name="Warning" style="header" type="xsd:string">
        <doc xml:lang="ENG">A general warning about possible problems with the⇒
 entity 
         body.</doc>
      </param>
      <fault Status="400" element="Weather_Fault" id="WEATHER_FAULT.v1" mediaType=⇒
"text/xml"/>
    </response>
  </method>
  <method id="HEADWeatherStation.v1" name="HEAD">
    <request>
      <resource path="weather/{state}/{city}?forecast={day}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
        <param name="day" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}/{city}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}">
        <param name="state" required="true" style="template" type="xsd:string"/>
      </resource>
      <param name="Accept-Charset" style="header" type="xsd:string">
        <doc xml:lang="ENG">Character sets that are acceptable: utf-8</doc>
      </param>
      <param name="Accept-Language" style="header" type="xsd:string">
        <doc xml:lang="ENG">Acceptable languages for response en-US</doc>
      </param>
      <param name="If-Modified-Since" style="header" type="xsd:string">
        <doc xml:lang="ENG">Allows a 304 Not Modified to be returned if 
        content is unchanged</doc>
      </param>
    </request>
    <response Status="0">
      <param name="Allow" style="header" type="xsd:string">
        <doc xml:lang="ENG">Valid actions for a specified resource.</doc>
      </param>
      <param name="Content-Language" style="header" type="xsd:string">
        <doc xml:lang="ENG">The language the content is in</doc>
      </param>
      <param name="Date" style="header" type="xsd:string">
        <doc xml:lang="ENG">The date and time that the message was sent</doc>
      </param>
      <param name="Expires" style="header" type="xsd:string">
        <doc xml:lang="ENG">Gives the date/time after which the response is 
        considered stale</doc>
      </param>
      <param name="Host" style="header" type="xsd:string">
        <doc xml:lang="ENG">Transaction Server</doc>
      </param>
      <param name="Warning" style="header" type="xsd:string">
        <doc xml:lang="ENG">A general warning about possible problems with 
         the entity body.</doc>
      </param>
    </response>
  </method>
  <method id="POSTWeatherStation.v1" name="POST">
    <request>
      <resource path="weather/{state}/{city}?forecast={day}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
        <param name="day" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}/{city}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}">
        <param name="state" required="true" style="template" type="xsd:string"/>
      </resource>
      <representation element="QE_FLIGHTPLAN_SYNC.VERSION_1:QE_FLIGHTPLAN_SYNC" 
      id="QE_FLIGHTPLAN_SYNC.VERSION_1.xsd" mediaType="text/xml"/>
    </request>
    <response Status="201">
      <representation element="WEATHERDATA.v1:WeatherInfo" id="WEATHERDATA.v1.xsd" 
       mediaType="text/xml"/>
      <fault Status="400" element="Weather_Fault" id="WEATHER_FAULT.v1" mediaType="
       text/xml"/>
    </response>
  </method>
  <method id="PUTWeatherStation.v1" name="PUT">
    <request>
      <resource path="weather/{state}/{city}?forecast={day}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
        <param name="day" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}/{city}">
        <param name="state" required="true" style="template" type="xsd:string"/>
        <param name="city" required="true" style="template" type="xsd:string"/>
      </resource>
      <resource path="weather/{state}">
        <param name="state" required="true" style="template" type="xsd:string"/>
      </resource>
      <representation element="QE_FLIGHTPLAN_SYNC.VERSION_1:QE_FLIGHTPLAN_SYNC" id=
      "QE_FLIGHTPLAN_SYNC.VERSION_1.xsd" mediaType="text/xml"/>
    </request>
    <response Status="200">
      <representation element="WEATHERDATA.v1:WeatherInfo" id="WEATHERDATA.v1.xsd" 
       mediaType="text/xml"/>
    </response>
  </method>
</application>

Click to jump to parent topicWSDL Document and WADL Document Versioning

When the Service System Status in the Services Configuration page is set to Production and you attempt to regenerate a WSDL document or a WADL document for a service, PeopleSoft Integration Broker versions and stores the WSDL document or WADL document in the WSDL repository under the following condition: You have previously generated a WSDL document or a WADL document for the same service and new service operations have been added that you selected to include in the new WSDL document or WADL 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 document version. The new version number is also appended to the document name. The latest 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 or a WADL document for a service, any existing document in the repository is overwritten.

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

See Also

Configuring PeopleSoft Integration Broker for Handling Services

Viewing WSDL Documents Generated for Services

Click to jump to parent topicPrerequisites for Providing Services

The following prerequisites exist for providing services:

See Also

Configuring PeopleSoft Integration Broker for Handling Services

Specifying UDDI Repositories in PeopleSoft Systems for Providing and Consuming Services

Managing Service Operation Routing Definitions

Managing Service Operations

Building Message Schemas

Click to jump to parent topicCommon 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 Services 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 or WADL.

Service

Name of the service that contains the service operations to include in the generated WSDL or WADL documents.

Service Operation

Name of the service operation for which to generate WSDL or WADL documents.

Click to jump to parent topicProviding Services

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

Click to jump to top of pageClick to jump to parent topicUnderstanding 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 and WADL documents to the WSDL repository in the PeopleSoft system or external UDDI repositories.

After you generate a WSDL document or a WADL document, the Provide Web Service wizard displays a WSDL URL or a WADL URL for each document you generated. This enables you to access WSDL document or WADL document content using the URL.

In addition, you can modify a WSDL 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 operation associated with the service.

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

See Also

Prerequisites for Providing Services

Click to jump to top of pageClick to jump to parent topicStep 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 search for REST-based services, you must check the REST Service box. To search for non-REST services, ensure that the REST Service box is clear.

To select services to provide:

  1. Access the Provide Web Service Wizard – Select Services page (PeopleTools, Integration Broker, Web Services, Provide Services).

  2. Enter search criteria for the services to provide by performing one or more of the following:

  3. Check the REST Service box to limit the search for REST-based services. Clear the REST Service box to search for non-REST services.

  4. 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.

  5. Check the box next to each name of the services to provide.

    To clear a selection, check the box again.

  6. Click the Next button to proceed to the next step in the wizard, selecting service operations.

Click to jump to top of pageClick to jump to parent topicStep 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.

By default, the system generates WSDL in WSDL 1.1 format. The Generate WSDL 2.0 option enables you to generate WSDL in WSDL 2.0 format.

If you are attempting to provide a different version of an existing WSDL document, the Service System Status mode currently set, Production or Development, may impact your results.

See WSDL Document and WADL Document Versioning.

To select service operations to include in a WSDL document:

  1. Check the box next to each service operation to include.

    To clear a selection, check the box again.

  2. (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.

  3. (Optional) Select the Use Target Location check box to export WSDL to the secure target location URL defined on the Service Configuration page.

  4. (Optional) Select the WSDL 2.0 check box to generate WSDL in WSDL 2.0 format.

  5. 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

Click to jump to top of pageClick to jump to parent topicStep 3: View WSDL Documents or WADL Documents

After you select the service operations to include in a WSDL document or a WADL document, you can preview the WSDL or WADL 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.

When you are generating a WADL document the page that appears is the View WADL page shown in the following example:

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 or the View WADL link, the WSDL or WADL displays in the WSDL Viewer page (IB_WSDEXPPVIEW_SEC) or the WADL Viewer page, respectively. The following example shows the WSDL document for the QE_PO service in the WSDL Viewer page.

To preview WSDL documents and WADL documents:

  1. Click the View WSDL link or View WADL link for a service.

    The WSDL document or WADL document for the service appears in the WSDL Viewer or WADL Viewer.

  2. Click the Return button to return to the View WSDL or View WADL page.

  3. 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 WSDL documents and WADL documents.

Click to jump to top of pageClick to jump to parent topicStep 4: Specify Publishing Options

After you preview the WSDL document or WADL document, use the Specify Publishing Options page (IB_WSDLEXP_LOC) to specify the publish location of the generated documents. The following graphic shows the page when you are publishing a WSDL document:

By default the system publishes WSDL documents and WADL document to the PeopleSoft WSDL repository.

Note. WADL documents can only be published to the 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:

  1. From the UDDI Name drop-down list box, select the UDDI server to which you are publishing the WSDL.

  2. Click the Get Bus. Entities button.

    The Select Business Entity section lists the business entities that are available to select for the UDDI server.

  3. Check the box next to each business entity name to include.

  4. Click the UDDI Category Name lookup button to display a list of UDDI categories and select a UDDI category. Click the OK button.

  5. In the Category Value field, enter a value for the category.

  6. 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.

  7. Click the Finish button.

    The Results page appears and displays the WSDL generation log.

Click to jump to top of pageClick to jump to parent topicStep 5: View the WSDL/WADL Generation Log

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

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

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

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

When providing non-REST service operations, a Generate SOAP Template link appears on the page. Click the link 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.

See Also

Using the Generate SOAP Template Utility

Click to jump to parent topicAccessing Generated WSDL Documents and WADL Documents

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicUsing WSDL and WADL URLs To Access Generated WSDL and WADL Documents

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

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

Click to jump to top of pageClick to jump to parent topicUsing the WSDL Repository to Access Generated WSDL and WADL Documents

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

The following example shows the WSDL Repository page:

The WSDL Repository page lists the WSDL or WADL 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 Default option on the page is selected and disabled. This indicates that the WSDL shown is the default WSDL document for the service. The WSDL document that is last generated is the default version for the service.

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 and WADL Document Versioning

Click to jump to parent topicDeleting WSDL and WADL Documents

This section discusses how to delete WSDL and WADL documents.

Click to jump to top of pageClick to jump to parent topicUnderstanding Deleting WSDL Documents

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

See Understanding Configuring PeopleSoft Integration Broker for Handling Services, Using the Service Configuration Page to Set Service Configuration Properties.

Click to jump to top of pageClick to jump to parent topicDeleting a WSDL or WADL Document

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

To delete a WSDL or WADL document

  1. Access the Services Administration - WSDL page (select PeopleTools, Integration Broker, Service Utilities, Service Administration).

  2. Click the arrow next to the Delete section header to expand the section.

  3. In the Service field, enter the name of the service that contains the WSDL document or WADL document to delete.

  4. Click the Search button.

    Search results appear in the WSDL/WADL results grid.

  5. In the results grid, select the check box next to the WSDL document or WADL document to delete.

  6. 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 and WADL Documents.