Before I begin explaining the topic, we need to answer a simple question -
Question - Who is this article’s target audience? Hint: Beginners, Intermediate or Advance Users
My Answer: ALL
Responses -
Beginner User Response – “I’ve not even got hang of creating my first Application and you want me to understand Application Versioning” that sounds crazy.
Intermediate User Response – “I’ve just started to appreciate the workings of DOE and you are again making it complex for me” that’s not required right now.
Advanced User Response –“I knew it, this one is for me to read, but I don’t understand what are these Beginners and Intermediate Users doing here reading this article”, It’s for me alone I’ve come a long way to be qualified at reading it.
My Response – Well versioning is a concept which is independent of the level of expertise in the software used to build the Application. It’s an art of pragmatically designing your application (schema + logic) keeping openness for future changes; hence it’s applicable to all and more so to those at the beginning of the application development.
Lets step back a moment and say you have an application Service Order App 1.0 on your mobile device which synchronizes data with DOE for a Data Model.
Now one year after going live with people in the field using their mobile device to capture the service orders completions, you identify that your application needs to be altered, i.e. you need to add some more content to the model which is currently missing for the Mobile User.
So what do you do?
Well If I were you, I’ll just go to DOE and change my Model and re-build my application with this new Model and call it Service Order App 2.0
But there is much more to this then just what I wrote above, just to name a few –
- Every new version of application requires it to be deployed on the Mobile Device
- Every new version requires the new data to be present with the User
- Every new Version requires that users using the earlier version of the same Model continue to remain happy ( i.e. continue to Enjoy their Right to Sync )
- Every new Version requires deltas to be sent only for the Objects affected due to the new development/ enhancements and should not involve a data re-load for the entire application model.
With DOE all these concerns are addressed via its capability to allow multiple versions of an application to work simultaneously i.e. Device Beginner is using App 1.0 where Device Advance is using App 2.0 and both can Synchronize their data i.e. Service Orders Completions to the DOE server within the same era of Existence.
I’ll now try to put these words into an Example -
If I say my Service Order Data Object looks something like this –
It has 2 Nodes – Header & Items
Items node is a child to Header Node and contains Details about the Repairs to be done.
Let say header has following fields – (the ones in bold are key fields)
Job No, Service Order Number, Customer Name; Technician Name and Customer Phone Number, Date, Time.
Let’s say ITEMS node contains fields like – (the ones in bold are key fields)
Item No, Job Status, Repair Part, Description, Problem, Part ID, Part Qty, Repair Details.
(The definition of the schema above is not a real-world scenario; you can map the same to your area of business)
Business Scenario 1 –
When the requirements were rolled out to the application developer -
- It was told that before visiting the Customer, the technician will make a call to the Customer and fix an appointment
- Secondly the customer recited the need to optimize the bandwidth usage during Sync i.e. send only what’s required no more no less.
So the developer wrote Version 1.0 of Service Order Application on top of the above described Model and Business Scenario - The final application looks the following –
It has 2 screens on the Mobile Device –
- First Screen - depicting the contents of the Header node i.e. Jobs for the Technician to start with along with the Telephone Number of the Customer to fix an appointment.
- Second Screen - which displays the repair details for each job, and a task completion drop down to confirm the repairs done.
Do you see anything wrong with the Application? I believe not, the application does what’s required i.e. show the technician the Jobs he is suppose to finish and for each job show the service/repair details.
After rolling out this application in the field, a feedback was taken, which came out contrary to the assumptions.
The application worked very well for all the Veterans, but it didn’t get a similar response from New Technicians (new joiners)
A further probe revealed the real cause; the application had Customer Telephone number but didn’t have the Customer Address. Now for Veterans they either new the Customers addresses by heart because of their earlier engagements, even otherwise they had good know-how of the area and could understand the address once on call with the Customer.
For the new joiners the situation was way different. First, they didn’t know the area well and secondly every customer was a new Customer.
Business Scenario 2 So the IT team came back and requested a change to the application with a new filed depicting the Customer Address which also had a link to its Map.
So, Model change was initiated in DOE a field Customer Address was added to the Header Node of the Service Order Data Object, and was then imported in the Application and the UI was enhanced and released as Application Version 2.0. (This also rendered the address as a map)
The newer version was deployed on DOE. Now DOE has 2 version of the Service Order Application.
A recommended way would be to do a phased upgrade to the new application i.e. rollout the newer version of the application first to the new Joiners and get a feedback of the working before rolling it out to everyone in the field.
This implies the Veterans would be working with APP 1.0 and new Joiners would be working with App 2.0 at the same time. Slowly we would also move Veterans to App 2.0 as they don’t mind having the address with them as it saves the time and money spent over phone talking with the Customer getting to know his address.
This brings to the crucial notion as to what does the capability to have multiple version of an application really means? A simple answer would be its meant to aid the application developer enhance applications based on the evolving requirements without disrupting the existing application landscape. This it does so by allowing additive changes (which additions to the current schema definition) to the Model like –
- Add NODE
- Add Field(s) etc
But it doesn’t support –
Delete NODE
Delete field(s)
- Remove a field to be a Key Field etc.
Why the removal of nodes and fields is not supported??
- If you delete a node or field you can’t make the APP 1.0 work anymore because it still continues to work with that deleted node or field.
- Secondly it might also be used as a key of the node, in which case deletion of the field might result in data integrity loss as the records would not be identifiable uniquely anymore.
Having said that this raises another Question -
Does it impliy that any DO created in DOE Workbench can only have Nodes and Fields added and we can’t delete nodes and fields? (What If I’m still in process of developing my APP 1.0 and I want to remove some fields because Customer has changed his requirements).
Well by default DOE workbench allows you to do non-additive changes to the model. In oreder to restrict the Modeler from doing any further non-additive changes to the model DOE has a flag called “Release for Shipment” at the SWCV level in the Workbench.
So once you are sure your application first version has gone LIVE with the Mobile Users. You can check this flag and henceforth the workbench will ensure that within this SWCV all the changes would be additive and no removal of released definitions of models would be allowed.
Till the flag is not marked you can continue to remove fields or nodes and continue to non-additive changes and keep changing your model for version 1.0.
SO WITH DOE's MULTI-VERSION CAPABILITIES AND A PRAGMATIC DESIGN OF YOUR MODELS WITH THE ABOVE QUOTED NOTIONS IN MIND, YOU CAN KEEP BUILDING AND DEPLOYING NEWER AND ADVANCED VERSIONS OF YOUR MOBILE APPLICATIONS WHICH CAN RUN SIMULATANESOULY WITH THE OLDER RELEASES.
In case you would like to know how to have these multiple versions of applications available in DOE, A recommended read from my side would be on Application Upgrade Process with NetWeaver Mobile 7.10
I plan to write next on “How to Ship the Modeled content to Productive Servers after doing dev & tests” (setting up of production landscape and transports of the next version of the application model). I strongly believe this also as an area where a good initial design/conventions can make you reap great benifits going forward with future releases of applications.
