Skip to Content

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Bernhard Knoblauch
    Commenting on the following section of the blog:
    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.

    I once heard that our indian colleagues rather think in examples than in abtract rules. Not sure if you are *the* counter-example to that saying or if you simply write for us europeans and americans as you’ve heard we like abstract rules ;-).

    Nevertheless I want to make sure I understood you well by providing an example. You might confirm the example describes the conditional dependency well or shed some more light in my darkness.

    Assume we define a distribution rule for a sales application. Assume each customer has an attribute “Area” and each device also has some device attribute “Area”. We define a distribution rule “r_Cust_Area” that distributes all customers of a certain “Area” to all devices with the same value in its device attribute “Area”. We also define a dependency “d_Cust_SalOrd” that all sales orders for a customer follow the customer. Fine so far.

    We also define a dependency “d_SalOrd_Cust” that all customeres referenced in a partner function of a sales orders follow the sales order.

    Assume wha have Customer A distributed to device A (because of rule “r_Cust_Area”) and a sales order 4711 for Customer A referencing customer A and B, which is also distributed to device A because of dependency “d_Cust_SalOrd”.

    For sure, we want to have customer B distriuted to the device A (Dependency “d_SalOrd_Cust”). If we don’t want to distribute the sales orders of cutomer B to the device (again “d_SalOrd_Cust” unless it is distributed directly via “Area” to the device “conditional dependency” seems to be the concept of choice, right?

    What do we have to define?

    Kind regards, Bernhard Knoblauch

    (0) 
    1. Pradeep Kumar Warrier Post author
      As mentioned abstract approach is only to start with, subsequently will take on examples to elaborate on them ;). Hope to keep different kinds of readers satisfied .

      With only basic dependency modeling, sequence of mapping instances to devices in your scenario will be as following:
      a- First Customer instances mapped to device through distribution rule
      b- Next Sales Order instances mapped because of dependency with customer
      c- Next customer instances mapped to devices because of dependency with sales order
      d- Next Sales Order instances mapped because of dependency with customer
      And so on the cycle will continue as long as distinct instances get mapped to device.

      Now in your scenario, involving cycle as well, you want to avoid step-d and subsequent steps by imposing some kind of filtering. The different filtering options in dependency modeling are:
      a-     using static filters
      b-     defining rules ,same as distribution rule, on top of dependency
      c-     defining conditional exclusion

      As each of the above options is involved I will be covering them in the subsequent articles as part of this blog series. Based on scenario conditional exclusion can help though.

      (0) 

Leave a Reply