Skip to Content
Author's profile photo Former Member

Understanding the Transports of DOE Objects

In my last Applicatoin Versioning with DOE (NetWaaver Mobile 7.10)which is now a year plus old, I did mention what I intend to write next. I had promised my next blog to be “How to setup a Productive Landscape” … I should remove “How to” as it might classify itself to be categorized under “How to Guides”… so let’s name it as “Setting up Objects in Production Server in NetWeaver Mobile 7.10”.

But before I write about it, I would like to take a step back and try to unfold the mystery behind the transports of Data Orchestration Engine Modeling Objects and their behavior once imported in the Target System which can be either Quality or Production.

Before you read any further I would request you to go through my First blog mentioned in the beginning as it involves concepts which are detailed in the earlier blog.

As you must be aware the Data Orchestration Engine provides a Modeling Tool called Workbench which can be accessed via transaction SDOE_WB. The workbench is a central place for modeling the Software Component which shall have Data Objects, Backend Adapters, and Distribution Models being modeled under it. Apart from these it also allows defining customizing Attributes for Receiver Meta Model called Mobile shipped under the Software Component named “SAP BASIS 7.10”.

All these objects defined and modeled are saved under transport request(s). The workbench only helps you in picking the transport request which you would like to use to save the object but it doesn’t enforce any principles on how to save the objects nor does any kind of checks if the objects are put in disparate transport request which can lead to sequencing problems based on the order in which these objects are transported.

In short DOE only uses the BASIS transport mechanism to save the objects; it doesn’t govern the semantics of BASIS Transports to allow objects to be put in any open request. The only enforcement from BASIS if the object is locked in one request it shall pop-up the same request for saving the next change on the object.

Now if you open any transport request which contains the DOE Modeled objects it shall look like the following example –

TR XYZ000012



TR XYZ000010





The above 2 figures describe the transport which actually capture 3 objects; the Data Object and the Backend Adapter in request XYZ000012 where ‘XYZ’ is the system name – this is just a dummy name for the example purpose, it doesn’t represent an actual system. (Any resemblance to actual system is purely coincidental)

Let’s dissect the request if you see request 000012 – the DO and the ADAPTER are attached with a delete ICON i.e. they are deleted from the System.  I’m using this just as an example to highlight the various possibilites.

The column object name shall contain the object directory entry for the object which can be found out by double clicking the object in the Workbench and then go to Menu -> Go To -> Object Directory Entry.

The second request just captures the DM as it was transported from the system.

Now they are 2 aspects of the entire transport concept –

  1. What’s getting transported and how?
  2. What’s the behavior in the target system?

 Answer to Question 1 –

If you re-look the objects are put in 2 different requests; now it’s at the modeler discretion how he wishes to capture the object in the transport request. So there is no enforcement which says that the objects need to be clubbed together.

This might lead to problems especially if we understand the reply to Question 2.

Answer to Question 2 –

Based on the object definition –

–          For new Objects the generation shall be triggered after the objects are persisted in the Target System, the generation shall run in DOE_MASS_ACTGEN queue which shall run in client 000 only. This generation shall create and activate the runtime which includes required DDIC, Classes and Function Modules.

–          For existing objects who have received a newer version – the manipulations shall be done at meta data level to capture the newer version as the active version, the earlier versions shall continue to work based on the multi-version support described to you in my earlierApplicatoin Versioning with DOE (NetWaaver Mobile 7.10).

–          For deleted objects the meta shall be maintained to mark the versions as deleted which shall remove them from being displayed in the workbench, moreover all the runtime data shall be removed as part of de-activation in case of Distribution models. For Objects it’s assuming that the Distribution Models are already removed hence it just removes the Objects and its generated DDIC from the system.


As DOE doesn’t govern how the transports are Released, its possible that you transport the objects in random fashion which will result in After Import Errors. The sequence of the transports coming in has led to Object missing errors, this also happens for normal BASIS object.

For e.g. Lets create a Data Element name XYZ_ELEMENT which uses a Domain XYZ_DOMAIN and lets save the DOMAIN and the ELEMENT in 2 separate transports and release transports for Element first.

The import log for the element will show error as it won’t be able to activate the object as the domain used in the definition is missing from the system.

A transport of Domain shall solve the problem.

Similar behavior is observed for DOE objects if you transport DM for which either the DO is not yet transported or is deleted as shown in the figure above where the DM and DO are captured in separate transport request. The after import logs shall say the same problem which is DO used in the DM is not available in the System.

So it’s a valid error and the fix is to transport the DO or to send the delete of the DM. Ideally we should send the delete of the DM before we delete the DO so that we can maintain the integrity of the system doesn’t end up encountering Edge Problems i.e. undetected behaviors which might occur because of the other environments like Fixes or SP’s currently in use.


If you are productively using a Model then a delete on any of the Modeled objects shall lead to removal of all the data from the device for the Object / Distribution Pattern so I would suggest think before you plan to delete objects which are being productively used.

There is a flag “Released for Shipment” at every SWCV; the flag should be checked once you have objects being used productively; details are explained in my earlier blog.


The next blog I shall share some do’s and dont’s for Setting up Models in the Production Server of DOE.



Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.