Creating an inbound web service

Create an inbound web service to provide a way for an external system or application to call into IBM® Business Process Manager.

1. Open the Process Designer desktop editor.
2. Open a process application in the Designer view.
3. Select the plus sign next to the Implementation category and then select Web Service from the list.
4. In New Web Service, type KickTheBPD in the Name field and then click the Finish button.
5. In the Operations section, click the Add button and select the Inbound WS Handler Integration service that you created in the preceding procedure from the list.
6. In the Operation Detail section, change Untitled in the Operation Name field to doKick or something similar.
7. Notice the WSDL URI in the Behavior section. You can use this URI to test the sample integration as instructed in Testing the integration.

   The Protected check box adds user name and password security to an operation in the web service. For a web service client to invoke a protected operation, the user ID and password added to the user name and password elements for this operation must be registered at the server, assigned to the process application and have at least read authority. Note that this is not authentication in the context of an HTTP transaction, so selecting Protected does not display a default user ID and password.

   The Target namespace scheme drop-down list provides options for setting the target namespace:

   • Per process app or toolkit settings (default): Use the namespace from the XML Settings section of the Process App Settings page and do not include the snapshot name. This is the recommended setting because the target namespace remains consistent across multiple snapshots.
     Important: If the process application namespace is not set, the target namespace instead uses the per snapshot scheme. For more information, see the table that follows this list of options.
   • Per snapshot name: Use the snapshot name as well as the namespace from the XML Settings section of the Process App Settings page. This means that the namespace value in the web service client targets a specific snapshot.
     Important: In the following situations, the namespace of the Web Services Description Language (WSDL) file changes and you must obtain a new file to maintain consistency between the namespace used by the client and the namespace on the server:

     • When the application namespace is not consistent with the namespace on the server.
     • When the host name and port changes and the inbound web service uses a business object defined in the System Data toolkit, which uses a host name and port specification.
     • When you create a snapshot and switch a service to the inbound web service in the new snapshot.
     • When you switch from a specific snapshot to the default snapshot or from the default snapshot to a specific snapshot.
     Remember: Versions of IBM BPM before 8.0.1 use, in effect, the snapshot name scheme.
     Attention: In a web service that uses business objects that are defined in a toolkit, after you update the toolkit namespace in the advanced XML Settings and switch the snapshot dependencies to the updated namespace, the generated WSDL might not contain the updated namespace. If you find that the namespace is not updated in the generated WSDL, open the business objects definition in the updated snapshot in the Process Designer and click View XML Schema to update the namespace.
   • Custom name: Use only the value specified in the Target namespace field.

   The following table shows the resulting target namespace depending on the value you choose for the scheme, the namespace setting for the process application, and where the web service is running.

   Combination	Resulting URI
   Process App namespace set to http://xyz value Use process app or toolkit scheme	http://xyz/web_service_name.tws
   Process App namespace set to http://xyz value Run on a snapshot that is not tip or default Use snapshot scheme	http://xyz/snapshot/web_service_name.tws
   Process App namespace set to no value Run on a tip or default snapshot Use process app or toolkit scheme or Use snapshot scheme	http://host:port/teamworks/webservices/ proc_app/web_service_name.tws
   Process App namespace set to no value Run on a snapshot that is not tip or default Use process app or toolkit scheme or Use snapshot scheme	http://host:port/teamworks/webservices/ proc_app/snapshot/web_service_name.tws
   Use Custom scheme	http://custom_namespace

8. Select the SOAP version you want to use.
9. The Security and Policy section allows you to configure a policy set and a policy binding with your web service. The server must have been already configured by a system administrator.
   • Policy Set: Specifies the name of the application policy set. Click Select to choose the policy set. The list you will see depends on the policies available on the server. Some default application policy sets include: WSHTTPS default, WSAddressing default, and Username WSSecurity default. You can also create additional application policy sets in the WebSphere Application Server Administrative Console. Deselecting a policy set also removes the policy binding. More information on policy sets can be found in the IBM Redbook WebSphere Application Server Web Services Guide.
   • Policy Binding: Specifies the name of the general provider policy set binding, which contains system-specific configuration parameters like username and password information. Click Select to choose the policy binding. The list you will see depends on the general provider policy set bindings available on the server. Default policy set bindings include: Provider sample and Provider sample V2. You can also create additional policy set bindings in the WebSphere Application Server Administrative Console. Deselecting removes the policy binding.

   Note: SOAP header information is available in system variables. The tw.system.soap.header.request variable is automatically initialized to contain the list of SOAP header entries found in the incoming request message. You can include JavaScript code with your inbound web service which accesses these SOAP header entries. You can also write JavaScript code which adds SOAP header entries to the tw.system.soap.header.response system variable. The SOAP header entries contained in this variable are added to the outbound response message.
10. Save your work.

    Limitation: Any variable with a simple type containing a restriction element will not have the restriction element on generation of the inbound web service.