Processing Rule Engine

In the other lessons of this course we provided the concept of SAP BRH, what it is exactly, what are the features, the business case and in general the overview. In the second blog we described the general characteristics of the User Interfaces and two of the three most important configurations: Manage Release Configurations and Manage Quality Departments. As shown in following figure however there is also a third configuration needed: Manage Business Rules.

Business rules allow you to automate decision making. If a business rule is assigned to a release check, the data that's received from the source system is evaluated against the business logic encapsulated in the rule to determine the release check status.

A business rule run is triggered whenever new data is received from the relevant source systems and the corresponding release decision items have not yet been completed. Once the business rule run is completed, the corresponding release check status and release check messages are shown in the My Release Decisions app.

Business rules are included in rule projects and defined in the Manage Rule Projects app. As a business administrator or configuration expert, you can adjust the preconfigured rules according to your needs or create your own rules.

Business rules are implemented in BRH using the SAP Business Rules service. Several tutorials exist on the use of SAP Business Rules services. This service is technically part of the SAP Workflow Management for which extensive documentation and tutorial are available.

There are different cases of application of release checks, in which Business Rules play different role.

In the first case, the back-end engine does not only store information but also decides on a specific data object and sends that to SAP BRH. In that case, SAP BRH is only used to check and visualize the data.

Another situation could be that systems sends data to SAP BRH but then the decision is executed in SAP BRH through SAP BRH rule engine.

A third case is also that the decision is take by user as shown above.

Lets now go through a real case step by step, in order to understand what is needed to do when something goes wrong. In this set of screenshots we are simulating a purchase of external materials and approval of a technical batch release. 

According to the internal Specification (SOP) of our virtual pharma company, for the "Tech Release Ext Procurement" (that we called TR-IHLS) the QP of our company needs to execute the following checks :  

• Certificate
• Change Control Data
• Deviations
• Manual Release
• Temperature
• Transport conditions

As you know from the previous lesson, these are configured in the "Configure Release Type" section of the "Manage Release Configuration" app, as shown hereafter.

In other words, our plant (1710) has purchased Fentanyl and is creating an internal technical release of an isotonic solution (Water and Sodium Chloride) .

On the right is the User Interface of a user that is Qualified Person (and in this case has also all rights to see all apps of BRH, quite unrealistic since usually will only see the apps that are needed, but here is to simplify the demonstration).

A typical process flow for the incoming product in SAP S/4HANA is:

1. Purchase Order is created as shown in the screen shot. In the purchase order you would be also able to assign already the batch number of procured materials.

2. Based on the purchase order you created the good receipts. The goods receipt will be booked and the batches will be stored in restricted stock.

3. In the material master it is maintained that an inspections lot of goods receipt from procurement will created, the settings will be maintained in the Quality Management Tab. The inspection lot is the release decision trigger.

According to the lesson 3 the different status values will be configured in SAP S/4HANA when the release decision trigger will be created out of the inspection lot. In that flow, transport check status and temperature check status, are set in S4 via a user status to simulate the those two checks. For our example with the certificate check the check will be executed based on the system status CHOK After executing the corresponding activities manually then one will see a LOG in the SAP S/4HANA window.

In SAP Batch Release Hub for Life Sciences you can check in the logs whether the inspection lot has been transferred to SAP Batch Release Hub for Life Sciences and the release decision trigger has been created.

In the App Monitor Data Processing you can see the release decision trigger for the created inspection lot from step 3 has been created and then in App Data Monitoring - Manage Staging and Active Area app selecting the Inspection Lots - Active

One can now inspect the status of the release decision in SAP BRH and the corresponding content in SAP S/4HANA (QA03 is the transaction to Display an Inspection Lot).

In the SAP Batch Release Hub for Life Sciences the release decision item based on the inspection lot shows the following release check of the release of a procured good. The release checks for certificate check and our manual check are still pending. For the explanation of the business rules we will focus on the certificate check.

The reason for the pending in Certificate Check is due to the fact that the Certificate has not yet been added in SAP S/4HANA for that Inspection Lot and the requested status on the inspection lot is not been set.

The standard way is that the certificate will be sent accompanying the delivery or also via a digital transfer.

1. The first step would be to record the certificate based on the purchase order via transaction QC51.
2. in the transaction QA02 Change Inspection Lot, you can add the physical document.
3. Insert Row, set Type =SQM (Simplified QM) and chose a document that has previously been uploaded in SAP S/4HANA or upload a document correspondingly. In the demo we have already a sample Certificate of Compliance. If all is done appropriately, it should look like the following, then click on "SAVE".

A last check is still pending, the "Manual Release Check". In the default configuration of BRH this check does not exist. Reason for that is, that "Manual Release Check" is a release check that has been created out of the "Custom Release Check" type, and as example we will cover this topic in one of the next lessons.

While we were working on the release of this batch suddenly new checks have been required by the new SOP (you can see the green bar has now 6 checks while before had only 4) however according to the available data these are all compliant with the specification.

At this point all checks are completed and a Batch Release decision can be taken and set through the "Set Release Decision" app as described in Setting Release Decisions | SAP Help Portal.

In proxied or federated identity provider (IDP) environments, the e-signature functionality of SAP Batch Release Hub for Life Sciences requires an additional non-proxied SAP Identity Authentication Service (IAS) or similar IDP to be configured specifically for release-responsible end-users. Therefore, users who want to sign with e-signature must be actively managed in SAP IAS or a similar IDP and be granted an additional password.

Identity Authentication Service in a Nutshell - YouTube

The above video illustrates the main usage scenarios for identity authentication.

While it does not address the specific of BRH Signature mechanism, it gives understanding on the overarching security architecture .

Additional videos such as Cloud Identity Services Identity Authentication | SAP Business Technology Platform - YouTube are available to deeper understanding.

The decision is taken and a password is required additionally - for compliance with Electronic Signature Regulations. In this case, it is the password that one has set in the IDP.

The E-Signature process requires some configurations to be performed, that are described in detail in Configure Integration of E-Signature | SAP Help Portal.

SAP Batch Release Hub for Life Sciences uses the OpenID Connect (OIDC) API for e-signature user re-authentication. This requires configuration of the integration between the identity provider that is designated for e-signature users and SAP Business Technology Platform (SAP BTP).

You must create a new OpenID Connect application in IAS or your third-party identity provider. This is a task that the BTP Administrator of your sub-account must perform and is described in Create an OpenID Connect Application | SAP Help Portal.

Once that is performed then the SAP BTP Administrator must create the target destination in the SAP BTP cockpit.

In the above drawing we see on the left side the screenshot of the configuration of the BTP DESTINATION "IDP_OIDC_URL", and on the top right we see the specific value from the corresponding Trust Configuration of the IAS tenant to be used.

Hereafter is the mapping between the names of the variables between the two interfaces:

Documentation: Create HTTP Destination for E-Signature | SAP Help Portal

The concept of applying business rules to data and allow these to be defined directly by the business is not new to this SAP product.

If one searches in the help documentation of SAP will find :

• SAP Business Rules Framework (BRF)

  The BRF is an event-controlled runtime environment in which the system processes certain rules. You can assign any number of rules to each event, whereby a rule normally consists of a Boolean expression and an action. If the expression returns the value TRUE, the system executes the action.

  The BRF also contains a maintenance environment in which you can edit and configure BRF objects. You can configure both technically oriented as well as business process oriented rules. This means that you configure the rules in the maintenance environment, and the system processes the rules in the runtime environment.

  The BRF is object-oriented and therefore offers appropriate enhancement mechanisms that are modification-free and upgrade-independent ( Business Rule Framework (BRF) | SAP Help Portal).

• SAP Business Rules Framework plus (BRFplus)

  BRFplus is an ABAP-based framework and is therefore best suited for integration into an ABAP-based system environment, for example, as an extension to an existing component of the SAP Business Suite. However, if your system environment is mainly Java-based, or if you plan to implement business rules for a system landscape based on service-oriented architecture (SOA), you may consider using the Java-based SAP Business Rules Management (BRM). SAP BRM is available with SAP NetWeaver 7.1 EhP1 or higher.

  It is also possible to implement a scenario where both components are used simultaneously: In a mixed environment with ABAP as well as Java parts, both engines may be used in their respective area. BRFplus and SAP BRM can call each other. This means that, for example, you can maintain rules in SAP BRM and call them via remote calls to be used in BRFplus and vice versa.

  Finally, even in an SOA environment it may be a good idea to use the web services of BRFplus. This is true for scenarios where the major part of the data to be processed is stored in an ABAP backend system. Here, using BRFplus brings advantages in terms of performance, sizing, and the availability of the integrated workbench(Business Rule Framework plus (BRFplus) | SAP Help Portal).

• SAP Business Rules Services

  SAP Business Rules service is a technology service that translates business decision logic into a natural language that is configurable directly by line of business key users, knowledge experts without IT or developer intervention. It provides solution architects and developers web based tools to model, author and simulate business rules independent of the backend system.(Overview | Business Rules Service | SAP Business Accelerator Hub)

• SAP Business Rules Capability for the Cloud Foundry environment

  The business rules capability within the SAP Workflow Management service lets you digitize and automate decision making. It encapsulates dynamic decision logic from application logic. It also provides web-based tools to model business vocabulary and decision interfaces to integrate with SaaS applications and business services. Business rules let you automate the decision-making process for a business scenario. For example, in an employee onboarding scenario, you can model business rules for the HR team to automate the equipment determination step for a new hire. Depending on the employee's designation, the required equipment can be automatically determined without the intervention of the HR team (What Is Business Rules Capability? | SAP Help Portal).

• SAP HANA Rules Framework

  Provides tools that enable application developers to build solutions with automated decision services, implementers and administrators to set up a project/customer system, and business users to manage and automate business decisions based on the organization's data. In daily business, strategic plans and mission critical tasks are implemented by a countless number of operational decisions, either manually or automated by business applications. An organization's agility in decision-making becomes a critical need to keep up with dynamic changes in the market. For example, applications for use in the insurance and banking industries must be able to accommodate the inevitable market changes that no one can predict or plan for. An application's ability to undergo changes in its decision-making logic depends highly on the method of implementation; for example, one application may require a complete version upgrade to provision for necessary updates to its rule logic, while another application may empower its business users to implement on-the-fly changes without needing to implement any updates to the actual application. An application that has SAP HANA rules framework integrated in it is a prime example of the latter. SAP HANA rules framework provides a set of tools enabling business users and application developers to build decision logic based on the organization's data. This rule engine applies rules and outputs as defined by end users without affecting how the application runs. The application is built to deal with the rules, which are designed separately (SAP HANA Rules Framework Overview | SAP Help Portal).

• Text Analysis CGUL rules

  Extraction rules (also referred to as CGUL rules) are written in a pattern-based language that enables you to perform pattern matching using character or token-based regular expressions combined with linguistic attributes to define custom entity types.You can create extraction rules to: Extract complex facts based on relations between entities and predicates (verbs or adjectives).Extract entities from new styles and formats of written communication.Associate entities such as times, dates, and locations, with other entities (entity-to-entity relations).Identify entities in unusual or industry-specific language. For example, use of the word crash in computer software versus insurance statistics.Capture facts expressed in new, popular vernacular. For example, recognizing sick, epic, and fly as slang terms meaning good(SAP HANA Text Analysis Language Reference Guide | SAP Help Portal)

• As one can see from above
  • Business Rules are "primary objects" in the SAP vision of enabling intelligent businesses.
  • Some sort of interoperability is possible (for example, Business Rules created on the SAP BTP Service can be automatically transformed into SAP S/4HANA Stored Procedures and in BRFPlus) however for most of them a manual intervention is needed
  • Rules written in ABAP BRF cannot be automatically converted to Business Rules on the SAP BTP service
  • CGUL rules can only be used within the text analysis system of SAP S/4HANA

For all of the above reasons, and many more, particularly in the text analysis world there has been a trend of automatically generating rules "learning" from data patterns.

Perhaps that will happen also for "structured" data, or "learning from behaviors" shown from experts .. as it happened in text analysis, translation systems, and BOTS .. through so called machine learning and artificial intelligence.

In the rest of this presentation we now focus on the Business Rules used in BRH.

SAP Business Rules service is a technology service that translates business decision logic into a natural language that is configurable directly by line of business key users, knowledge experts without IT or developer intervention. It provides solution architects and developers web based tools to model, author and simulate business rules independent of the backend system.

The main advantage of SAP BTP Business Rules is that they allow to separate the application logic from the business logic. This means that one can maintain the rules independently from the source code that the developers wrote as a whole. So what does this mean? Imagine you have certain kind of policies, business rules you would also like to implement in your applications. So with the Business Rules Service you are really able to maintain these rules independently. Whenever there are changed, you can just adopt the rule and you don't need to take a look at the application implementation itself. With the Business Rule Service, we also provide you capabilities to manage all your rules centrally, so our aim is really to provide you one environment where you can design, but also govern all the business rules running in your company. So finally we really provide capabilities to rapidly build and extend business rules and use them wherever you need them.

The rule service is more or less a communication to the outside world. So in that example is mentioned the discount rule service, that will be used to give certain discounts on specific products based on their categories.

Then there is the notion of rule sets. This is very interesting because you can combine different kind of rules into one common set and let them execute and then finally the rule itself.

If you take a look in that example you can find promotion rules, delivery rules, shipping rules and discount rules. If we take a look here, then we can see that there is a decision table to actually define the rule, so this means if a certain product category has been chosen in the application and depending on the product and also depending on the product seller name, then there would be a certain discount. So for example if we choose less than 10 smartphones we would get 5% of discount. If we choose 10 or more than 10 smartphones we would get 30% of discount. Now let's take a look how this actually is working then in the application. We have here the shopping cart application and now we would like to buy some smartphones. Let us take here the Astrophone, add let's say two of them to our shopping cart. If we take a look at the shopping cart and proceed to the checkout, we will see that we will get a 5% discount. So this is actually this, what we have maintained also in our decision table. But now let's move on and add some more of these phones to our cart. So let's say you would like to purchase 11 of these Astrophones. If you proceed, then you can see the discount has been changed. we have here now 30% at all. In addition to that we are only not limited to this kind of discount rules based on product category. No, for example we can also make for specific dates. For example we will get here an end of season sale discount by 5%. Also this has been maintained in the business rule. So this was just a short overview on the business rule service.

This technology is used in SAP Batch Release Hub for Life Sciences in order to facilitate the automatic decision making. Namely, each time new data reached SAP BRH, this triggers the execution of all the rules for the specific batch. All the rules are executed and then the corresponding status information is shown to the user.

Without the rule engine, the user would have to check manually all the values of the various parameters, would have manually to see if tor the specific release type all the data has been collected and the values are all valid.

This is all automated by the rule engine system, and the rules themselves are 100% under control of the business user, with the appropriate SAP BTP rights, so that these can be adapted accordingly.

As described in "Business Rules Capabilities for the Cloud Foundry Environment" , the workflow to create and deploy rules is an activity that is typically done by the Application or Content Developer. In BRH this is directly accessible to the customer so that each customer can have their own rules.

The following figure, taken from the Development | SAP Help Portal, shows a typical flow for creating and using rules.

1. Add data objects with attributes that represent your application context and optionally associate data objects based on mapping attributes.
2. Define the interface between your application and the rule runtime, and set the data objects to the rule service based on their usage.
3. Model your business logic using business rules. Define the condition constraints and the results to be returned for different business logic.
4. Configure the ruleset by grouping the related rules together and assigning them to a rule service.

The above approach, that is achieved through embedding of the Business Rules Capability within the SAP Workflow Management, is hereafter demonstrated on how is used in BRH.

In our example let's focus on the Certificate Check. It is one of the mandatory release checks that are prescribed in our fictious SOP for the specific release type we chose. As you can see in the below image, the Certificate Check is determined by the Business Rule "SAP CertificateCheckProject"

We have also learned that in the Allowed Release Check Status there are specific values that also impact the release. Specifically, if the ID = NR or CD then the release can take place without restrictions, otherwise either is not possible or with comments.

The rules will determine for the specific input what could happen.

If we therefore go into the "Manage Business Rules" app (given appropriate BTP rights) you will see different "Rule Projects". These are those that we preconfigured according to our market analysis of customer needs for automation of the batch release decision. However, you can create your own projects too. This is described in the "Create a Project" documentation.

For the specific of the Certificate Check, we have seen above that the "SAPCertificateCheckProject" is used. We can inspect it in detail by clicking on it from the Rule Projects overview page.

A project is used to configure and manage the entities of business rules capability.

Features of a project include:

• Name: This must be without "spaces" and be present only once in the list of Project Rules. Therefore in this case we called it "SAPCertificateCheckProject".
• Label: A label can be provided to the project and its entities along with the name and description for globalization. If a label is maintained for each entity of the project, the label name is displayed in the header of all the entities, breadcrumb navigation, and the autosuggest list, is good practice to have it closely resembling the Name of the project as provided above, and adapted for easier reading by non developers, e.g. "SAP Project for the Certificate Check"
• System: BRH provides "embedded" its own rule engine, however one can also extend it with additional instances of the BTP Rule Engine. In our case we use "Cloud Runtime" as that is sufficient and appropriate.
• Reference Currency: could be used if one needs to have rules that employ a specific monetary currency. For the purpose of BRH this does not apply and therefore is not used in this check.
• Version Management: Create different versions and revisions of a project. Projects are categorized based on their working state as follows:
  • DRAFT: The project that you are currently working on.
  • REVISED CONTENT: The project that has been released and is ready for consumption.

    See Manage Project Versions and Revisions | SAP Help Portal

• Project Hierarchy: The project hierarchy feature lets you create a project with content that is separable. It includes the following functionalities:
  • Inclusion of other projects in your project to consume its exposed vocabulary (In this case "SAP Base Project(Final)"
  • Exposing your project vocabulary so that it can be consumed in other projects.
  • Extension of data objects of the included projects.

In BRH SAP provides various application templates as a projects to the customer. Customer can extend the template project to create an extension project with their own content. The extension project can then be included in the end user's local project to create a project that is independent of the template project content. This ensures content separation in each project.

We can inspect what is provided by the "SAP Base Project(Final)" by going back into the "Manage Rule Projects" and selecting the "SAPBaseProject". We will notice that it is a "container" of the output produced by applying the rules to the data.

Expression Language: The rule engine is configured to "understand" a specific business language. This is specified as "Expression Language 2.0". As described in the above mentioned link, Expression Language 2.0, which is based on DMN FEEL, provides a standard syntax for rule conditions, and reduces ambiguities while modelling a rule in business rules. Friendly Enough Expression Language (FEEL) is an element of the Decision Model and Notation (DMN) standard and is an improved approach to modelling business decision logic.

It is also highly recommended to copy the standard rules and adapt the rules to your need otherwise changes might be lost, with a new release update.

The following examples illustrate the syntax and context specification of Expression Language 2.0:

Typical operands in Expression Language 2.0 are as follows:

• customer.annual income:

  annual income is the attribute of the data object customer.

  Meaning: The annual income of the current customer.

• customer.customer name:

  customer name is the attribute of the data object customer.

  Meaning:The name of the customer.

A typical rule condition in Expression Language 2.0 with the above operands is as follows:

customer.annual income >= 500000 AND customer.customer name MATCHES 'John'

Meaning: The annual income of the customer is greater than or equal to 500000 and the customer name is 'John'. Here, customer is the data object label, and annual income and customer name are the attribute labels of the data object customer AND and MATCHES are the operators.

A data object is a reusable entity that represents the data domain of BRH. Full documentation on the meaning of each aspect of this component are described in the "Model Data Objects" documentation, there you will find all details about the types of data objects, their attributes, and all other aspects (mostly not used) that you will see in the user interfaces.

Clicking on "Data Objects" shows that this project deals with data that comes from the "CertificatesActive" data structure.

The "CertificatesActive" data structure can be observed by clicking on the "CertificatesActive" row. In the following screenshot one can see that the data structure accessible by the "SAP Project for the Certificate Check"

• is documented in detail in the SAP Business Accelerator Hub (SAP API HUB)
• it is a subset of the whole object as in the SAP API HUB

Further scrolling in the SAP API HUB page one can see all fields of this data structure and also those not accessible by the rule project.

So, the check that is implemented (and that can be changed by the SAP BRH administrator adapting at specific customer needs) will access the fields from the CertificatesActive and then generate output in the SAPOutputTable (itself relying upon the SAPOutputStructure).

The Ruleset is connecting the input data object (CertificatesActive) with the output data object (SAP Outbut Table) and with the rules (Determination of Release Check Status).

In order to make absolutely sure that the ruleservice is *really* deployed one has to follow the following steps:

1. In Manage Rule Projects check the checkbox on the left side the Project name of interest.
2. Click on the „History" still having the checkbox on the selected project name
3. Click on the radio button specific for the latest version
4. Then click on the line item
5. Click on the Rule Service Tab
6. Check the checkbox with the name of the rule service
7. Click on „deploy"
8. Select "Cloud Runtime" If at this point an error message pops up and shows „Rule service version : … for given rule service Id : … is already deployed" then the project is properly activated.

It is really important that the check be executed through the "History" step, any other attempt will not result in a meaningful result.

The above screen shows the rule that determines how the Certificate Check should be calculated.

A easier visualisation of that rule can be obtained by clicking on "Export"

Here we can see that there are 5 different rules that relies on

• isCertificateCheckRequired_ID
• certificateCheckStatus_code

They are addressing various situations on the input possible values. Hereafter a different representation of the logic covered by those rules.

We can check if these rules really worked by filtering in the "Monitor Data Processing" for the corresponding events of type "Business Rule Executed". We should expect to see two records, a first one with the status "ND" and then a second one with the status "CD".

In the first screen, you will see that the Certificate Check was "gray". The meaning of that color is described in the "Gray for Pending Information" section of the online help (Color and Impact on Release for Release Checks | SAP Help Portal).

Let's remember from the previous screens

• Batch ID 0022440039
• Batch Material ID MZ-LS_3001
• Plant ID 1710

In the "Monitor Data Processing" app, we want to identify precisely what happened in BRH as soon as the certificate was added to the corresponding Inspection Lot in S4. For this reason we want to filter for the Record Type "Certificates", and focusing on the Batch ID 0022440039.

As shown above, we can see (sorting on date) that at first, SAP S/4HANA sent a Certificate specific to our batch in the Staging area.

The record was then activated, and then the business rule was executed.

Let`s now consider step by step what happened.

1234567891011121314151617181920212223242526272829303132333435363738394041424344
{"data": {
"sourceModifiedAt": "2022-11-04T09:42:12Z",
"batch_ID": "0022440039",
"batch_material_ID": "MZ-LS-3001",
"batch_plant_ID": "1710",
"certificateCheckStatus_code": "CD",
"isCertificateCheckRequired_ID": "Y"
},"executedRules": [
{
"project": "SAPCertificateCheckProject",
"input": [
{
"CertificatesActive": {
"batch_ID": "0022440039",
"batch_material_ID": "MZ-LS-3001",
"batch_plant_ID": "1710",
"certificateCheckStatus_code": "CD",
"isCertificateCheckRequired_ID": "Y",
"createdAt": "2022-11-04T09:42:21.072Z",
"status_ID": "A",
"sourceIdentifier": "myS4",
"sourceModifiedAt": "2022-11-04T09:42:12.000Z",
"snapshotTime": "0"
}
}
],
"output": {
"Result": [
{
"SAPOutputTable": [
{
"SAPBaseOutputValue": "CD",
"SAPBaseOutputMessage": "SAP_001",
"SAPBaseOutputReleaseCheckType": "CERT"
}
]
}
]
}
}
],
…
}

By clicking on the first row of the previous table we can see the INBOUND Payload that was sent to the "staging".

It consisted of the various required parameters for the payload ( as specified in the API Hub) and then specifically

"isCertificateCheckRequired_ID"= Y

andcertificateCheckStatus_code = "CD"

From our understanding of the above rule, we would now expect that the rule engine, after the data is migrated in the Active area, will be executed and return a green check.

This is in fact reported in the last row of the previous image, there we can see that he Event Record of type Business Rule Executed is executed, for our same Certificate.

By clicking on the last row we can see that the "Inbound"tab shows both the data that has been used, and as well the rule that have been executed.

One can select the "Inbound" content and then look at it for example with a text editor , this is shown on the right side of the above figure.

Hereafter few aspects are emphasized:

1. The SAPCertificateCheckProject was used
2. The Input had "isCertificateCheckRequired_ID="Y" and "certificateCheckStatus_code= "CD"
3. The output has the "OutputMessage" = "SAP_001" and "OutputValue" = "CD

All worked out as expected.

Through this tutorial you should now be in the position of create new rules, understand how they work, and be able to find out eventually when these do not work as you expect … perhaps due to a change in the original data.

For deeper learning on this topic I recommend you to follow the Unit2 of the open SAP course "SAP Cloud Platform Essentials" SAP Cloud Platform Essentials (Update Q3/2017) | openSAP. That course has been made in 2017 and therefore it uses the previous product name ( Cloud Platform ) while the current one is "Business Technology Platform", however for the details of the Business Rules service this is not an important difference and also shows that the Business Rules services has quite some level of maturity.

Congratulation ! You reached the end of this lesson. By now you should have a good understanding on

• How you can check when something does not work as expected
• How they work
• The Value that Business Rules are bringing to your batch Release decision process

Next step is now that you start creating your own rules, assign them to the release type that you need and proceed with further optimisations of your process.

Get Started with Business Rules Capability | Tutorials for SAP Developers