Skip to Content
Author's profile photo Former Member

DOE aka NetWeaver Mobile 7.1

NetWeaver Mobile Infrastructure has a new nickname and you will be impressed to know that it is another three letter acronym : DOE. DOE stands for Data Orchestration Engine. Do you hear the bell and whistles? Me neither.

So what is new in this 0.1 release. In fact, the question should be what is not new, because everything has changed! DOE is a complete new engine both Under the hood and in front of the wheel. It is a complete model driven middleware stack to mobilize SAP application. Let me give you a first introduction into the different terminology of the Data Orchestration Engine.

First stop are the basis concepts of what composes DOE. Everything revolves around a model which is called Data Object (DO). Each data object defines a header and child node. One nice particularity is that you can have has many child node as you want : child can have children on their own! You can also define association between DO.

Each DO needs to be linked to a data source to receive data. In DOE this data source is called a backend adapter. You can have as many backend adapter you want for a DO (which can point into different systems) but only one can be activated at a given time. The backend adapter role is to map the fields from the backend BAPI wrapper to the DO model’s. For extra flexibility you do not have to map all fields of the DO nor use all fields of the BAPI, only the key fields are mandatory.

If I stop here for a minute, you will see that those 2 concepts effectively decouples the backend from the model. This opens up a nice array of possibilities: multiple backend system, one client application for both CRM or ERP system depending on the connectivity, etc. The separation of concerns is well established.

Now that you know about the model and how to bring data from the backend system to the middleware system using the backend adapter, how do we bring the data from the middleware system to each user’s client application. This is done using a new concept named Distribution Model. A DM is is a set of simple rules that allow you to match a record in the database to a device. A rule can be as simple as “Send all records from DO ABC to all Devices” to as complicated as “Send records if Field USERID equals device USERID and ORDERTYPE equals ‘PM01′”.

You can define multiple set of rules for a DO. You can also define dependencies between DOs. Those are using the association defined earlier and can be activated and deactivated using rules also.

Finally all those are grouped into what is called a Software Component Version or a SWCV not to be confused with Java/ABAP Software Components. SO the SWCV groups all the DO, the backend adapters, the distribution rule for your client application. Once this SWCV is assigned to your device you will receive the data matching the distribution rules.

I am planning to cover each topic in more details in the coming weeks and month, so if you have one topic you are really interested in, please drop me a mail. I am planning to talk about, push, distribution, performance tricks, modeling tricks, etc.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Julien,
      Thank you very much for your post! I am just starting to take over an MI project 7.1 and I am wondering if there is a common idea between PI Software Component Versions (SLD) and MI Component Versions? Another concern is the value of having such kind of additional encapsulation; did you get it?

      Thanks and Regards,

      Author's profile photo Former Member
      Former Member
      please forget the second question: I finally got it by reading your post again!