Dear Colleagues,
Welcome Back
🙂 I realized sometime back that there is still a missing piece in the puzzle of Repository Migration which is about error handling. With this post, I would try to answer a few more questions and also add information on how to analyze errors in case you face them and basic tricks that can help you in resolving them. I will keep it as a FAQ for simplicity.
Q:- How can I find an existing storage category that is getting used for storing the attachments
Ans:-
>> If you know the document class (PHIO Class) You can go to table SDOKPHCL. In this table using PHIO_CLASS as input, you can find the header table and then check the header table. This header table will hold all the PHIO Ids which will be created in this PHIO class. You can also find the storage category here.
>> If you know repository that you are using, You can go to transaction OACT and find corresponding storage category
>> If you are using Archivelink application You can use transaction OAC2 to find the content repository and then use it in ArchiveLink report
Q:- I have performed the migration of the documents and I still find that some documents are remaining in source repository what should I do?
Ans:-
There can be multiple reasons why these documents can be remaining in your repository. I can list a few possibilities so that you can weigh them and make a correct call.
>>> These documents are test /dummy documents that are created while repository testing. I need not tell you that you can ignore these documents. You can find it by checking the document contents.
>>> These are documents which are remaining as the deletion of these documents were missed out and there is no business document which is referring to them.
You can find this by trying to find these Document Ids in PHIO header table and ArchiveLink link tables and then you can be assured that these documents are most likely would not be accessed. ( Exception to this statement:- You have Archived the links and document is still there in the repository) . You should make your own call here. But if there is no archiving which is involved you can consider deleting the documents. You should also execute report
'RSIR_CONTENT_UNMARK_PRELIM' this report will delete marked documents.
>>> These are actual business documents from the required document class but they were not migrated and you are getting an error in migration. In this case, we need to dive deeper. You use below mentioned methods to find why failure and decide what should be next.
Please note that in case you are using Archivelink report Z_MIGRATE_ARCHIVELINK ( SAP note 1043676 Or report Z_DOC_COPY SAP note 2774469 the source repository will be untouched and the documents would remain in the source. The above question is not relevant in that case.
] Q:- I get an error while executing report RSIRPIRL now what?
Ans:-
If your inputs are correct and existing documents have been saved correctly, you should not be facing any issues. As you are facing the issues, let's try to find what went wrong.
As a first step, You should check application logs with transaction SLG1. You should use the object as 'SDOK' and 'SCMS'. KPro will log the error against these two objects.
Here looking at the error, if you find that you have an issue in reading attachment from the original repository, You should try to access the documents from the actual business object and if you get an error, you should be certain that error is in the source repository.
If you find that error is while creating the document in the new repository, You know that error is in the target repository. To re-confirm that your target repository is working correctly, You can use test report RSCMST with input as Repository ID and then Report RSCMSTH0 and RSCMSTH1 to confirm that repository is working correctly.
In general, You will not have an error in the source repository because your business would have reached out to you by now. You will most likely have an error in the transfer of the document to the target repository or in the Target repository and steps above should help. In case this is not helping, please take necessary traces while you try to migrate the documents and contact your repository vendor.
Qs:- I have migrated the documents with report RSIRPIRL and now we are not able to access the documents.
Ans:-
This is the most difficult and unpleasant of all. This issue becomes more annoying if it occurs for some documents and not for all.
In my experience, there have been cases where there were some issues in the data transfer from SAP and if you are using stable software patch chances of you facing issues is fairly low.
Another case that I have seen where you may face issues is that you have saved the documents incorrectly, e.g. without file size and now you are moving your documents to the HTTP server and you find that the documents are not saved correctly.
Technically, if you were using SAP DB for the document storage, Kpro just performs the export the contents and document information to the R3 Database.
When you try to move this data to the external server the server will get the file information along with the contents. Here if the file size zero,
the HTTP content server ignores the contents and stores the empty file.
My recommendation to handle this would be you make sure that you take the back-up of your source server before you start the migration. This will save you in case things turn sour.
Another issue that can happen is that you have saved the documents with incorrect MIME Types and then you perform the migration where virus scanner would block the file because of the incorrect MIME type. You should correct the MIME types in this case. You can use the SAP standard report to correct the MIME type of each individual document.
This would help you with the migration of existing documents.
So That's all that I can come up with for now. Be safe and be healthy. Until next time
Bye, Ciao, Tschüss.
