Introduction
In this blog I will discuss on how to transform existing developments to BOPF in a non-disruptive way. We are an SAP customer with a long history of custom development. There are more than 15 years of development without BO frameworks. The green field approach will not work for us and a big bang transition for our 8 million lines of code is not a way our management will let us go (I don't want to go this either). So I was looking for a smart way to move towards BOPF without disrupting productive environment. The transition is split up into the following phases:
- BO Modelling
- Dependency Analysis
- BO Implementation – Part 1
- BO Implementation – Part 2
- Finalization
These phases will be described in the following chapters in detail. To get to know why we want to move towards BOPF you can read this in my previous blog.
Starting Point
Let’s start with a short description of what we are facing before starting the transition. The "business objects" consist of some tables, function modules, classes, module pools, etc. In addition there are a plenty of reports that access these tables. Some of them are for analytical purposes, some have been used for migration and I’m sure there are also some reports that have fixed data to solve issues caused by application faults. Many of them will have a direct read access to the BOs database tables and a few of them will also have write access to these database tables. In addition there will be development objects of BOs that will also have direct access to other BOs database tables. So we will be pretty far away from a perfect world, but that’s reality. Nevertheless we are able to start from here to move towards BOPF. What you have to do here is to choose the BO you want to start with. I would recommend to choose a BO that is not depending from other BOs. In general a master data object is a good choice.
BO modelling
First step is to get a clear understanding of the new BO structure. In here you should start from scratch. You can have your old BOs structure in mind but be open minded for changes to the BOs structure. Now it’s the time for change. Later on it will be more effort to make changes. You can use the rapid prototyping features of BOPF. Create the BO and use the test environment to check if you feel comfortable with the new BO structure and that all information has it’s place. There’s no need to model actions, validations and determinations at this time. We will do this later on.
Don’t worry that the database tables created by BOPF will look different from your existing tables. Check if the data from your existing tables can be transformed to the new BO’s structure. I’m sure that this transformation will be possible even if you have done changes to the BO’s structure. Both structures serve your business requirements so they won’t be that different.
As a result of this phase you have a clear understanding of how your new BO will look like. The target is set and we are ready to go ahead to the next phase. In addition we have a new BO with the basic functions without coding.
Dependency analysis
In this step we will determine what has to be done and we will also define the order of actions. We will use the where-used-list of our database tables to determine which development objects are accessing the BO’s database tables. Create an excel sheet with all references. Check for each development object if it is required any more. The older your system is the more likely you will have old coding like reports for data correction that will not be used any more. Mark them as obsolete and remove these object from your development system. If the development object is still required check if the database access is read-only or if there is also write access to the database table. Objects with write access will be covered in part 1 of BO implementation and objects that only have read access will be handled in part 2 of BO implementation. The objects within part 2 of BO implementation can be ordered by usage. It is a good choice to change frequently used objects first. Another approach can be to group them by functionality to reduce test efforts.
Now is a good time to update our planning and effort estimation. We know how many objects we will have to adjust and which phase will cover how many objects. In addition we have an idea of the complexity of the transformation. Now we are well prepared to start core implementation in the next phase.
BO Implementation – Part 1
During BO modelling in the first phase we have already created a new BO and BOPF has created database tables for the new BO structure. The first step will be to connect the new and the old BO structure. There are two options to choose from.
If there are just a few write accesses you may prefer using a sidecar approach. This means that you implement an action in the BO that transforms your new BO’s data to the old structure when saving your new BO. Until end of the transition you will always synchronize both worlds having the new BO as a source of truth. When using the sidecar approach you must have to make sure that after go live of the new BO there will be no write accesses to the old database tables any more. Otherwise you will end up in inconsistencies.
If your transition time will be long you can also use a data access class (DAC) to do the transformation between old and new world. The DAC will replace the standard functionality to store data in database. You will be able to use your old database tables without any limitations. The transformation within the DAC will care for consistent data. Because this is very essential for the success of the transition I recommend using unit testing to ensure that the transformation works. In a previous blog I described how to create those data access classes. Choose to use persistent GUIDs instead of transient GUIDs in this case.
After connecting both worlds we can start adjusting the write accesses to our old database tables. Replace the direct database accesses by using the BOPF API to access the BO. Before we can do so define an alternative key for your BO. Because we already have a BO with basic functionality like CRUDQ replacing the direct database access is done easily. Reuse the transformation methods of the DAC to map to the new BO’s structure. In addition you should also add determinations, actions and validations to your BO and remove this functionality from the development object that now calls the BOPF API. This can be done step by step. If you have finished transition for a development object you will go to the next development object and do the same. Within each of the following development object you will benefit from already existing validations, actions and determinations.
Please note that at any time during development you can test and go live with your implementation if you have chosen the data access class.
To let your business users benefit from the new well formed BO you should also replace the existing application to maintain the BO by a modern UI created with FPM or SAPUI5 within this step. Make sure that all required validations and determinations are implemented within the BO before going live with the new UI.
At the end of this phase we have a BO synchronizing both data models and being fully functional for maintaining the BO. In addition we have a new UI to maintain the BO. Make sure that there is no reference left having write access to the old database tables.
BO Implementation – Part 2
In this phase we are replacing the direct read access to the old database tables. If your query methods of the BO are not sufficient you may extend them in this phase. There should be no need to create or update actions, validations and determinations in your BO because they will be created in Part 1 of the BO implementation. In most cases this phase will be time consuming because of the number of development objects to be adjusted.
Now we have replaced all direct accesses to the old database tables by calling the BOPF API. It’s time to finalize our transition.
Finalization
In our final step we will remove the old database tables from our system. If we have chosen the sidecar approach we will have to remove the action from our BO that synchronizes the old tables before deleting the old database tables.
If we have chosen the way implementing a data access class we will have to migrate the data from the old database tables to the new database tables. You should reuse the transformation methods of your data access class again to ensure a consistent migration. If your migration is completed just remove the data access class from your BO and use the generated database tables.
We have completed our transition now and can repeat the transition for the surrounding BO’s. You now can use cross BO links to join these business objects
Summary
As you can see there’s a way to move to BOPF in a non-disruptive way. Using data access classes there is no need for a big bang and you can start from any point because there are no requirements for your current state of developments and no limitations with regard to maintaining your productive environment.
During implementation of the new BO in part 1 and 2 you may think that refactoring the surrounding developments objects may be a good idea. It is up to you to decide if you want to refactor now or after the transition. Be aware of the timeline and your budget for the transition of the BO when deciding to refactor.
