Overview
As TIBCO developers, we have been faced with different challenges during our work. One of those challenges would be the time-consuming process before delivering a fully-packaged bundle to a runtime environment. This process involves executing and passing all regressions tests during developing BW applications.
Most of the time we focus on the requirements and tasks that are provided to us and we do not pay attention if our code hasn’t altered or destroyed the already existing functionality of the system.
When it comes to pulling data from REST API’s or Web Services from multiple BW applications we are simulating some kind of build-in mock services by open-source platforms like Soap UI or we are developing ad hoc services in our favorite programming language.
When BW applications are part of a complex system and simple change can affect process execution, then we should consider simulating all BW applications and running each of them simultaneously to make sure that our implementation is not brittle.
Having been faced with this kind of challenge, we have managed to find a solution in the BW Designer by using raw TIBCO Web Service implementation as a centralized place. However, this solution saved time when it came to chaining complex BW applications, but it was tedious and messy in the long term since the code was repetitive and did not follow the DRY convention. Thus, we decided to build something else.
Why do we need Generic Mock Services?
Creating mock services with certain implementations requires time, especially in TIBCO BW with all capabilities of BW components or some external resource that is part of the system, we decided that a more automatic solution is necessary for a convenient and better outcome.
Hence, we have developed a generic tool for creating web services that simulates one or multiple API’s which enormously accelerates development and regression tests with only a few clicks without touching existing BW components to accommodate the latest changes of the code.
Implementation
Our Generic web service tool is developed as a Maven project and wrapped in a *.jar file which can be executed in various ways.
After executing the jar, a simple desktop canvas will pop up with dozens of self-description fields and buttons each with a certain functionality.
As we can see the tool is user-friendly and intuitive for users. In the left upper corner, we have specified the default host of the mock, we can provide a port of our choice and set additional resources and response headers which we will show you in the corresponding topic.
In the right upper corner, we are providing HTTP resources like endpoint, incoming verb, status code, and response payload from the local disc.
In the bottom section, we have specified three buttons for adding multiple services, exporting current services in an external file, and start/stop the service.
If we go step by step in simple terms we are just populating the provided fields with desired values and start the service. Let’s say for example that we want to produce a mock service that runs on port 1234 and on endpoint /test with a simple JSON response saved in some file.
JSON response:
Single service
First, we are populating the fields for port and base paths accordingly.
Also, we are setting GET for the verb in the dropdown, where we are telling our service to expect only GET requests.
In the end, we are navigating to JSON file in our local disc where we are setting for a response.
Finally, we can start the service by clicking the Start Service button and testing the functionality of the desktop app.
Notice on the right side after the Export to File button new canvas is created where the full URL of the running service is displayed.
In order to get the benefits of the tool, we can create a simple HTTP client in BW or use CLI utility curl.
Single service with multiple endpoints
Additionally, we can add multiple endpoints with different values in the same service for the simulation of BW components by clicking Add Endpoint.
We can remove each of them with the remove button on the left side of the panel.
Multiple services + HTTP response headers
In addition, we can add one or multiple services in order to meet our needs for testing BW application that is chained with dozens of other resources.
Optionally we can add static HTTP response headers for each service and they will be exposed in the response.
So far so good, after invoking the service, we can check the response headers.
Export and reference state
There is an additional option implemented to keep the previously created state of the generic tool in the external *.yml file in order to distinguish certain service implementations with TIBCO BW components where we can keep the separated version of the yml file in the code itself.
Let’s take the latest version of the tool with multiple services for example where we will export the implementation in our local disc.
After clicking the Export to File button, the local disc lookup canvas will appear that will point to our machine and we can choose where to save the .yml file.
By convention, it is best to save the file in the project directory where the BW code resides.
And we can reuse it later as we pass the full path location of the file when we are executing the jar.
After releasing this statement, we will have previously created mock services on track and ready for usage.
Conclusion
Currently, as a team, we are using this tool continuously in one of our projects where complete integration between business associations and marketplaces resides on TIBCO BW5 product with regression testing as an inevitable part of our journey.
All those tedious and excessive days of testing on various platforms and checking all over again on multiple BW components if every change does not affect the other parts became part of the reluctant past.
Certainly, there are also other functionalities that can be incorporated into the generic tool and improve the basic usage of the services, but in order to do that, time and a lot of effort are needed, alongside the concurrently executed tasks which we will cover in another manual.
By creating dozens of services, creating resources for each service, and wrapping them in the external file we can rapidly accelerate our software lifecycle by connecting our application (regardless of which programming language or integration product is developed) with the generic tool.
As a Tibco team in ⋮IWConnect, we are fully committed to automating our tasks as much as possible, and for that purpose, we have created various other tools that we are using interchangeably across the projects.
For further information regarding the tool, you can contact our TIBCO team at sales@iwconnect.com.
