The following topics describe how you can invoke Process Designer and Process Developer processes deployed to the Cloud Server.
Web Services and SOAP Endpoints
Process Designer exposes web services through an automatically generated WSDL interface that you can access and use as a SOAP endpoint. Each web service you interact with contains a set of methods, also called operations, hosted on an application server. You can invoke these operations remotely in the cloud or over a network.
When you invoke a process that is deployed to the Cloud Server by using the SOAP Service URL, the SOAPAction Header is set to the process name by default. However, you can provide a different value in the header. For more information about using the SOAP endpoints, see Rules and guidelines for SOAP endpoints.
When you invoke an operation, you create a SOAP message and send it to the web service, typically over HTTP/ HTTPS. SOAP is a commonly used XML-based messaging protocol used to exchange information.
A web service has a WSDL (Web Services Definition Language) document, an XML description of the operations and how to invoke them. Every web service you want to interact with must have a service name and an endpoint URL (the location to which you send SOAP messages in order to invoke the operation).
The caller of the web service need not know anything about the internal details, as the SOAP interface publishes the available operations. For each call, the web service returns a response message. The response contains either the information requested or fault information, in case of an error.
This simple SOAP message calls the "Add" method and returns the answer:
When you define processes with Process Designer, the SOAP endpoint is available for use by SOAP clients that handle the "xsd:any" payload style, which means the clients can process inputs, outputs and handle faults.
Process Designer supports the SOAP 1.1 standard with the document/literal message style and encoding option used by most web services.
With the WSDL interface, you can:
•Define WSDL input and output types with an inline schema based on the process input and output fields or process objects. The namespace is automatically generated.
•Display the SOAP Service URL in the process details.
•Link to the WSDL definition from the process details.
•Use basic authentication, consistent with REST.
•Generate faults using a Throw step, which allows you to share a single fault and provide a description.
•Generate correlation properties in the WSDL to handle inline message events and boundary conditions.
To define a SOAP endpoint in Process Designer:
1In the process properties, choose REST/SOAP as the Start Binding.
The following image shows the Binding property set as REST/SOAP:
2After you define and publish the process, you can see the SOAP Service URL.
The following image shows the SOAP Service URL:
3Click View WSDL File to open the complete WSDL and view the SOAP message generated for the process. You can copy the URL to use it as an endpoint.
Note: If a process contains Japanese characters in its name, you might see an error when you view the WSDL file from a Chrome browser. If you see an error, right-click on the page and select View page source to view the WSDL file.
REST and Process Designer SOAP Endpoints to Access Message Events
You can access message events using REST and SOAP 1.1 endpoints generated by Process Designer. If SOAP 1.2 endpoints are required please use Process Developer to generate these endpoints. To obtain endpoints of services created using Process Developer, refer to information on policy-driven bindings in the Process Developer Guide.
Note: When the number of REST or SOAP request exceeds the rate limit within the designated time frame, a HTTP 429 status code appears.
The following table specifies the pattern for each REST or SOAP 1.1 endpoint based on the type of access required when you invoke message events.
The process uses HTTP Basic access authentication when you uncheck Allow anonymous access in the process Start properties or the Messages properties for message events. You can define a process to authenticate differently than the callback it receives, in message events or subprocess calls.
Note: For SOAP requests, you can use the default process or sub process endpoint if the event has the same access, either anonymous or HTTP Basic access authentication, as the process or sub process.
Rules and guidelines for SOAP endpoints
Consider the following rules and guidelines when a public or an authenticated process call is made:
•If the SOAP URL contains the tenant ID and the service name, the SOAPAction header can be empty or can have any value to invoke the process.
•If the SOAP URL does not contain the tenant ID or the service name, the SOAPAction header must contain the respective missing value to invoke the process.
•If the SOAP URL does not contain the tenant ID and the service name, the process invocation fails even if the SOAPAction header contains a value.
