- SAP Managed Tags:
Every developer surely knows this screen:
Version history is an important tool to track changes in products. But how do you migrate these data from one system to another, so that it remains accessible?
Company I currently work for has got two main development systems: an older on Web AS 6.20 basis, and a newer one. Support for our products for the SAP R/3 lasted until end of 2015. Then all the products got installed in the newer system. All but one, for which the R/3-support ends in this year. That's the reason why there was no system upgrade. But as a result our version history is splitted — all changes until end of 2015 can be viewed in the older system, newer changes can be viewed in the newer system. With the end of R/3-support for the last product the system will be shut down so that the version history will not be accessible anymore. Since we don't want to loose this valuable source of information, I'm currently looking for a way to migrate this data.
I don't know any report to migrate the version history. But to be honest, I wasn't looking for it either. I found that the version history is stored in some DB tables, particulary VRSD (somewhat like header information) and VRSX, VRSX2 and VRSX3 (actually there is also VRSX4, but not in the older system). It seems that it would be enough to migrate the entries from these tables. The only issue is, that from 2016 until now further development of our products took place. So we have to merge the history from both systems. But this should not be difficult, since there was no parallel development. So we only have to renumber the entries in new system and insert entries from the older one.
First checks were positive.
But then I realized, that the version history is not all we need. Often to get the background information of some change, one have to double click on the request number, to get more information, like short text, attributes, list of objects, tasks with their owners and last but not least — documentation.
But neither this point should be that difficult — all the information about transport requests and tasks is kept in DB tables, and since systems with different SIDs have different number ranges for transport requests and tasks, we can just migrate theses data the same way as the version history itself.
The tables which are relevant for transports are: E070 (header data), E070A (attributes), E070C (source / target client) — I'm not really sure that we need these data, E071 (list of objects) and E07T (short texts) — as a matter of fact, this table is language dependend, but I think SAP doesn't support short texts in different languages for transport requests / tasks, at least not in our newer system, which is actually not that new anymore (NW 7.0). There are many more E* tables, but I don't know whether these data is relevant. On the other hand, it wouldn't bother me, to migrate these data too.
Only the documentation for transport requests / tasks is kept in the central tables with SAPscript texts. But the content of these tables has to be migrated also for the repository objects, so nothing new.
All (?) documentation is kept as SAPscript in DB tables, particulary DOKHL and DOKTL. I'm curious about the second one, in which the older versions of documentation is also stored. But I did not find the possibility to view and compare these older versions.
One way or another — we don't want to loose these data either, so we will migrate it. And I hope these two tables are the only relevant. In this context I came across some header fields for each SAPscript text:
These are stored in DB table STXH. This can be important for documentation of transport requests and tasks, but not repository objects, since their documentation will be transported with the request. The above screen shot was taken in the newer system — in older these three fields are present in the DB table, but I didn't find the possibility to display them among with all the other header informations.
There is a possibility to store comments to the translation of every object:
These are stored in DB table LXE_REMRKS. But since we don't (yet!) use the system tools for translation but rather a third party product, we have no comments. If we were using the standard translation tools, we would have to migrate also the data for the translation projects, tasks or whatever these are called.
That's pretty much all about my plan to migrate these data. I'm now preparing a PoC, but since there is too much data to migrate, and there are more relevant tasks to accomplish, the validation of the concept will be carried out for a small representation of our repository objects only.
The final migration will take place in February, assumed the PoC finishes positive.
And here's my question to the community: did you ever have such a requirement? If yes, how did you realize it? Can you think of any other aspects, which I didn't take into consideration until now? I'll be more than glad to hear from you in the comments and hope you enjoyed reading this short blog.
Version history is an important tool to track changes in products. But how do you migrate these data from one system to another, so that it remains accessible?
Background
Company I currently work for has got two main development systems: an older on Web AS 6.20 basis, and a newer one. Support for our products for the SAP R/3 lasted until end of 2015. Then all the products got installed in the newer system. All but one, for which the R/3-support ends in this year. That's the reason why there was no system upgrade. But as a result our version history is splitted — all changes until end of 2015 can be viewed in the older system, newer changes can be viewed in the newer system. With the end of R/3-support for the last product the system will be shut down so that the version history will not be accessible anymore. Since we don't want to loose this valuable source of information, I'm currently looking for a way to migrate this data.
Plan
I don't know any report to migrate the version history. But to be honest, I wasn't looking for it either. I found that the version history is stored in some DB tables, particulary VRSD (somewhat like header information) and VRSX, VRSX2 and VRSX3 (actually there is also VRSX4, but not in the older system). It seems that it would be enough to migrate the entries from these tables. The only issue is, that from 2016 until now further development of our products took place. So we have to merge the history from both systems. But this should not be difficult, since there was no parallel development. So we only have to renumber the entries in new system and insert entries from the older one.
First checks were positive.
Dependent information
Transport requests and tasks
But then I realized, that the version history is not all we need. Often to get the background information of some change, one have to double click on the request number, to get more information, like short text, attributes, list of objects, tasks with their owners and last but not least — documentation.
But neither this point should be that difficult — all the information about transport requests and tasks is kept in DB tables, and since systems with different SIDs have different number ranges for transport requests and tasks, we can just migrate theses data the same way as the version history itself.
The tables which are relevant for transports are: E070 (header data), E070A (attributes), E070C (source / target client) — I'm not really sure that we need these data, E071 (list of objects) and E07T (short texts) — as a matter of fact, this table is language dependend, but I think SAP doesn't support short texts in different languages for transport requests / tasks, at least not in our newer system, which is actually not that new anymore (NW 7.0). There are many more E* tables, but I don't know whether these data is relevant. On the other hand, it wouldn't bother me, to migrate these data too.
Only the documentation for transport requests / tasks is kept in the central tables with SAPscript texts. But the content of these tables has to be migrated also for the repository objects, so nothing new.
Documentation
All (?) documentation is kept as SAPscript in DB tables, particulary DOKHL and DOKTL. I'm curious about the second one, in which the older versions of documentation is also stored. But I did not find the possibility to view and compare these older versions.
One way or another — we don't want to loose these data either, so we will migrate it. And I hope these two tables are the only relevant. In this context I came across some header fields for each SAPscript text:
These are stored in DB table STXH. This can be important for documentation of transport requests and tasks, but not repository objects, since their documentation will be transported with the request. The above screen shot was taken in the newer system — in older these three fields are present in the DB table, but I didn't find the possibility to display them among with all the other header informations.
Translations
There is a possibility to store comments to the translation of every object:
These are stored in DB table LXE_REMRKS. But since we don't (yet!) use the system tools for translation but rather a third party product, we have no comments. If we were using the standard translation tools, we would have to migrate also the data for the translation projects, tasks or whatever these are called.
Summary
That's pretty much all about my plan to migrate these data. I'm now preparing a PoC, but since there is too much data to migrate, and there are more relevant tasks to accomplish, the validation of the concept will be carried out for a small representation of our repository objects only.
The final migration will take place in February, assumed the PoC finishes positive.
And here's my question to the community: did you ever have such a requirement? If yes, how did you realize it? Can you think of any other aspects, which I didn't take into consideration until now? I'll be more than glad to hear from you in the comments and hope you enjoyed reading this short blog.
9 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
