The Services Enablement feature enables you to turn any integration process into a web service that can then be deployed on premise or in any Boomiruntime cloud to which your account has access.
Web services deployed in a runtime cloud can be dynamically invoked by any cloud or local application through the cloud’s domain name (such as, https://c01-usa-east-integrate.boomi.com). a Runtime can even be enabled as a simple web server that does not require SOAP or XML messaging. If a client application can post via HTTP or HTTPS, messages are parsed and forward them into the linked process.
All web services, whether deployed on premise or “in the cloud,” are then managed from one central location in Integration to help extend and strengthen existing governance policies.
Deploying a process that contains a Web Services Server connector will launch the web service and web server that will listen for requests or documents.
Another optional feature, API Management, enables a web service publisher to expose versioned APIs for logical groups of web services. A web service API consists of a set of REST and/or SOAP endpoints. APIs are implemented as deployable web service components. For more information, see the topic about API management linked below.
One of the most common use cases for web services is event-based integration. Here is an overview of the process of building, publishing, and invoking web service processes to implement event-driven integration:
- Configure your shared web server.
- If you will deploy your web service to a runtime cloud, there is no need to configure it. It defaults to BASIC authentication and should generate a token if one was not already generated.
- If you will deploy your web service to a local Runtime, you should also configure your firewall/router to route incoming messages to the Runtime (similar to AS2).
- You should set Authentication to NONE.
- Authentication should be IP-based or SSL Client Certificate-based, but that needs to be done at the firewall level.
- Build your initial process:
- Configure the Start step by defining a Web Services Server listener and a Web Services Server operation.
- Add a Message step to generate an XML document for the acknowledgment.
- Add a Return Documents step after the Message step to return the acknowledgment message synchronously back to the sending application.
- Test the process.
- Configure the Start step by editing the Web Services Server operation:
- Create a new request XML profile and use the XML Import Wizard to build a profile structure based on a saved copy of the test data received from the client application.
- If the client application requires acknowledgment, create a new response XML profile and use the XML Import Wizard to build a profile structure based on a saved copy of the acknowledgment XML.
- Add a Branch step after the Start step. Use the second branch path as the starting point for the rest of your process flow. The request XML profile defined in the Web Services Server operation can be used as the source format for the rest of your process and maps.
- Redeploy the process.