Chapter 14. Deploying the Application
In the previous chapter, you created the Tahiti application and ran it in your development environment to validate all the actions presented in the application page and the associated processes. This chapter contains some advice about how to test your application more thoroughly before putting it into production, and explains some of the considerations for setting up the environment required to support the application. Finally, it suggests some ideas for improving the application in future versions.
Testing
When you use a BPM solution to build a process-based application, you need to plan for testing, just like in any other software development process. The details of what testing is required and how you run the tests will depend on your corporate infrastructure and guidelines for acceptance testing to demonstrate that the application is acceptable to be installed.
Typically, testing is done at various levels such as unit test, workflow execution, and user acceptance testing.
Unit Test
Unit tests focus on the source code you write for your processes implementation, addressing each code unit separately.
When you use Bonita BPM, you typically write source code for the following artifacts:
-
Java code for connectors, actor filters, event handlers, or libraries included in process definitions. In the Tahiti application, you have not created any Java code.
-
Groovy scripts for REST API extensions and in various places in process definitions. In the Tahiti application, you use a REST API extension and many Groovy scripts.
-
JavaScript scripts in forms, pages, and custom widgets. In the Tahiti application, you have used many JavaScript scripts in forms and the application page.
Define unit tests in the development environment you use to write the different pieces of source code. If source code is called only in a process definition, you might want to externalize it to make testing easier.
You can usually benefit from the testing tools already used in your development environment. For example, to test Java source code we recommend JUnit, Mockito, and AssertJ.
Workflow Execution
Workflow execution is an integrated test of all the process elements used to execute a usage scenario. This validates the behavior of the processes end to end. In earlier chapters of this book, you have checked the end-to-end workflow using test scenarios that start in the Tahiti application page and then progress through process steps.
As well as test scenarios that execute the happy path of expected user interactions, you should also test all possible branches of each process.
Tests should verify process execution progress by checking which steps are pending, and the process state after giving an order, such as creating a process instance or execution of a step. Tests should also perform checks on the business data to validate consistency with process execution progress. For example, you need a test that verifies that the leave request status is consistent with the user actions taken.
If your process definition is integrated with external systems such as an email server or web services, you need to create mock-ups of the application interactions with these systems. This enables you to test your application and its processes in isolation, without also testing the external systems.
User Acceptance Testing
Unit tests and workflow execution tests primarily cover process definitions with the goal of ensuring that process execution is flawless. For a fully automated process this is all that is required. However, for a process or application that includes user interaction, you also need to test the user interface elements.
Web user interface testing can be automated with tools like Protractor. Such tools are invaluable, though the upfront investment to create test definitions can be high. Also, automated user interface tests do not provide feedback about your application usability.
We recommend that you partially automate this testing, but counterbalance the automated testing with testing done by a panel of users. This way you will quickly catch obvious bugs and gather information for future improvements.
Setting Up the Environment
After you have completed the testing, there are three steps to complete before you can put the Tahiti application into production:
- Set up a Bonita BPM production platform.
- Integrate Bonita BPM and the Tahiti application into your corporate systems. For example, if you manage users with an LDAP system, synchronize this with the Bonita BPM organization. If you have a single sign-on system, extend this to Bonita BPM to grant access to the Tahiti application. The Bonita BPM documentation explains how to do this.
- Create a process for initializing the vacation days available at the start of the vacation year, and for any new hires during the year. The downloadable initialization process is really provided for testing, but you could adapt it to update the available days for all employees at the start of each vacation year.
Future Enhancements
Throughout this book you have been developing the process-based Tahiti vacation management application. You now have a working application that, with a little configuration, you can deploy in your company. But you have probably noticed that there are some things that the application does not do. We made some deliberate decisions to ignore some potential features, either to to avoid duplication, to avoid distracting detail that is not specifically about BPM application, or just for simplicity.
Application development is always iterative, and it’s completely normal that you finish the development of version 1 with a list of features for version 2! Here is our list of things that we decided not to cover in this first version of the Tahiti application:
- Handle multiple types of vacation (for example, unpaid vacation, personal days, recoup).
- Handle half days.
- Calculate number of days out or return date instead of asking user to enter them both. Would need logic with knowledge of each employee’s work pattern (for example, if part-time) and public/company holidays for each location.
- Monitor unbooked vacation totals automatically and flag potential issues to manager. Would need to compare days unbooked with remaining bookable days, and with some indication of “typical” pattern. For now, we just show the data and expect the manager to draw conclusions.
- Manage the potential concurrent access if user modifies or cancels a pending request while it is being reviewed by the manager. Transaction model means risk is low.
- Permit modification of an approved request.
- Send a notification to the escalation reviewers group when a vacation request review is late.
- Present cancellation requests for review in the manager’s Tahiti application page. The manager can use the Bonita BPM Portal to do these tasks.
- Add an escalation path for cancellation requests.
- Present escalated review requests in the Tahiti application page. The users in the escalation group can use the Bonita BPM Portal to do these tasks.
- Handle tables when there is no data to display by showing a message instead of an empty table, so that it is clear this is not an error.
- Add an application page for updating an employee’s available vacation or for initializing this for a specific user partway through the year (the new hire case). Keep script for bulk initialization at start of year, but update it to allow for different numbers of days for employees with nonstandard work patterns.
- Support administrative tasks including reporting vacation to payroll.
- Add metrics to track the efficiency of the process. For example, you could track the average time between submission and review for a request for each manager, and how often requests are escalated.
You can add you own ideas here, and then start developing Tahiti2!
Next Steps
Congratulations on staying the course! You have made it to the end of the last chapter of your journey to develop your vacation management application. You can deploy it and get feedback from your employees, and enjoy the efficiency gains over your old manual process.
But this is just your first business process application. Now that you understand how to go about creating a process-based application, take a look at the other business processes in your company: there will be many more processes that you could automate, with even more productivity gains and cost savings.