DSM Experiences and Practices

[former_member200954]

Those days where you wait hours and hours for a single transport to be imported through the landscape. Not any more, they are long gone with DSM. Now with a click of a button we have all what we need in the desired managed system in real quick time. I’m more than exited to share my experience and love towards DSM and may be a few helpful tips along the way.

I was so driven to write a lot of blogs/share my experience and love towards BRFplus and DSM about an year ago or so; well that lasted for one blog hopefully it will be different this time around since I have few things I would like to share which may be helpful to some :smile:

I work in a enormous project where something or the other is deployed to production every week and a major release every three months. Which may not be the case in some if not most of the projects. When you add BRFplus transport to that it will be long nights for sure. Then when you have around 20-30 functions in a major release, imagine amount it takes to generate them is just cherry on the top for the transports. On the top of this when you have multiple clients in a system and you will defiantly end up in inconsistencies over the two clients to say the least (some developer did not sync his application the second development client, now I cannot test this before I move to quality). Well those days are long gone, With DSM you don’t have to worry about long transports, you don’t have to worry about inconsistency with the rules in multiple clients, you don’t have to worry about generating the functions, all that you need to do is push that sweet little button (‘deploy’) and wallah you have it in any manages systems you desire. Their are lots of blogs/books from carsten.ziegler and jocelyn.dart on DSM which come in more than handy when you are new to DSM or if you have to understand/learn anything related to DSM.

From my experience it is good to have two DSM systems where one is connected to DEV, QAS and PRE-PROD and the other is connected to PROD. This gives an opportunity to do hot fixes for PROD in the second system and them deployed to PROD and use the first system for further releases. Obviously any and all the changes which are done in second system has to be replicated in first system. This is not easy thing, no one wants to do the same thing twice. Their are few ways to go about it, we can achieve this by some standard tools, but most of it depends on the design of the application, the changes which you are making.

1) The hardest way would be to redo all the changes which are made in second system (which is connected to production), for some cases this would be frustrating and time consuming.

2) Their are few expressions such as decision tables where you can export the data of the table and have it imported in any system you like. I can def speak on every one who has worked on BRFplus that how much we love the decision table import and export.

3) XML export and XML import, this would be the one which is the game changer where you can export an expression/entire application and have it imported into the system you would like. you have to be careful here >> when you have use this and if you have already made changes to the objects in first system (development system) which you are importing from second system (production system); all the changes will be over written.

The main thing is that this has to be considered during the design phase of the BRFplus applications so that we can take advantage of the tool (for example 2nd or 3rd option) which would make life a lot easier. I have played around with a lot of XML export and XML import, I will try to share them in coming blogs. Which is defiantly what I would suggest/what I would use. Again it all depends on how the design and what kinda changes you plan to make. Their are a lot of ways on how to go about this having two system or copy of the system after the release for the next one, so on. Always more than happy to learn and understand what we can do to make life simpler.

When you have multiple system when one is connected to DEV and other is connected to PROD and you have to use transports to move the objects between the systems this makes it a bit challenging since you will not have any of the metadata available in the DSM systems. Since when you move the transport to the system it will not add the managed system via transports in the system which you are importing. This would mean the objects which you move will not have access to any of the metadata. To overcome this we have made a practice; Once any application is created in DSM system we move the transport to second system(which is connected to PROD) and assign the managed system, so any objects from that application will always have access to metadata in the second system also, which would allow the transports to go through. Also I have come across few transports which failed to perform the post import steps and activate the objects even when the application is assigned to a manages system; Not to worry, report 'FDT_TRANS_PHASE_EXECUTION' to rescue. By with you can trigger the after import steps. jocelyn.dart has a dedicated blog explaining metadata which would help you understand what metadata is and what it means in DSM environment.

Another thing which comes into picture is timeframes of the applications/objects going to PROD. This is very frustrating and almost impossible to handle when you work on enormous project where multiple people are working on multiple things and which creates decencies on other transports. let me take a simple scenario to go about this, I’m using a table in BRFplus and wanted to send it to production, but I came to know that one of the field in the table is not in production and my change cannot go until the transport with the table goes in to production which is planned to go in two months time and still needs test sign off. What do I do?? Obviously I need that table for my rules and I cannot delete that one filed since it is bound to that table. Do I create a new table with one less field?? again I will be referring to a different table which I cannot do. With DSM I can do this little trick when I assign the PRE-PROD system where it is similar to production and refresh the binding and assign it back to the managed system I like. NO! we cannot do this in BRFplus without DSM and this is just a tip of the iceberg of what we can do with DSM.

Another little advice from my experience is to have as less function calls as you can in the rules. The more function call you have the longer it takes to deploy the function via DSM from my experience. I have seen a lot of applications where they use function calls at will, stating reusability even for a small table operation or a rule which may not change in a million years (not to judge ones design). Avoiding function calls and procedure calls is what I always keep in my mind when I design/build rules. Obviously their comes a debate of reusability, maintenance and performance, lets pick that another day in time, not a topic for today :wink:

To end I would like to point out that we have to rebuild the application exit classes and create currencies/unit of measures(may be their is already a note which I did not come across). You have to copy and past every class and replicate all the currencies/unit of measures when you are migrating to DSM and your CRM/ERP or what ever system it may be has application exit classes and currencies/unit of measures.

Hope this was knowledgeable and will come in handy in your future endeavors and that you will stay with me for the next blogs. Any and all the feedback is much appreciated, which would help me learn new things or correct things which we could handle in a  different and a better way.