"So I just saw this film about these people making a movie, and the movie they were making was about the film industry..."
"Dude, that's so meta. Stop before my brain explodes."
One of my favourite features of Decision Service Management is the neat way it handles metadata references, so that I can create rules for any managed system (i.e. a system whose rules are governed by DSM) referencing data dictionary definitions, database tables, function modules and ABAP classes *without* having to transport those objects into the DSM system itself. It really is a very cool answer to enabling all sorts of calling applications to integrate with decision services (aka BRFPlus rule functions) without overburdening either the DSM or the managed system.
But if you are new to DSM, it does take a minute or two to wrap your head around how metadata works, and how that impacts what you need to do in DSM.
Why we need metadata
DSM acts as a central rules build, test and governance environment across multiple managed systems. Those multiple managed systems could be the DEV, QA and PRD instances of ECC, SRM, CRM, HANA, etc. With such a broad mix of systems there are always going to be occasions when we need metadata to cope with the differences between systems. Typical use cases are:
1. Different managed systems have different dictionary objects.
E.g. the database table CRMD_ORDERADM_H exists in a CRM system but not in ECC or SRM.
DSM needs to know whether that dictionary object can be used in a rule or not, i.e. will the rule run in CRM or in SRM or in ECC or HANA?
2. Different managed systems can have the same dictionary object but that same dictionary object might have a different definition.
E.g. The structure ZMyTableType might have 5 fields in QAS and PRD, but in DEV it has 7 fields as it is being extended as part of a project.
DSM needs to know whether the structure matches what the rule is expecting - i.e. have the new fields been transported from DEV to QAS yet - before it can deploy the updated rule to the QAS system.
3. Different managed systems have different database tables, function modules and ABAP Classes.
If a rule is using a DB Lookup expression to search a database table, or a Procedure Call expression to call a function module or ABAP Class method, then DSM needs to know if the database table, function module, or ABAP Class method exists in the managed system.
Now of course DSM could maintain a remote connection to all of the managed systems all of the time, just to make sure everything was in synch. But that's rather tedious and inconvenient, especially when different systems may need to be down for maintenance at different times. It's even more annoying for sandpit systems, where the system may be here one day but gone the next. You don't really want to have to go clean up all those rules, especially after a successful proof of concept when you want to retain your rules as much as possible so you can redeploy them to your DEV system to start the productive project.
So DSM is smarter than that. It uses metadata so that:
a) It only contacts the managed system at certain points to confirm if the metadata has a match in the managed system.
b) It only holds metadata references not the actual metadata itself.
Think of the metadata reference as a kind of copy of the essential details that DSM needs, so that the actual metadata - dictionary objects, function modules, ABAP Classes, etc. - never need to be transported into DSM itself. The metadata reference means DSM knows enough about them so that the rules build can continue without the managed system having to be available all the time.
Baselining metadata: Assignment to Managed System
For DSM to use metadata references, it needs to know that metadata is needed and which system to use as a baseline for metadata references. In other words it needs to know which system is the source of truth for the correct version of the metadata. That way if it is deploying the same rule to more than one managed system, such as ECC DEV, ECC QAS, and ECC PRD, it knows which version of the metadata is needed, and can check that the metadata reference DSM has matches the actual metadata in the managed system *before* it deploys the rule function.
Usually we want the DEV system to be the baseline, so that we follow the transport sequence between the managed systems themselves.
For example:
- Say you have a decision service that will be deployed to executed in ECC DEV, ECC QAS, and ECC PRD.
- We make ECC DEV is the assigned managed system for the decision service.
- DSM gets the metadata references from the ECC DEV system.
- Once the actual metadata of the dictionary objects, function modules, ABAP Classes, etc. used by the decision service are transported from ECC DEV to ECC QAS, the decision service can be deployed to ECC QAS.
- In a similarly way similarly changes are progressed from ECC QAS to ECC PRD.
The way we baseline the metadata in DSM is we assign the rule application which holds the rule function to the managed system. In other words all data objects, rule objects including expressions and rule functions, and even certain exit classes are covered as using the same metadata baseline.
Each rule application can be assigned to only one managed system at any one time (more about reassigning later). Each managed system can be assigned to as many rule applications as needed.
Tip: Note just because a rule application is assigned to a managed system, it doesn't mean that every data object needs to use a metadata reference. Decision services can still use BRFPlus native data types (such as Timepoint, Amount, Text, etc.) freely. Assigning the rule application to a managed system just gives us the option to use metadata references where they make sense.
And although this is a MUCH bigger topic for another blog another time, it does give you a clue as to one of the reasons for putting different rule functions in different rule applications, i.e. all the rule functions in the same rule application need to baseline metadata against the same managed system.
So say you have decided you need to assign the application to managed system. There are two(2) main times that you normally do this:
- When you create a new rules application in DSM
- When you import an existing decision service from the managed system (i.e. during migration to DSM)
Explaining these options in a little more depth...
Option 1: When you create a rules application directly in DSM, you can assign it to a managed system.
You can do this by creating the rules application directly in the Decision Service Manager workbench by selecting the managed system in Edit mode, and then using the New button on the Application tab to create the rules application. The rules application is then automatically assigned to the managed system.
Option 2: When you perform a service import bringing an existing BRFPlus function or application into DSM, as part of migrating from local BRFPlus to DSM, you can assign it to a managed system. By assigning the managed system during the service import, any existing metadata references will be interpreted correctly, i.e. checked against the actual metadata of the managed system and not the actual metadata of the DSM system itself.
The easiest way to do this is in the Decision Service Manager workbench. Select the managed system in Edit mode, go to the Service Import tab, start the Search for Active Services, find the service you want to import, and start the import by pressing the icon button in front of the service.
In the pop-up window where you confirm the service that you are importing from the managed system, simply tick the checkbox "Assign application to managed system".
Although these are two main times we assign the managed system, it doesn't matter too much if you change your mind later. You can reassign the managed system at any time. The easiest way to do to this is in the DSM Workbench by selecting the managed system in Edit mode and using the Add button on the Application tab. This is a great option when you are migrating decision services used as part of a proof of concept from a sandpit managed system to the development managed system. And also when you want your rules developer to create the rules application itself in the BRFPlus workbench of DSM itself, but restrict access to the Decision Service Manager workbench to your DSM administrator, who then assigns the rule application to the appropriate managed system advised by the rules developer.
Reassigning the managed system
While it is possible to reassign the managed system at any time, and we've found this sometimes confuses people new to DSM. Sometimes I have found that people misinterpret this option to think that when you redeploy a rule from DEV to QAS you have to reassign the rule from DEV to QAS. That is incorrect. The assigned managed system remains the baseline for metadata references. The assigned managed system doesn't in any way restrict your choice of target managed system for deployments.
In a typical scenario, DEV is the assigned managed system. As the actual metadata is transported by the usual CTS (Change and Transport system) from DEV to QAS to PRD, all that's needed is for DSM to deploy to each target system. The assigned managed system doesn't need to change.
So how does DSM know it's safe to deploy to QAS and PRD? Well that's the smart bit... prior to deploying it validates whether the actual metadata in the target managed system match the metadata references in DSM.
For instance, if an Element Data Object references a ABAP Dictionary Data Element, the name, type and length need to match. If the actual metadata doesn't match the metadata references the deployment will stop and give appropriate error messages on the log indicating which metadata references don't match.
This avoids decision services being accidentally deployed to the wrong managed system, e.g. avoid a ECC rule being deployed to a SRM system.
And it also avoids decision services being deployed too early (i.e. before the actual metadata itself has been transported) to the right managed system.
Validation points for metadata
In fact there are several validation points where metadata references can be checked. The important pre-requisite is that the managed system must be available and connected to DSM at the point of validation. If the managed system is not available, DSM will give an error indicating this. You won't lose any data or settings in DSM when this happens. At most you won't be able to update the reference until the managed system comes back online.
These are the major milestones where metadata references are checked:
- On Creation of a data object or expression when choosing the option to set up a binding, e.g.to bind a Data Object to a Dictionary object
- This creates a single metadata reference
- On Refresh Binding, by explicitly choosing the Refresh Binding when maintaining a data object
- This checks a single metadata reference
- On update of an expression that uses one or more metadata references, such as DB Lookup or Procedure Call
- For instance if you want to map another parameter in a procedure call, the metadata references will be checked to make sure the metadata references to the signature of the function module or ABAP Class method are up to date. Note that the metadata references are typically only checked when needed, e.g. if all you are doing is changing the mapping of an existing parameter, DSM doesn't need to check the metadata references
- On Deployment Test in the Decision Service Manager workbench
- This is a great feature that lets you check all the metadata references related to a decision service or rule application against any managed system at any time, e.g. when someone tells you they think the actual metadata objects have been transported from DEV to QAS, but they aren't sure...
- On Deployment
- This happens at the start of deployment, so it is a pre-deployment check of all the metadata references related to the decision service (rule function) being deployed. If the check fails, the deployment will be stopped. The rules developer then needs to resolve any issues - e.g. by chasing up the actual metadata transport or refreshing the binding in DSM - before starting a new deployment.
The diagram below explains a typical flow of creation of metadata reference through to deployment using a Decision Service ABC with a metadata reference to a data element ZZCUSTOM. Although this example uses a single metadata reference, a decision service could potentially have many metadata references.
Special considerations for Common Rules
What happens if you want to create common decision services or rules objects that are deployed to multiple target systems? Say you have a set of decision tables with certain rates and factors that you want to share to ECC, CRM, SRM and HANA. How do you handle metadata references then?
There are basically two(2) choices:
- Make sure any metadata references are to actual metadata that exists in all of the target managed systems.
- Only use native BRFPlus data types, do NOT assign to a managed system, and avoid metadata references altogether
Having faced this situation myself on customer sites, my preference is for option 2 - only use native BRFPlus data types in common rules. While option 1 is possible it's all too easy for rule developers to forget and create an unwanted metadata reference that is a pain to fix up afterwards.
What you really don't to have to do is to create a special CTS transport that transports the actual metadata references to all target systems. It will work - if done properly - but it tends to require advanced CTS configuration, landscape and governance, for what is typically a very small set of exceptions and that generally leads to unnecessary confusion for developers and administrators... and delays in getting your decision services deployed.
Viewing metadata references in the BRFPlus workbench (of DSM)
What if, as a rules developer, you don't have access to the Decision Service Manager workbench? How can you see whether a metadata reference exists or is possible?
If you are working in the BRFPlus workbench of DSM, then you can see the Assigned to Managed System icon next to the rule application and against any data object or expression which uses metadata references. The icon looks like this:
You should see the icon in the title area of the relevant rule application, data object or expression. For example:
Once the rule application has been assigned to the managed system, you don't need access to the Decision Service Manager workbench to create metadata references. That's all just normal rules build in the BRFPlus workbench of DSM.
One final caution:
The one thing that can break your metadata references is changing the name of the actual metadata that it refers to. For instance if you have a data element called ZZCUSTOM in your managed system, and you change the name to ZZCUSTOM1 that will break your metadata reference. Which means you will need to not only Refresh Binding but also will often need to remap any references in your rule objects to that field. This is even more of a pain when dealing with structures and tables.
The easiest way to avoid these problems is to encourage developers who are creating the actual metadata to use your corporate naming conventions from the beginning - even in sandpit systems. Then you minimize the number of metadata changes you need to deal with.
So I hope this blog clarifies how Assigned to Managed System and metadata references work in DSM.
Enjoy your metadata and if you have any queries about metadata make sure you post a discussion in the Business Rules Management community!
- SAP Managed Tags:
3 Comments
