Web service references
Use the Web service references to connect to the third-party software applications, regardless of how each web service is implemented.
For example, TotalAgility can integrate with a web service that automatically validates a credit card number or retrieves delivery information from a transportation company for a dispatched order.
See Web services supported by TotalAgility.
When creating a Web service reference, you can specify custom headers so that the custom header is passed to the Third-party web service when the corresponding Web Service or Restful node is executed. A custom header consists of a name and value pair, such as Host: localhost, where Host is the name, and localhost is the value. All SOAP, SOAP WCF, and RESTful web services support custom headers.
You can also use a RESTful service that has an Open API definition in the process/rule/custom service so that you can see the methods/parameters and execute the service successfully. The OpenAPI specification is an API description format for REST APIs. You can write the OpenAPI definitions in JSON or YAML. YAML is recommended because it is easier to read and write. An OpenAPI file allows you to describe your entire API, including the following:
-
Available endpoints (users)
-
Operations on each endpoint (GET/users. POST/users)
-
Operation parameters (that is, input and output for each operation)
You can reuse the existing web service proxies and proxy file names for any web service references used by TotalAgility processes, forms, or packages. Web service proxies are dynamically created at run time.
When the proxy cannot be created for the web reference, when you import a process map, the reference is still imported, and the following message appears: "Web Service failed to create proxy DLL. To fix the issue regenerate client proxy."
When you import processes, forms, or both using packages, if a new web service reference has the same name as an existing web service reference, a message appears.
How to: