DOE is a model driven middleware system. To be called that it sure needs some model somewhere. It comes in the form of Data Objects or DOs for short. Here is an introduction to the concept and to the feature DOE provides surrounding it.
DOE is providing a development environment to create DOs. Fire up transaction SDOE_WB to open the DOE WorkBench. It is based on the SPEED framework which also powers the ABAP workbench so most ABAPers will recognize it.
Once you created the Software Component Version (SWCV) needed to store the Data Objects, you have many choices to create DOs. You can either create them manually, from a merepMeta.xml file or from a BAPI Wrapper. The later option is the recommended for two main reasons: you run into less typing problem and you already know what is available in the backend.
However when you create the DO, you can always go back and change the field names, the type, the keys, the structure etc. Once you created the structure of your DO and assigned the backend fields and backend key fields, you have to activate it. Only if activated the DO can be consumed by a client application.
The structure of a DO is a parent child relationship like it was in previous version of Mobile Infrastructure (MI). The difference is that this time you can have as many children as you want, and as deep as you want. So for example, if you have an order composed of operations which are themselves composed of operation splits, you can actually model it exactly like that.
Within each child, there can be any number of fields. They data types are the basic ABAP ones but you can also add attachment or binary data to a field. Well the binary data is not in the actual field, it is used to specify an handle to the binary data. So in the data object you have attachments out of the box.
For each field, you can also create an association to another DO. For example, I have an order with a reference to a partner, you could create a new association from "Order.partnerid" field to the "Partner" DO. The association will be computed at runtime and on the client you will be able to directly do "myOrder.getPartner()" to retrieve the partner object. No need for querying the order and then querying the partner afterwards.
Data Objects also features versioning. So when you activate a data object and you actually mark it as "shipped" (ie. in production) a versioning mechanism is started. Once the versioning is activated, DOE will track all the changes made to a particular DO and make sure that the previously created client application will only receive the data matching their DO version. This enables smooth rollout of new solution. So if you switch from application ABC 1.0 on your client device to ABC 2.0, you do not have to update all 1000 users at the same time and not sleep for a week. You could decide to rollout to 10 users see how it goes then rollout to 100 users, etc. This is the power of DO versioning.
This versioning does not come for free. Once a DO is released, there is a set of allowed modifications you can do. For example, all deletion activities on a node or a field are not allowed. You can only add stuff to a previously released DO. Somehow it is similar to an interface, you have to think before releasing it.
This covers the basic topics about Data Objects. Next week I will give an introduction on the backend adapters, the data objects little brothers.
