Managing DOE models on a Production Server of NetWeaver Mobile 7.10

[Former Member]

So I’m back to write what I said I would write about in my Applicatoin Versioning with DOE (NetWaaver Mobile 7.10). I had to digress to explain a transports before i can write this one and hence came my Understanding  the Transports of DOE Objects in between.

I believe the topic of managing DOE models is of utmost importance on a Production Server. Any unnecessary changes which are created because of import of changes from DEV/TEST servers or a direct change on the production server itself shall cause a huge impact on the productive data flowing to all the productive devices.

Often I’ve experienced, people mistaking the DOE models as just simple schemas which form the basis for the Application Development, but they underestimate the fact that these schemas not only form the building blocks for the Mobile Application Development, but they are also responsible for defining the structures for Staging Data and also for Distributing Data, hence any change shall effect all the three aspects namely –

a)      Application

b)      Staging

c)       Distribution

Application and Staging go hand in hand; if you change the schema, the app needs a re-build to adapt to the changes. DOE supports multi-versioning as described in my earlier Applicatoin Versioning with DOE (NetWaaver Mobile 7.10), which can make the application remain intact where in we can enhance the schema on the DOE, thus providing the only exception to my above statement. But any such change of no application change actually implies that Staging change was done for Distribution Enhancement i.e. the modeler might add an additional NODE/FIELD to define a rule/dependency which modifies the Data Flow. Thus highlighting the Staging and Distribution as closely related to changes.

So which ever scenario is applicable it’s for sure that such a change shouldn’t be done in an unrestricted fashion. So I’ve highlighted DO’s and DON’Ts to keep in mind while importing/doing model changes on a productive server.

DO’s & DON’Ts [All DO's below highlight what one should not DO (DON’T) and vice-versa]

1. Once you have gone productive with a GIVEN model which uses Software Component Version(s), you should always set the flag “Released for Shipment” at the SWCV level. This enforces the DOE Workbench to enforce only additive changes to be allowed in the model henceforth. [This is very important as it ensure that no-one accidentally model a non-additive change to the existing schema].

2. Transport only the final version to the Production Server. 

For example let’s say you have a Data Object in Dev System version XYZ0001 and you transported it to Test Server. After running some test you figure out it requires some change hence you go back to the Development System and do the alterations and the version is changed to XYZ0002. You continue this process for 3 more iteration before you finalized on the optimal model with the current active version number XYZ0005.

Now all these changes are also captured as Transport Requests which were transported from DEV-TEST. But it should not be connected to PROD in the same way, so a good practice is to send only the active and finalized version to production which in the current case would be XZY0005.

3. No manual changes to the models in Production Server.

You should avoid doing any model changes manually as for one it will not be captured in the Development environment, secondly if you do a change in the Development System a transport later will result in conflict which will again require manual intervention. For e.g. in the same example of point 2. Let’s say you do a change in the Production it will be saved as ABC0006. Now a parallel change in dev will result in the version to become XYZ0006. Now a transport from DEV shall result in conflict as there will be 2 active versions XYZ0006 and ABC0006 and you need to manually resolve conflict using the merge tool which is not at all required, desired or even intended.

4. Delete should be avoided on a production server.

One reason of enforcing this is via the Flag “Released for Shipment”. But in case you don’t want to follow my advice and will like to do delete of objects / nodes/ associations etc. it will require the data which was going because of that object to be deleted. Hence it makes sense to not mix deletes with fresh objects or re-created objects with the same name.  I know it’s confusing I’ve clubbed in too many words paradigm in a single sentence. So let me try explaining this with an example.

Let’s say the object ‘A’ with the version XYZ0005. Now you have a Distribution Model on the object by name ‘DM_PRODUCTIVE’. Now let’s say in this Distribution Model has a dependency modeled to another object ‘B’ which implies ‘B’ follows ‘A’ i.e. whichever instance of ‘B’ is linked to the instances of ‘A’ will flow to all the devices where A’s instance is going. For ‘A’ to get distributed you have modeled a rule on ‘A’.

Now after evaluating the solution with the field you identify that the model is not working in the optimal fashion and can be optimized by defining a reverse association i.e. define a Distribution Model on object ‘B’ with an association defined between ‘B’ and ‘A’ and also a rule on ‘B’ to distribute ‘B’.

Now for the model in ‘A’ to stop working you don’t need to delete the DM defined on ‘A’ you can just deactivate the rule on ‘A’ in ‘DM_PRODUCTIVE’ which will result in removal of data going because of the DM and activation of rule on DM on ‘B’ shall send the data to the devices with the new logic.

I know you can still decide otherwise and give in to the dev paradigm to delete and unused object. So if you still decide to delete the DM on ‘A’ and you wish to still keep a new rule on ‘A’ for distributing any data which were not getting distributed because of the new DM on ‘B’.

So you can delete the earlier DM on ‘A’ i.e. DM_PRODUCTIVE and then create a new DM with the same name.

But while transporting to production we should first transport the delete of objects where in DM deletion should be transported before DO deletion.

Once the import is green and there is not active entry in the DOE_MASS_ACTGEN queue of transaction SMQ2 in client 000, you should start the second transport which carries with the delete of the adapter and then DO.

And finally the transport for the new DO adapter and DM can all go in single request.

You might argue - "As a tool the system should work irrespective of the combination you choose to transport" and you are right. So i won't debate much on that as my Goal is to help you in avoiding the mistake which by doing some pragmatic modeling keeping the current needs and future wants in mind.

So if I were you I would save my time and follow the tips mentioned and avoid the mistake of getting objects shipped in uncontrolled fashion with random changes.  whom. This also gaurantees that you have a control on the release and can look back and isolate problems which caused troubles during dev/test and keep production totally clean and minimal.

PS: There might be some more to the given list but right now these 4 are the ones which I feel are common pitfalls which can be avoided if due diligence is observed while transporting/modifying the objects.