Dear Reader,
I hope you have read the earlier part of this series where I introduced different ways in which you can perform the content repository migration. You can read about the same here
As mentioned I would try to explain the difference in Report RSIRPIRL, Z_DOC_COPY, Z_MIGRATE_ARCHIVELINK.
You may ask a question, Why did I select these three reports only and not adding about other reports?
The reason is that other reports are derived core module which is being used in the report RSIRPIRL and thus other application reports would have the same technical behavior as RSIRPIRL. (Exception: Migration/Copy with Transport Layer )
Also why this is a separate blog post and not part of the same?
I like to keep things short and simple. Also, I feel that I may have lost some of my genuine readers if the blog post would have been very long.
So let's come to the point.
As you know now, There are 3 main reports from the which are suggested for the migration of the data. The differences are as below.
| Report RSIRPIRL | Report Z_DOC_COPY | Report Z_MIGRATE_ARCHIVELINK |
| This works in the application context, In other words, this needs a PHIO Class and storage category for selection screen for execution. In other words, this works at the DMS level | This report works in a context with the content repositories. | This report works only on Archivelink documents |
This report migrates to the attachments. In other words, it copies the attachments from the source repository to the destination repository and then deletes the attachments from the source repository.
As this report deletes the attachments after copying it to the destination repository. There is a chance of attachments loss in case the create operation on the destination repository is inconsistent. |
This report copies the attachments between the source repository and the destination repository. The report does not delete the attachments at the source repository. You have to delete the documents from the source repository.
No chance of data loss. Ideally, we double the data volume. | Same as Z_DOC_COPY |
| This report also changes attachments metadata in SAP tables. The program modifies the tables in a way that KPro would read the documents from the destination once the migration of the document is complete. Works on one document at a time. | No changes in metadata tables are made, the customer has to adjust them manually. After a successful document copy. Works on one document at a time | Report adjusts the Link table entries and attachments would be accessed from the destination repository / new repository |
| As this report works on the application level, there are chances that after migrating the data from source to destination, We may have residual documents on the content server. These documents can be from other applications like Archiving / Archivelink. These can also be orphan documents (documents do not have application context) | All consistent documents are copied. | The report copies all the consistent documents from the source repository to the destination repository. Documents remain on the source repository and are not deleted |
| This report can work with any type of storage like HTTP content Servers, RFC repositories, SAP System Database storage, etc. | Works with only with SAP content Servers, in other words, SAP System Database storage repository and SAP HTTP repository (Undocumented* Command docidlist ) | This report can work with any types of storages like HTTP content Servers, RFC repositories, SAP DB |
| It can be restarted and the report would continue from where it left in last execution. | It can be restarted and the report would continue from where it left in last execution. | It can be restarted and the report would continue from where it left in last execution |
Undocumented *:- This command is not documented in SAP HTTP interface guide and only SAP repositories have implementation for this.
Limitations with all these reports.
1) These report needs to have different repository names. Because the customer has to create repositories in the same SAP system (Transaction OAC0) and SAP would not accept the duplicate in this case.
2) These reports will not work across the systems. In other words, you need to connect both the repositories to the same SAP system. This does not work via RFC.
*Please note that this was compiled before CMIS repositories were in use. CMIS there are changes in the way documents are handled. the Report Z_DOC_COPY cannot be used for ArchiveLink Documents with CMIS repository.
1) Report Z_DOC_COPY
Issues that can occur:-
1) The report is Slow:- These are ABAP reports and the customer would be moving a large amount of data (a couple of GBs or TBs) via SAP system and thus copy process is slower. This report works with a single document at a time. In case you feel that the report is slow and you would like to execute this in parallel, please schedule the report manually by using the date range option in the report RSIRPIRL.
Report Z_DOC_COPY cannot be executed in parallel unless you trigger this with a specific list of documents in parallel.
Please note that Z_MIGRATE_ARCHIVELINK cannot be executed in parallel.
2) Memory Overflow while report execution.
KPro communicates with the content server with SAPHTTP or ICM client. In some cases, ICM may run out of memory and thus your background job may be terminated. In this case, we would recommend you to add the following entry in table SDOKPROF and restart the job.
NAME = USEHTTPPLG and VALUE = OFF.
(This setting would use SAPHTTP client to communicate with the content server instead of ICM).
3) Always make sure that you are using the latest version of the content server patch and SAPHTTP while performing the migration. You would be touching a large number of documents during the migration process and thus any bug in these components can cause a large impact on your systems. Please also make sure that you have a necessary backup of the content server, KPro Header table, and link tables. In case the migration fails you have to restore these tables.
So that’s all for now. In the next part of this series, I plan to provide details on what can be done as the next steps in your system or what you generally call follow up activities.
