You can create, update, delete, get details, or get all details for business rules using API’s. This table shows the base API calls.

The fields to be used in the create/update requests are listed below. The get details, get all details, and delete API’s do not require any entity information.

If you have created determining attributes with priorities, and want to use the priorities to quickly reduce the number of rows generated by those rules based on priorities, this can be done quickly via this API call.

The call is sent as a PATCH call. The ID of the rule you will be reducing is included in the URL.

The body of the call contains the context information, as well as the coverage set and the priorities you want to retain. These priorities will be applied to all determining attributes that have priorities set.

{
	"context": {
		"user": "mbj_test",
		"password": "xxxx",
		"project": {
			"name": "mug_test_project",
			"version": "1.0"
		},
		"coverage" : {
		  "name": "mug_test_coverage",
		  "version": "1.1"
		},
		"params" : { "priorities" : [1,2] }
	}
}

The return message contains information on the rule, and all of the attribute values that have been retained after applying the priorities.

In TDO, the revised rule (rule 1) can be seen with only the priority 1 and 2 values in the currency fields.

This API gets details on a single business rule in a coverage set. It is sent as a POST. The ID of the rule you want details on is included in the call.

The body of the call includes the context – user ID, password, and coverage set. No other items are required.

The return message on this API gives all details on the specified rule, including created by, updated by, and all of the conditions.

This is a PATCH call as opposed to a POST call.

In the body of the message, the ‘entity.ID’ is now a required field. We will update the complex rule created above. The ‘has_online’ determining attribute is being updated to include both ‘true’ and ‘false’ and the ‘currency_a’ attribute is being updated to include both USD and GBP currencies. Note that you must include all values that were set in the original rule that you want to keep in the modified rule. If you do not include a value that was set in the original rule it will be deleted.

The return message shows the values that were sent.

This call generates the coverage matrix from the business rules.

This is sent as a POST call.

The body of the call is simple; it contains the user credentials, project, and coverage set information.

The results of this call will display information on the generated coverage matrix. The body contains information on each row generated as part of the coverage matrix.

This call is sent as a DELETE call. You can only delete one rule at a time using this call, as the rule ID is part of the header.

The body of this call is the same as the details calls, only containing the context.

For this call, we are sending the ID for the third rule in the ‘Get All Details’ call illustrated earlier. The return message simply shows a successful call.

Viewing the business rules in TDO after this call is sent, you can see that the third business rule is no longer present.

This call will create a new business rule. You can only create one business rule at a time, so if you are creating multiple business rules you will need to run this for each rule.

The API can be used to create a business rule with one or more determining attributes. The key is that the determining attributes referenced in the body of your call must match the determining attributes in the coverage set you are working in. Below, we will show how to create a simple business rule (one determining attribute) and then a more complex rule (multiple determining attributes).

The call for creating the business rule is a POST call.

Simple (one determining attribute)

The body of the call includes the name of the coverage set after the base context (user ID, password, and project). The coverage set you identify must be locked by the user ID you are using to send this API. You will need to send the ‘lock coverage set’ API before creating business rules.

In the ‘entity’ section, you include both the determining attribute name and value(s) in an array. Note that all values selected must exist in the determining attribute as it is defined in TDO.

When the rule is created, the return message shows the rule ID as well as the contents of the rule.

Looking at the business rules in this coverage set in TDO, you can see that the rule was set.

Complex (multiple determining attributes)

For this call, we will use the coverage set ‘api_demo_coverage 1.1’. This coverage set has five determining attributes.

The body of the call for multiple determining attributes is set up as an array in the ‘conditions’ section. Note that you can select one or more values for each determining attribute.

The response to this call will show all of the attributes you defined in the body of the message.

The business rule now shows in TDO.

This API returns details on all rules within a single coverage set. It is sent as a POST, with the same header details as the ‘create’ and ‘update’ calls.

The body of the call looks like the body of the ‘Get Rule Details’ call.

{
    "context": {
        "user": "mbj_test",
        "password": "xxxx",
        "project": {
            "name": "imp_payments_demo",
            "version": "1.0"
        },
        "coverage" : {
            "name": "api_demo_coverage",
          "version": "1.2"
        }
    }
}

The return message of the API shows the information for all rules contained in this coverage set.

This coverage set now contains three rules; the information on all three is included above. In TDO, the three rules are also shown.