Updating business decisions is always challenging, but using a centralized business logic server, you can synchronize a decision service with your new updates ‘on-the-fly’.

A decision is generally an answer to a business question. To answer a business question, one or usually multiple types of business logic are involved. For example, the decision for calculation of an annual premium of a car has to answer two questions: How much is the Base Premium and Auto Premium of the car?


To build the above model along with its Decision Tables, you can use our modeling tool. For hosting and execution across your enterprise use our Decision as a Service platform that allows you to host the entire decision model shown above (decision module) as a REST service. Then this business decision can be shared across all processes and applications in different technologies (i.e., JavaScript, .Net Framework, etc.)

In running day-to-day business operations and processes, you would need to update the decision quite often. So you simply manage and apply changes to your online business logic. However, once a change is spread across multiple different logic types, it is not easy to apply changes one-by-one.

Synchronise Changes

What you can do is to build a deployment package containing all of your changes and upload it via the web administration console:

Upload Updates

And then you will have the option as to how you would like to apply the changes:


So you can package all the changes and apply them in just one simple upload. Synchronize the change of business decision and automate the update using the REST API provided or manually by using the Web user interface as described.

In this example, two Decision Tables were updated, and when you go back to the online viewer/editor, you can see that two of the logic types are updated:


Happy changing business rules and logic!

Skip Testing?

Since I posted the original article, I received some comments on LinkedIn that some would argue these types of changes should be a deployment because they need to be tested properly.

I just wanted to make a note here that this approach does not mean we just skip the testing process, or we don't do any QA…

This actually means that there are more effective and optimal processes to ensure the changed logic is working properly. Because the business logic is now separated from the application, and isolated in modules as well, when the business logic changes you do not need to test the entire application!
By running testing scenarios and regression testing of business logic, you make sure the logic is correct and you have not broken other logic types within the business logic service.

What If…

In any software, despite all the tests that are written and regardless of whether QA activities and processes are in place, still there is the possibility that something will go wrong, and you discover a defect… In a normal scenario (not using this platform), what would you do if you need to re-run the old version until you fix the nasty defect? You just re-deploy your old services (i.e., micro services, Web API, etc.).

However, here is a much simpler solution. You change the running version of your logic to the previous version just by one click, on-the-fly. That's it! No redeployment – you get to choose what version of logic is running.

As a matter of fact, you may actually want to run multiple different versions of logic as a service side-by-side. Even that's not an issue. This allows you to keep running multiple versions of your business logic without affecting each other and with no deployment hardship.

Book a Custom Demo

First or last name is too short

Read More

  1. Synchronize Decision Service
  2. .NET Decision as a Service – REST API Client for .Net
  3. SOA for Business Rules and Logic
  4. Manage Online Business Rules
  5. Decision as a Service
  6. JavaScript Decision as a Service – REST API Client for HTML/JS

Last updated June 26th, 2024 at 02:29 pm Published August 20th, 2015 at 10:52 am