Functional Testing Business Processes In Oracle BPM Suite

Over the last couple of projects, I have been trying to establish a set of methodologies around initiation, development, deployment and management of business processes using Oracle BPM Suite 11g. In a series of posts, I will be taking about a lot of problem areas that can be effectively tackled in order to deliver a highly successful BPM project using this technology. The areas I intend to cover are around design and modelling best practices, team development, delivery methodologies, testing, troubleshooting, automation, performance tuning and operational management to name a few. However in terms of priority and the nature of pain experienced in each of these aforementioned areas, I am of the opinion that a great chunk is attributed to testing and maintaining code quality. Business processes are in constant need to be truly dynamic more than ever so that planned as well as ad-hoc changes can be promoted seamlessly. Also with Oracle BPM Suite 11g promising greater involvement of business users in terms of making deployable changes to the processes, ensuring that functionality and quality of the build/changes is maintained is very crucial. In the previous blog post, I had elaborated on unit testing strategies for business processes and methods of achieving them from the Oracle BPM Suite 11g studio. Proper unit testing is important in terms of validating that the core logical outcomes of a business processes are executed as expected. This ensures that all sequence flows and paths in a business process are tested and conformant. The post can be accessed here:

https://beatechnologies.wordpress.com/2013/05/05/unit-testing-business-processes-in-oracle-bpm-suite-11g/

However, apart from testing the basic process paths a lot of other things demand testing too. Business processes can populate data in downstream systems, integrate with services, create events, send notifications, assign workflow tasks which may have their own lifecycle, etc. From a quality perspective all of these steps must be verified too. The overall functionality of the business processes must be thoroughly tested to determine their reliability before being deployed to the actual IT infrastructures. Organizations do invest in quality measures to evaluate features of business processes by employing a comprehensive testing strategy, involving analysts, developers, functional testers and business users. However they begin to invest in test automation very late in the project lifecycle. This poses a significant threat and concern, particularly when the business processes are continuously changing and evolving. An increasing pace of business process changes as well as applications growing more complex means that many functional testing teams are reaching the breaking point. Change management becomes difficult as there is always a risk of introducing new bugs down the way. As much as we all would like to have agility, the process is defeated by having improper developer operations. Having a regression functional testing suite very early in BPM project development cycle is, by my opinion a must have thing for any successful and timely implementation. More often than not, it is not the choice of technology that is responsible for this but rather the lack of some important know-how’s.

Typical Problem Areas and how Automating Functional Testing can help

In my interactions with different project teams, here are some typical questions they have, especially with respect to testing business processes in Oracle BPM Suite 11g.

• Is it possible to really approach functional testing early in the project cycle considering the nature of composite applications involved (business processes, services, rules, etc.).
• Human tasks components in business processes need to have user interfaces (which may have their own development lifecycle). How can functional testing be achieved before a fully operational UI?
• Are their any developer tools, approaches or frameworks that can be utilized to automate functional testing?
• What kind of a functional testing strategy is suitable, cost efficient and good to contain a wide variety of problems in the project lifecycle?

If we begin to investigate the possibilities, they may be endless. I, am particularly aware of many custom products which promises to take care of all of these. However hey tend to be expensive, have a steep learning curve and may not always fit the bill. This act as a big deterrent. However, in this article, I am keen on presenting an approach that is quick, easy, developer friendly and can be easily catered in the development phase of the project. The best way to begin with functional testing is to base it on the business process design. Model driven functional testing ensures that critical processes and their paths are covered and that any variation of those tests can easily be amended and rerun without adding to significant time to the test cycle. Functional testing can start earlier and better quality tests are produced and maintained in a test repository. This can then be part of the continuous build and integration iterations to ensure sufficient test coverage in accelerated delivery cycles. A part of model driven testing strategy was described in details with respect to ascertaining the cyclomatic complexity factor of the business processes and deriving test cases based on that. This approach is a very good starting point, especially because this can be used to build unit tests too. Once the basic process paths are determined, the functional test suites can incorporate a lot of test steps to cover the functional aspects such as validate business logic and rules, verify data across systems, check events and notifications, etc..

With all this being said, however, automation of functional testing will only be successful if an organization’s underlying quality fundamentals are solid and everyone clearly understands how testing can continuously support process iterations. Another big advantage to automate early is potential time savings. Considering that multiple stakeholders will need to repeat their testing task, every time something changes, doing them manually becomes a burden sooner or later. Have a look at the sheet I’ve compiled based on various time and frequency of performing functional tests and the effort involved in each case.

The columns marked in green in the above sheet reflects the most likely scenarios in terms of the amount of time spent on testing in various Oracle BPM Suite 11g projects. The effort involved in manual testing can range from 20 days to 4 months for a very simple and less frequently changing business process to a complex and often changing business process. This effort does not accounts for test planning but simply reflect the time spent in test execution. The columns in red represents scenarios that can be applicable for certain project types too and in those cases the amount of time spent in manual testing can be even 8 months. This offcourse is under the assumption that all quality standards of software functional testing are maintained. 

Approach and Tooling

As indicated before, there are many players in this field providing varied approaches and option. This article will not debate their merits here. In the course of my involvement with BPM projects, I seems to incline towards SOAPUI. This is particularly due to the fact that it is pretty inexpensive (there is also a freeware if ~$350 license cost seems significant) and does most of the basic functional testing that can be considered acceptable from a quality perspective. It is fairly straight forward too and the learning curve is minimal. Chances are also high that in most projects there will be developers with considerable amount of experience using SOAPUI, if they have been involved in a SOA project in the past.

Having said that, this article will talk about how to plan and implement a comprehensive and automated functional testing suite for business processes developed using Oracle BPM Suite 11g.

The Employee Expense Approval Business Process

I will use the same employee expense approval business process that was discussed in my previous blog. This process has primarily all the ingredients that any complex business process has i.e it is fairly unstructured, have business rules, human workflow components, arbitrary cycles, gateways, events and writes to external applications.  As a refresher, the process map looks like below in the JDeveloper studio.

Technology Prerequisite(s)

The modelling workspace and the version of Oracle BPM Suite used in this demonstration is 11gR1PS5 i.e 11.1.1.6. The version of SOAP UI being used is 4.5.0 (excuse my backwardness in terms of working with the latest versions of these tools). I use the open source version of SOAPUI but for better productivity and ease of use you may consider using the Pro version too. A connection to the database is also necessary to be able to create certain database objects that the project requires. The version of the database, though, can be any generic with the only exception that it has to be Oracle database.The concepts discussed in this blog are however generic and applicable to any version of the above products.

Project Setup

In order to import the implemented expense approval project in JDeveloper, obtain the composite (ExpenseApprovalComposite.zip), unzip it and open the application (.jws) file in the studio. As can be noticed from the BPMN mode, the process populates some database tables with expense and payment records at various stages. To be able to deploy and execute the project, a database schema and certain tables needs to be created. On the Weblogic server side, there is a need to create a data source and add a new connection factory to the database resource adapter.

Doing this set-up is pretty simple. I have created some SQL and ANT scripts that can do all of this. Follow the instructions below to execute these scripts to create the required resources.

Create the Database Artefacts

• Download and unzip the DatabaseSchema.zip file in a local directory.
• Open the edit the create_expense_structure.bat and simply substitute the sys password with the one for the database you are using. This script assumes that a local XE flavour of the database is running. If this is any different then modify the bat file accordingly.
• Open a command prompt and cd to the directory containing the bat file. Simply run the batch file in the prompt.
• This will create a database user “EXPENSE” and two tables in it called EMPLOYEE_EXPENSE_PAYMENT and EMPLOYEE_EXPENSE_RECORD.
• Verify that the scripts ran okay and the database artefacts were created.

Create the Weblogic Server Artefacts

• Unzip the ResourceAdapter.zip in a local directory.
• Open the build.properties file and substitute the middleware home location with the one being used. Also modify the values of the database server, weblogic server, domain, connection credentials etc. Properties that needs to be changed are marked in the build.properties file through comments.
• Open a command prompt and cd to the local directory where the contents of the .zip file are placed.
• Type ant makeDataSource to create the required datasource in the weblogic server to connect to the EXPENSE schema created in the step before.
• Once the build is successful type ant createResourceAdapterEntries in the same command prompt.
• This will create the database adapter connection factory and update it with the datasource created before. It also updates the DbAdapter deployment plan to commit all these changes onto the server.
• Verify that the script executes successfully. If it doesn’t then there may be a problem in substituting values in the build.properties file.
• As a last resort, you may configure these resources manually on the server or alternatively send me your configuration files along with the error(s).

Creating the Functional Test Suite

Once the project has been set-up and the required artefacts are created, it is time to look into creating a functional testing suite for the expense approval processes. Once we create the functional tests, they can be used for regression every time there are changes made to the business processes. A good practice is to always accept any changes when it is accompanied by a functional test case and when all existing test cases pass the regression. However the dynamics here may be dependent upon the level of business user’s involvement in creating ad-hoc changes to the business process after it is deployed. If business users are empowered to make dynamic changes, then it cannot be expected of them to create/modify the functional test cases supporting their changes. This situation demands a change control process in place. I am of the personal opinion that to ensure the quality of business processes running on the production environment, changes must always be supported with regression. Whether business analysts and process analysts create these tests or whether they get it done from developers is a matter of having a governance around the change control.

Nevertheless it is pertinent to have an initial set of functional tests. If you managed to read the previous blog post on unit testing business processes in Oracle BPM Suite 11g, you must have noticed how we employed cyclomatic complexity to determine the number of unique test cases required to provide a cent percent test coverage. From the functional testing perspective, we will still create the same number of test cases but also have a series of test steps to validate that the business process is indeed doing all the right things.

As determined before the following test cases shows the various routes a process can take from all the conditional nodes. To ensure the utmost quality, we will have as many functional test cases too.

Test Case 1: Submit, Auto Approve, Finance Approve, Approve
Test Case 2: Submit, Auto Approve, Finance Reject, Refer
Test Case 3: Submit, Refer, Manager Approve, Finance Approve, Approve
Test Case 4: Submit, Refer, Manager Approve, Finance Reject, Refer
Test Case 5: Submit, Refer, Manager Reject, Reject

The following section will demonstrate a series of test steps that will be created to fully functionally test one of the test cases (here Test Case 3: Submit, Refer, Manager Approve, Finance Approve, Approve). Other test cases can be created in the similar lines.

• Deploy the ExpenseApprovalComposite to a BPM server and grab its wsdl  from the enterprise manager (since the business process has a message start event it can be invoked as a web service)
• Launch soapUI and create a new soapUI project. Put ExpenseApprovalTest as the project name and copy the wsdl localtion in the Initial WSDL/WADL field. Also check the option to create sample requests for all operations.

• This will create a soapUI project in the existing workspace. Now right click on the project and click on New TestSuite to create a new test suite inside the project. Name it as Expense Approval Functional Tests.
• A test suite can have multiple test cases that can be run either individually or all together as part of the test suite (either sequentially or in parallel). Once the test suite is created, right click on it to create a New TestCase inside it. Name the test case as T3_Refer_ManagerApprove_FinanceApprove_Approve.

• A test case is constituted of a series of test steps that are executed in sequence one after another. Testing a business process will involve initiating the business process through the message based event, capturing data in the human tasks, simulating user behaviour on the workflow screens and verifying that once the process is completed, it is in the right state, populates the right statuses in the end systems and follow the expected process path.
• A test case in its due steps may need to refer some constant values or store values intermittently to be used in later steps.  soapUI allows creation of global, test suite level as well as test case level properties. While properties at the test suite level are more appropriate to hold any constants (or pass them between multiple test cases), properties in the test cases are used primarily for passing information between multiple steps. Create the following properties at each level. You will notice that the test suite properties have been set to some constant values.

• The properties can then be accessed as variable using the below construct.

${#TestSuite#TASKSTATE}
${#TestCase#CONVERSATION ID}

• It is commonly believed that a business process with human tasks will need a functional user interface in order to test it. However it is not true. Oracle BPM Suite 11g offers both Web Services as well as JAVA based API’s to interact with the workflow tables. The operations in these API’s can be used to search and query for tasks, update task payloads and outcome, attach comments and attachments etc. Access the following posts to be able to get a glimpse of the human workflow API’s.

https://beatechnologies.wordpress.com/2011/08/24/using-java-apis-for-oracle-human-workflows

https://beatechnologies.wordpress.com/2011/08/22/oracle-human-workflow-web-service-apis

• In this article I will be using the Web Service API’s to simulate the human tasks when building the functional test steps. The first step in the test case is to create a unique identifier (random number) that can be used to set the conversation id while invoking the business process. Setting up a conversation id is important as the composite/component instances ID’s can be determined by querying the dehydration store against it. In soapUI a Groovy Script based test step can be used to generate a random number. Name this step as Create Conversation Identifier and paste the following groovy code snippet in the code editor.

testRunner.testCase.setPropertyValue("CONVERSATION ID", "${java.util.UUID.randomUUID()}")
log.info(java.util.UUID.randomUUID())

• The groovy script dynamically populates the CONVERSATION ID property in the test case with the uniquely generated number.
• Add a new SOAP Test Request and name it as Submit Employee Expenses – submit expense application. When needing to specify the operation to invoke select ApproveEmployeeExpenseBinding –> submitExpenseApplication from the available options. As a matter of best practices, I typically append the name of the process model object that is being interacted with in the name of the test step. This is important to maintain a visibility of which event in the process is invoked or which human task is updated/actioned.

• Copy the following payload to trigger the business process. The combination of business unit and expense total will force the business rule activity in the business process to send this instance to a manager review.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:app="http://www.rubiconred.com/ApproveEmployeeExpense" xmlns:empl="http://www.rubiconred.com/bpmtest/empl">
<soapenv:Header/>
<soapenv:Body>
<app:submitExpenseApplication>
<empl:Expense>
<empl:Employee>
<empl:EmployeeID>988977698</empl:EmployeeID>
<empl:FirstName>Arrun</empl:FirstName>
<empl:LastName>Pareek</empl:LastName>
<empl:Email>arun.pareek@rubiconred.com</empl:Email>
<empl:PhoneNumber>0424987673</empl:PhoneNumber>
<empl:ManagerID>6312313</empl:ManagerID>
<empl:DepartmentID>132313</empl:DepartmentID>
<empl:BusinessUnit>3</empl:BusinessUnit>
</empl:Employee>
<!--1 or more repetitions:-->
<empl:ExpenseList>
<empl:Amount>80000</empl:Amount>
<empl:Type>Travel</empl:Type>
<empl:Date>2013-02-06</empl:Date>
<empl:Justification>Travel on Business</empl:Justification>
<empl:Authoriser>Matt</empl:Authoriser>
</empl:ExpenseList>
<empl:ExpenseList>
<empl:Amount>40000</empl:Amount>
<empl:Type>Travel</empl:Type>
<empl:Date>2013-02-07</empl:Date>
<empl:Justification>Travel on Business</empl:Justification>
<empl:Authoriser>John</empl:Authoriser>
</empl:ExpenseList>
</empl:Expense>
</app:submitExpenseApplication>
</soapenv:Body>
</soapenv:Envelope>

• It is also very important to note here that the business process, by the virtue of message based start and end events, is implemented as an asynchronous web service. When the process completes it will send an asynchronous call-back to the initiator at a call-back address. Basically Oracle BPM Suite 11g supports WS-Addressing. The conversation id generated in the previous step can be used as the unique correlation identifier when invoking the submitExpenseApplication operation. Also the initiator can define a call-back address (Reply To in the addressing header) where the engine can send the call-back response.
• In soapUI WS-Addressing related headers can be added by clicking on the WS-A tab in the test step. The WS-A addressing enabled option has to be selected and the must understand flag is to be set to TRUE. The MessageID field is populated with the CONVERSATION ID test case property. Also provide a reply to address like below to let the BPMN engine register the the call-back address for this instance. This will be used in a future step.

http://rubiconred-pc:2222/ApproveEmployeeExpensePortTypeCallBackBinding

• The first test to be performed is to be able to successfully determine whether the soap request was successfully delivered to the end point. Since it is an asynchronous request, the response is not received in the same thread. Hence the only way to determine a success is to verify that the HTTP status code received is correct. To do that, add a status assertion for a Valid HTTP Status Code. Enter 202 (Accepted) as the expected status code. This status code reflects that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed or fault out when processing actually takes place. The 202 response does not requires an initiator’s connection to the server persist until the process is completed.

• The above test step will create an instance of the expense approval process which can be seen and verified through the enterprise manager.  The next test step to add is to retrieve the composite instance, ecid and the composite state from the CUBE_INSTANCE and COMPOSITE_INSTANCE tables in the dehydration store against the conversation id. The conversation id supplied by the initiator is stored in the CUBE_INSTANCE table. This will correctly grab the instance metadata for the instance that was created in the test steps above.
• Add a new JDBC Request test step and name it as Retrieve Composite Instance ID. A JDBC test step will require a JDBC driver and connection string and an SQL query to be specified. But before this can event work, you will need to copy the ojdbc5.jar under the $soapUIHome/bin/ext folder. This jar facilitates the connection to an oracle database from soapUI. The following values can be specified for the different properties in the JDBC request test step. Be careful to substitute the database connection details with the ones reflecting your environment.

Driver : oracle.jdbc.driver.OracleDriver
Connection String : jdbc:oracle:thin:ps5_soainfra/welcome123@localhost:1521:xe

SQL Query :SELECT COMPOSITE_INSTANCE.ECID, COMPOSITE_INSTANCE.ID, CUBE_INSTANCE.COMPOSITE_NAME, CUBE_INSTANCE.COMPOSITE_REVISION, COMPOSITE_INSTANCE.STATE FROM COMPOSITE_INSTANCE,
CUBE_INSTANCE WHERE COMPOSITE_INSTANCE.CONVERSATION_ID =CUBE_INSTANCE.CONVERSATION_ID AND CUBE_INSTANCE.CONVERSATION_ID= '${#TestCase#CONVERSATION ID}'

• The SQL query returns important metadata with respect to the composite instance that is created. soapUI allows adding assertions to each test steps in a test case. Assertions are a very good way to add functional validation at each test steps. The following screenshot shows the four different assertions that are added to this test step. The composite name and version are validated against the values of these properties specified in the functional test. The state value of 0 indicates that the process instance has been initiated.

• The instance might not be created immediately and available to be queried against the dehydration store. It may take a couple of seconds for the instance to be initiated. It may be required to add a Delay test step in between the SOAP and JDBC request test steps.
• The values retrieved from the JDBC request test step and the original payload passed in the SOAP test request can be saved to the test case properties so that they can be used in the next test steps. A Property Transfer test case can be added for this purpose. Name the step as Capture Process Properties and add four test step properties viz. ECID, INSTANCE ID, PAYLOAD and EMPID. For each of the properties the appropriate values can be captured by specifying the source test step, the variable (request, response or raw request, etc.) and the target test step property. When the property transfer test step is executed the test suite properties will have the most current values depending upon the payload entered and the results retrieved by querying the database schemas.

• Once the process is triggered/initiated it creates an entry in the EMPLOYEE_EXPENSE_RECORD table with the relevant employee and expense details. The EXPENSE_APPROVAL_STATUS column at this stage should be marked with a SUBMITTED status, assuming it is used for tracking the state of expenses. From a functionality standpoint it should be verified whether this is indeed the status. To be able to do that is soapUI will mean creating another JDBC Request test step. Name this as Verify Expense Record – Create Expense Record (here Create Expense Record is the name of the BPMN activity in the process model which executes the database update).
• In the JDBC test step, the connection string this time should be specific to the Expense schema that was created initially. The SQL query to fetch the record for a given employee is determined uniquely by the employee id and the record reference (populated with ECID).

SELECT * FROM EMPLOYEE_EXPENSE_RECORD WHERE EMPLOYEE_ID ='${#TestCase#EMPLOYEEID}' AND RECORD_REF='${#TestCase#ECID}'

• In the same test step, assertions can be added to verify the expense approval status and also the expense approver, if applicable. A JDBC status validation assertion is also added as this is something that should preferably added to each JDBC Request step.

• For this particular test case, the business rule will determine that a manager approval is required before the expense is presented to the finance user. The business process instances initiates a workflow task that is available to the designated user in his in-tray. In the most basic scenario the task is available to be be actioned by the user(s) assigned to the process swimlane role.
• At this stage if the audit trail of the instance is viewed it will correctly represent that the process has initiated and is waiting at the Approve Employee Expense human task activity.

• Interacting with the task is very easy and straight forward. Fortunately there is no need for a properly designed UI to be able to test the user interactions with the business process. Oracle BPM Suite 11g provides Human Workflow web services that can be invoked with the proper operations to simulate the UI behaviour.
• When an instance reaches any human task activity the human workflow engine initiates a task with the appropriate task metadata along with a unique taskId and number.
• The workflow engine captures this metadata in the WFTASK table in the dehydration store. Querying this table against the task definition name, composite instance id and the ECID will return a task identified for the initiated task.
• Create a JDBC Request test step yet again and name it as Retrieve Task Identifier – Approve Employee Expense. Use a connection string specifying the details of the SOAINFRA schema and the following sql query to uniquely determine the task identifier for the initiated human task.

SELECT WFTASK.TASKID FROM WFTASK WHERE WFTASK.TASKDEFINITIONNAME='${#TestSuite#MANAGERTASK}' AND WFTASK.ECID = '${#TestCase#ECID}' AND WFTASK.STATE = '${#TestSuite#TASKSTATE}' AND WFTASK.COMPOSITEINSTANCEID= '${#TestCase#INSTANCEID}'

• The task identifier that is fetched as a result of the sql query will be used in the future test steps to query and update task details using the workflow APIs. In order to use it forward, a property transfer step (Capture Human Task Identifier – Approve Employee Expense) has to be created to copy this value to the TASKID property of the test case.

• This task id will now be used in the forthcoming test steps to operate on the human task. In order to do so, first of all we will need to add two more WSDL files to our soapUI test project. These WSDL files can be located at the following end points after substituting the appropriate values for the host and port where the soa server is running. This will add all the operations in these services to the soapUI project catalogue.

http://<host>:<soaserverport>/integration/services/TaskQueryService/TaskQueryService?wsdl
http://<host>:<soaserverport>/integration/services/TaskService/TaskServicePort?wsdl

• Once the WSDLs have been added, add another SOAP Request test step. When prompted for a name put Get Task Details from Task Indetifier – Approve Employee Expenses (long but very descriptive, pinning down the actual human task activity in the process model for which this test step is performed).
• Select the getTaskDetailsByID operation in the TaskQueryService wsdl in order to retrieve the task details by providing the task identifier. Invoking this operation also requires appropriate credentials. The task identified is captured in the test case property TASKID. The operation returns the entire human workflow task consisting of the payload as well as additional task metadata. In order to ascertain that all functionality requirements are met, a couple of assertions could be added. As this is a synchronous service invocation, add assertions for a valid soap response, schema compliance and that no soap fault is encountered. These assertions are available in the Compliance, Status and Standards tab of the Add Assertion window.
• Apart from the web service assertions, also verify that the task state is correctly set to a value of Assigned. Also verify that the task version reason is equal to TASK_VERSION_REASON_INITIATED confirming that the task is in an initiated state at this stage. These elements are child of the systemAttributes element in the task data and can be queried with the following XPath expressions.

/*:Envelope/*:Body/*:task/*:systemAttributes/*:state
/*:Envelope/*:Body/*:task/*:systemAttributes/*:versionReason

• The task metadata returned from the service call has a section called task payload. This represents the initial arguments passed to the human task when it is initiated. As part of a manager approval or any other interaction with a form based user interface, process participants may change data in the forms (editable arguments) after which they may action the task (reassign, delegate, approve, reject, suspend etc.). Depending upon the functional requirements of task management, we may have to create appropriate steps at this point and validate the behaviour. For instance, tasks may always be reassigned to a team leader who may then reassign them to actual participants who have to then action them. In this case a test step to invoke the reassignTask operation in the TaskService service may be required. This test case assumes that a team lead simply puts in his comments (which is part of the payload here and saved to the expense record table) and approves the expenses.
• Add a property transfer step and name it as Capture Human Task Payload – Approve Employee Expense. The purpose of this step is to take the task payload from the response of the previous step, modify the comments child in the approval status element (replace it with a value such as “Manager Approved”) and transfer this to the TASKPAYLOAD property in the test case. In this example, an XQuery function is used to achieve this however any other smarter way can be employed too.

• Once the payload has been modified (mimicking the user’s behaviour in the form), the task metadata has to be updated in the dehydration store so that the workflow engine is aware of the changes made. This can be done by passing the modified task data to the updateTask operation in the TaskService. Add another SOAP Request test step to call it as Update Human Task – Approve Employee Expense. Choose updateTask as the operation from the TaskService. soapUI will populate the default request but the service will work with only the credential of the user trying to perform the update and the task itself (which is now available in the TASKPAYLOAD property). Apart from the usual soap based assertions an important assertion to be determined here is the state of the verionReason element in the task. Verify that it is now modified to TASK_VERSION_REASON_UPDATED.

• The final step in moving this task out of the manager’s inbox is to emulate his action, which can either be approve or reject. Task outcomes can be committed to the workflow engines through the updateTaskOutcome operation in the TaskService. Once an outcome has been received by the human task engine it will send a call-back to the business process with the response, which is waiting for it at the human task step. The business process will then proceed ahead, update the expense record table with the status of manager’s decision and evaluate the manager’s outcome at the exclusive gateway. As we are interested in the scenario where the manager approves the expenses the business process will initiate a task for the finance approver.
• The operation only requires the outcome flag and the task identifier along with the user credential in able to submit the request. There is one important thing to be kept in mind in this test step. Only those users who have been mapped to the swimlane role to which the task is assigned or reassigned to can update the task outcome.

• Create another JDBC Request step to verify that the expense record is updated with the expected value.
• As the task moves to the Finance Approver’s inbox, the WFTASK table can be again queried to determine the task id corresponding to this task. The following query (similar to the one used before) can be used to retrieve the new task identifier. The only difference in this query is the TASKDEFINITONNAME filter, which basically have to be set with how the finance approval task is called.

SELECT WFTASK.TASKID FROM WFTASK WHERE  WFTASK.TASKDEFINITIONNAME='${#TestSuite#FINANCETASK}' AND WFTASK.ECID = '${#TestCase#ECID}' AND WFTASK.STATE = '${#TestSuite#TASKSTATE}' AND WFTASK.COMPOSITEINSTANCEID= '${#TestCase#INSTANCEID}'

• At this point, a few of the test steps that were created to fetch the task id from WF task table, copy it to the test case TASKID, retrieve the task payload, modify it and then update the task outcome has to be repeated for the finance approval task too. To maintain visibility, append the name of the human task i.e Administer Expense Payment to each of these steps. After these steps are created the functional test case will reach a point where it has emulated all human steps in the business process, asserted the functional points, and verified that the instance is behaving as expected.

• Once a member of the finance approval team approves the expenses, notice that the business process model updates the payment register as well as the expense record tables. The business process then ends with a message based event viz. expense paid. This triggers an asynchronous call-back to the client calling the business process if it is waiting for one.
• As a next logical step in the functional testing scenario is to verify that the updates to the end systems has correctly happened and also to somehow receive the process end response to assert if it has the right status. It is also recommended to have some additional test steps to even verify that the instance state is marked as completed in the dehydration store to fully satisfy all functional aspects.
• To begin with these assertions, add a Mock Response test step in the test case and name it Receive Process Callback Response – expenses paid. Select the expensePaid callback operation from the ApproveEmployeeExpensePortTypeCallBackBinding interface.
• The port and the path has to be 2222 and ApproveEmployeeExpensePortTypeCallBackBinding respectively. This however depends upon what was entered in the original/initial soap request in the Reply To field. This step will automatically be populated with the callback response containing the approval status of the expense. Add the normal web services assertions to this test step as well an Xpath assertion to verify that the approval status is equal to FINANCE APPROVE

• It is also worth while to add a property transfer step to Capture the Expense Amount total and assign it to the EXPENSETOTAL test case property. This is done by summing all the amounts in the expense list submitted by the employee.

• As indicated earlier, the final steps in the test case is to create a couple of additional JDBC test steps to verify that the updates to the tables are consistent with the instance data by adding the necessary assertions.

• Optionally it can also be verified that the process instance has successfully completed. This can be queried against the dehydration store tables. The CUBE_INSTANCE and the COMPOSITE_INSTANCE table stores the process instance header and the state data. The state column has a numerical value which can be translated into a very informative physical state of the instance. The given query can be executed to retrieve and decode the status from these two tables.

SELECT (CASE
WHEN CU.STATE=0 THEN 'INITIATED'
WHEN CU.STATE=1 THEN 'OPEN AND RUNNING'
WHEN CU.STATE=2 THEN 'OPEN AND SUSPENDED'
WHEN CU.STATE=3 THEN 'OPEN AND FAULTED'
WHEN CU.STATE=4 THEN 'CLOSED AND PENDING'
WHEN CU.STATE=5 THEN 'CLOSED AND COMPLETED'
WHEN CU.STATE=6 THEN 'CLOSED AND FAUTED'
WHEN CU.STATE=7 THEN 'CLOSED AND CANCELLED'
WHEN CU.STATE=8 THEN 'CLOSED AND ABORTED'
WHEN CU.STATE=9 THEN 'CLOSED AND STALE'
WHEN CU.STATE=10 THEN 'NON-RECOVERABLE'
ELSE CU.STATE || 'UNKNOWN'
END) AS CUBE_INSTANCE_STATE, (CASE
WHEN CO.STATE=0 THEN 'RUNNING'
WHEN CO.STATE=1 THEN 'COMPLETED'
WHEN CO.STATE=2 THEN 'RUNNING WITH FAULTS'
WHEN CO.STATE=3 THEN 'COMPLETED WITH FAULTS'
WHEN CO.STATE=4 THEN 'RUNNING WITH RECOVERY REQUIRED'
WHEN CO.STATE=5 THEN 'COMPLETED WITH RECOVERY REQUIRED'
WHEN CO.STATE=6 THEN 'RUNNING WITH FAULTS AND RECOVERY REQUIRED'
WHEN CO.STATE=7 THEN 'RUNNING WITH FAULTS AND RECOVERY REQUIRED'
WHEN CO.STATE=8 THEN 'RUNNING WITH SUSPENDED'
WHEN CO.STATE=9 THEN 'CLOSED WITH SUSPENDED'
WHEN CO.STATE=10 THEN 'RUNNING WITH FAULTS SUSPENDED'
WHEN CO.STATE=11 THEN 'COMPLETED WITH FAULTS SUSPENDED'
WHEN CO.STATE=12 THEN 'RUNNING WITH RECOVERY REQUIRED AND SUSPENDED'
WHEN CO.STATE=13 THEN 'COMPLETED WITH RECOVERY REQUIRED AND SUSPENDED'
WHEN CO.STATE=14 THEN 'RUNNING WITH FAULTS, RECOVERY REQUIRED AND SUSPENDED'
WHEN CO.STATE=15 THEN 'COMPLETED WITH FAULTS, RECOVERY REQUIRED AND SUSPENDED'
WHEN CO.STATE=16 THEN 'RUNNING WITH TERMINATED'
WHEN CO.STATE=17 THEN 'COMPLETED WITH TERMINATED'
WHEN CO.STATE=18 THEN 'RUNNING WITH FAULTS AND TERMINATED'
WHEN CO.STATE=19 THEN 'COMPLETED WITH FAULTS AND TERMINATED'
WHEN CO.STATE=20 THEN 'RUNNING WITH RECOVERY REQUIRED AND TERMINATED'
WHEN CO.STATE=21 THEN 'COMPLETED WITH RECOVERY REQUIRED AND TERMINATED'
WHEN CO.STATE=22 THEN 'RUNNING WITH FAULTS, RECOVERY REQUIRED AND TERMINATED'
WHEN CO.STATE=23 THEN 'COMPLETED WITH FAULTS, RECOVERY REQUIRED AND TERMINATED'
WHEN CO.STATE=24 THEN 'RUNNING WITH SUSPENDED AND TERMINATED'
WHEN CO.STATE=25 THEN 'COMPLETED WITH SUSPENDED AND TERMINATED'
WHEN CO.STATE=26 THEN 'RUNNING WITH FAULTED, SUSPENDED AND TERMINATED'
WHEN CO.STATE=27 THEN 'COMPLETED WITH FAULTED, SUSPENDED AND TERMINATED'
WHEN CO.STATE=28 THEN 'RUNNING WITH RECOVERY REQUIRED, SUSPENDED AND TERMINATED'
WHEN CO.STATE=29 THEN 'COMPLETED WITH RECOVERY REQUIRED, SUSPENDED AND TERMINATED'
WHEN CO.STATE=30 THEN 'RUNNING WITH FAULTED, RECOVERY REQUIRED, SUSPENDED AND TERMINATED'
WHEN CO.STATE=31 THEN 'COMPLETED WITH FAULTED, RECOVERY REQUIRED,SUSPENDED AND TERMINATED'
WHEN CO.STATE IN (32,64) THEN 'UNKNOWN'
ELSE CO.STATE || ''
END) AS COMPOSITE_INSTANCE_STATE FROM CUBE_INSTANCE CU, COMPOSITE_INSTANCE CO WHERE CU.ECID=CO.ECID
AND CU.ECID='${#TestCase#ECID}'
AND CU.CMPST_ID='${#TestCase#INSTANCEID}'

• As a last step verify that the state in the cube instance table is CLOSED AND COMPLETED and COMPLETED in the composite instance table.

The test case is now complete in a way that it can successfully test all the major functionality of the business process. This increases operational as well as developer efficiency since continuous changes to business processes can be supported without too much worrying about them breaking existing logic. From here it is also possible to create functional test cases to test all possible paths of the business process. These test cases can be ran together as part of an integrated test suite. Creating additional test case is very easy as it mostly involves cloning an existing test case and making some necessary modifications with test data and steps. Once they are created they can be run together as part of the original Expense Approval Functional Tests suite either sequentially or in parallel.

Conclusion

soapUI also provides a way to run and extract reports out of these tests through ant/maven and hence it is extremely easy to incorporate them in the release cycle. If you can use soapUI pro, you have the out of the box ability to generate a wide variety of reports for the executed tests too. The basic version can be used to publish JUnit type tests, which I believe are good enough if considering running these tests in a continuous integration fashion.

Business process testing covers how well the system executes the functions it is supposed to execute; including user actions, data manipulation and integrations. It is done to validate the solution as defined in the business requirements and detailed technical specifications document for each processes. It may often contain the highest overall number of test cases, as it is focused on testing the entire system, not just small bits or units of code. Business processes are tested to ensure that the edits, changes, and outputs conform to the required specifications and/or expectations. Business process testing is also often the most complex area of testing as it involves testing processes during development cycles as it occurs and also when processes evolve through multiple changes post deployment. Automating this testing process will provide extreme productivity, quality and add dynamism to business processes. This article can be used as a reference to carve out a strategy to do so. Off course there may be may way but in my experience, I have found out this way to be effective, easy and without any financial obligation to invest in expensive tools.

The composite project, setup scripts, soapUI projects and some sample reports used in this article can be found here. Please feel free to share opinions, feedbacks and suggestions and I will be glad to provide any help.

.