Generally, the simulation process is implemented by calling rules service via a invoker and by passing parameters. I have also seen simulation run against ADB file. The issue with the above approaches is that the user cannot change rules and run the simulation again.
The nirvana for the users would be to make a change in the rules and then run the simulation. After looking at the result they might choose to run the simulation again. And they would want to do all this without the involvement of IT.
The solution described in this article will guide you on how to build a simulation module which can be run from RMA. I have worked only on java version of Blaze so this article will refer mostly to Java version. This will be a high level approach and I will not be supplying SRL Code. You can contact me if you need further assistance.
I have used the term “Rules Service” throughout my article as reference to the execution or runtime component which can be POJO, WebService or MDB. Please refer the Blaze Fundamentals for some basic information.
The advantages of this approach are -
- The module will piggy back on the BrUnit execution framework.
- User friendly as the interface will be built with function templates.
- Users will be familiar with the interface as it will within RMA.
- Avoid additional licensing cost.
- Avoid additional cost of building client interface as we use RMA.
The solution makes a few assumptions –
- The rules service uses a function end-point.
- The rules service accepts a input and gives a validation or assessment as output.
- You have code which can get you the required input by passing a unique ID.
- You understand BrUnit, function templates and a bit of java. I also assume you have a RMA setup up and running.
Step 1 : The service
You will need a service which can get you the input to the rules service entry point. The service should accept a unique ID (Transaction ID, Claim ID, Policy ID, Case ID). The unique ID should be able to get you the input that you need. The service should Java based so that you can import into Blaze.
In most of the cases the service would already exist as your system will be using it to pass the input to the rules engine. We will call this service “input service”.
Step 2 : BrUnit (Initialization and run simulation)
You can use any kind of repository (versioned / non versioned). Create a BrUnit function template which will accept the following –
- TestName – Name for the test.
- Unique IDs – A unique ID which you pass to the service to get the input to the blaze.
- Threshold – The allowed number of failures.
- Email – email of the user to send status updates.
- Comments – A note to identify what kind of simulation was run.
The SRL part of the function should contain the logic (SRL) in the below order –
- Parse the Unique IDs to get individual IDs and put them into an array.
- Then pass the unique ID to the service which will then return the input to the rules service.
- Pass the unique ID to the entry point and store the response in an array.
- Keep track of exceptions during the call.
- If there is any increment the threshold counter by 1.
- If the threshold count in more than the threshold value set then terminate the simulation.
Step 3: Results processing (should be the last part of BrUnit function)
How you handle the processing depends on your requirements. It can be as simple as processing the array of returned results and displaying it on the screen using the assert function or using a java utility to append the results to a CSV file and then email it to the user.
It can be tricky as the assert the function will accept only a string value. So you will have to concatenate the response and then show that using the assert function. Remember that you have always have to set the assert function to false so that it fails and displays the results on screen.
I have successfully implemented a Java utility which will parse every response from the service and append it to a CSV file and also append a summary at the end of the file. I used the utility to email the simulation file to the user. You can also use the email feature to send regular updates to the user so that they are aware of how the simulation is progressing.
The solution described in this article will guide you on how to build a simulation module which can be run from RMA. I have worked only on java version of Blaze so this article will refer mostly to Java version. This will be a high level approach and I will not be supplying SRL Code. You can contact me if you need further assistance. I have used the term “Rules Service” throughout my article as reference to the execution or runtime component which can be POJO, WebService or MDB. Please refer the Blaze Fundamentals for some basic information.
Step 4: Execution
The execution is the simplest of all. Go to BrUnit execution and execute the BrUnit test. You also probably need a refresh functionality. The refresh functionality will allow the business users to get a fresh copy of the rules so that the user can run a new simulation. The refresh is a must have as multiple users can login and make change and then forget, if the user forgets to undo the change the next simulation run will not have proper results. To avoid such situations a fresh is a must.
The Simulation that I have developed in past had the below features –
- Accept a threshold or max no. of failures.
- Send email updates every 25% of processing is complete.
- Email update when the simulation terminates.
- At the end send email with simulation results (CSV file) attached to the user.
- Generate graphs for better visualisation using jGraph.
- Had a simulation refresh functionality.
- Executed high volumes up to 10,000 calls.
Some of the disadvantages of this approach are -
- Not a scalable solution.
- Difficult to maintain.
- Making UI enhancements can be difficult as templates are more suited for rules testing.
- Need to write and maintain some custom code.
- BrUnit is designed for unit testing.
- You will have to write code to create reports – so no fancy reports.