Data Orchestration Engine, Netweaver Mobile, is a model driven message oriented middleware having data distribution as one of its strength. As a model driven platform it asks the developers to define their application's data model. And on top of that developers can model patterns to distribute the contents of the data model. The data distribution capability is one of the core capabilities of Data Orchestration Engine.
However it could be also one of the trickiest and susceptible to misuse. So here by starting a series on various aspect of distribution modeling. To start with will cover very high level conceptual stuff and in later articles will take some of the scenarios and how to model for them in DOE.
To begin with important thing is to identify the role of functionality. In short the idea behind distribution is to ensure that the right data is identified and mapped for right receiver based on the modeled distribution requirements. And hence the modeling of right distribution model becomes important.
At a basic level, the questions that one needs to ask when modeling distribution model are:
- What to distribute?
- Whom to distribute?
- On what basis to distribute?
- When to distribute?
The different steps in the distribution model wizard help in answering the above question.
What to distribute: This is the simplest question when modeling DM. Any data object that is application relevant is candidate for distribution. However, when modeling DM, the question needs to be looked bit deeper as what can exist on its own in the client application or what is it that governs the need of other data objects. Based on the answer to above, the root data object of the distribution model is identified as relevant for distribution. It's only on the root data object that one is allowed to define distribution rule (will be explained later). Based on the individual modeler choice the root data object can represent either master data or transaction data. In any business relevant application, there exist relations among the data. And these references must also need to be distributed. All such required referred or associated data objects can be distributed in the same distribution model by defining them as follower of the root data object or other leading data object.
Whom to distribute: Like data object, this again is a simple question on the face value. Distribute to devices or client. It's possible that in the application/system landscape there are hundreds of devices. Will all of them be relevant to get the data? Possibly not. In such cases, the set of potential receiver set of the data is limited by identifying their binding criteria for the data. In the simplest case, all the devices that are making use of application on the involved data objects are potential receivers. So in such case just specifying device binding as all may be sufficient. However keep in mind that all such receivers should have the DM-SWCV assigned. (The assignment of DM-SWCV signals the receivers interest in getting the application data based on distribution pattern defined in that DM-SWCV.) Another possibility is the reduced subset of available devices. In this case, binding option allows binding based on the attributes of the devices. Another option is to identify and bind the potential receivers manually. For this option, binding as none is useful.
On what basis to distribute: The underlying action when distributing relevant data to receivers is to map or form the data-device pair. As such the basis to distribute can be based on the properties of the data, properties of device, or by other decision criteria.
The simplest way is to distribute all the data to all the bound devices. Bulk rule provides this approach.
Next could be to distribute only those data whose value meets some criteria to bound devices. These criteria value can be statically defined or dynamically identified. In the case of statically defined one can give the constant values while modeling the rules. Only the instances that match these values will be distributed to devices.
In the dynamic identification, the source can be either/or backend or device. When backend is expected to identify these criteria values then rule modeling is expected to make use of subscription generator data object. In case of device, mapping the criteria to device's attribute will mark the dynamic identification based on device's relevant properties. When using subscription generator, additional things to be identified is which criteria value is relevant to which device devices. And hence a mapping to device attribute there is required with the field of the subscription generator data object.
The above options of criteria identify the instances of the root data object only.
The associated data object needs to be made as follower of some root or other leading data object. And for that dependency can be modeled. The plain dependency will allow all data of associated object to be distributed when the corresponding data of root or leading is distributed.
In the case when not all associated data needs be distributed:
One can either use filter value (on the link node) that can limit the possible associated data, or
One can define rule on top of dependency. The second option will apply rule criteria after the associated data is found using the plain dependency.
An advanced option of distributing the associated data object is based on dependency which caused its leading data object instances to be distributed. This option is modeled as conditional dependency. According to this, only if the leading data object is being distributed because of some dependency that the corresponding following data object needs to be distributed.
When to distribute: The evaluation based on the model depends on the event related to properties being used in model. For device created, it is first checked if that has interest in distribution pattern by checking the assigned DM-SWCV. And if so, the rules part of that distribution model are evaluated to identify data for that device. In case, the device's attributes are used to define the binding or criteria values, then any change in these attribute requires the evaluation to take place. In case, the rule is having any criteria making use of date, then evaluation happens daily on date change.
Apart from these any message from client or backend for the relevant data objects will cause these evaluations to take place.
In the subsequent articles will dive into modeling with specific scenarios as example.
