webMethods.io: Transformation Service, Ready to Go.
We completed the development of the Flow service last week. Today, we will test it and use the service in a webMethods.io Workflow.
Starting with a thorough set of input data that captures various cases is key to effective software testing. This light-hearted joke illustrates how important it is to balance complete test coverage and realistic situations.
Jokes aside, I use the authentic ChatGPT response from my integration Workflow. You can store multiple test cases for the service and use them to debug functionality. Uploading complex input documents from a file is the most convenient way to populate them. You can find an adjusted message on our GitHub sample code repository - comp-response.json.
- Login to your Webmethods.io environment and open a project with the integration service.
- Select Flow services from the navigation on the left and open the StripCompletion service.
- From the service toolbar, select the Debug icon. The debugger immediately pops the input data dialog to populate the missing service details. As you may see, the input document is based on the document type we defined as input-output data.
- Click the "Upload input values" button to select the JSON document from our local storage. You will receive a confirmation of success, and input values will be present in the form.
- Even if you get a confirmation of the successful data upload, it's a good idea to walk through and ensure that all mandatory fields are in your value set.
- Click the "Debug" button to start. If you have made a last-minute change, the debugger will ask you to update the existing set, create a new one, or continue without it. Save the data and continue to the debugger.
- Press F10 (on my MacOS system) or click the "Step Over" icon from the debug controls on the right. The current line advances to the next step in the service flow, and your service data state will be updated.
- Click F8 to run the service to the end and observe the results produced by the execution steps.
I don't want to rephrase and repost the very informative description of the debugger interface and features provided by the product documentation. The primary functions are intuitive and give you a clear picture of how the service transforms your data or what other services are called.
To conclude the test and use topic, let's review our use options:
- Flow service can call other Flow Services. To do so, click the service step and start typing our Flow service name.
- Call Flow Service from Workflows. Start typing the service name in the component palette. Published Flow services are listed under the Services section. Drag your service to the Workflow design area and drop it near where you need it. Complete variables mapping the same way as you configure all the other integrations.
- Use the Flow service HTTP endpoint to place HTTP POST calls from 3rd party clients.
To enable HTTP access, we should go back to the project integrations.
- Close the Flow service project if it's open.
- Click on the hamburger icon in the bottom right corner and then "Overview."
- Mark the "Enable Flow service invocation over HTTP" checkbox. Please note that it's not precisely a RESTful service. The access offers only POST operation and payload type depending on your I/O definition.
The HTTP invocation provides backward compatibility for on-premises or historical systems. If you want to expose your services to modern integration systems, consider exposing them to the Workflow or with the Webmethods API Gateway.
I close the Flow Service series with a small confession: My production integration still uses Node.js transformations. The reason is the implementation of the "replace" function. The underlying RegExp treats blank characters ['\t","\n","\r"] differently and does not produce the desired outcome.
I truly believe that enterprise integration projects with no low-level code are better, and compromises should be made to balance principles and delivery.
Previous posts in the Flow service series: