Skip to Content

Tools for migrating GOS attachments

May 07 at 08:18 PM


avatar image

We're migrating data from a legacy SAP ECC system to a newly implemented one. Many SAP business objects, such as materials, maintenance plans, functional locations and FI documents, have documents attached to them via the Generic Object Services (GOS). The documents are stored in the legacy system's database.

What's the best way to migrate these GOS attachments along with the SAP business objects? Are there really no standard tools for that?

Note 389366 and KBA 2365781, as well as many Q&A posts describe how to use report RSIRPIRL to migrate the documents from one content repository to another. However, in that scenario the ECC system stays the same. If we migrate the attachments to an external content repository while the business objects are in the legacy system, can we somehow ensure the integrity of the links when we migrate to the new system?

For custom development scenarios, Philip Johnston posted a nice blog about uploading and downloading GOS attachments. In it's comments, he proposes using the tools for a migration scenario, too.

One post quoted an anonymous source: Migration of GOS attachements is challenging. Nothing ready for use exists in SAP to do it. '

Is that really the case?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Tammy Powlas
May 07 at 09:25 PM

In this thread it looks like Jürgen L company bought a program from SAP. Interesting.

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Cool! As SAP has already developed it a couple of years back, we should get it with a discount ;)

Our source system is ECC 6.0 on NW 7.0, so the link table SRBCSBREL Jürgen mentions is there.

Much as I like coding, I think building the solution from scratch is a Conan the Barbarian solution. One would think there has been a need for it hundreds of times already.

Mike Pokraka May 07 at 11:29 PM

Interesting topic. As the documents are stored independently, it's "just" a matter of recreating the links :-)

My approach would be something like:

  • Migrate documents and keep a record of old/new IDs.
  • Create a link to the new document ID via a custom report. The links are stored as binary relations, you will get to know CL_BINARY_RELATION very well.
  • You should now see duplicates of all your attachments in GOS
  • Delete the old links when you're happy.

It won't be an afternoon's job, but I think it should be doable.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Mike, I'm not sure I understand your idea. Why would there be duplicates?

My idea is along the lines of

  1. define a new, external content repository
  2. use RSIRPIRL to migrate the documents from the current content repository to the new one. This is all with the old ECC. After this, the business objects (material masters etc.) of the old ECC point to GOS objects in the new external repository
  3. define the same external repository to the new ECC system, so it can access documents
  4. migrate the business objects (material masters etc) from the old ECC to the new ECC
  5. (this is the step I'm most unclear about) - copy the GOS links from the old ECC's business objects to the new ECC. For this, we'd build the custom report you mention. But - will the links/binary relations work as such in the new system?

OK, I thought RSIRPIRL just copied, wasn't aware that it would also repoint the GOS references, my second step was to create the link to the new copy, hence you'd have seen a duplicate.

Nevertheless, the principle remains the same: As long as you have a list of the links, you can recreate them, it should be the same relations as in the old system. You will have to dig deep into CL_BINARY_RELATIONS and the underlying tables.