A couple of things regarding GOS and ArchiveLink for attaching Business Documents
Our project has implemented an OpenText archive server and we have integrated it to the SAP environment.
The first phase that we have implemented is simply to allow users to attach documents into the various business transactions in SAP. SAP uses the GOS button in order to store (Create->Store Business Document) and retrieve (Attachment List) documents associated with document types and classes that we are storing in the archive server.
Iu2019ve done some searching on the web and have seen that other people have complained about these same two issues that we are experiencing.
Everything is working well, but weu2019ve got a few users starting to make some noise about how SAP handles the attaching of the documents. Iu2019ve done some investigation and it seems to me that it is just the way that SAP has architected itu2019s solution for connecting to repositories via ArchiveLink.
The users are complaining that they canu2019t attach documents when they are in u201Ccreateu201D transactions and can only do them in u201CDisplayu201D or u201CChangeu201D transactions. For example they can attach documents to customers in XD02 and XD03 but not XD01.
From a technology perspective I understand why this is the case. They havenu2019t included the GOS functionality in create transactions because the main input required for any GOS functions is the document number and the document hasnu2019t been created yet and therefore wonu2019t be able to update the link table. Even more so, the GOS function is executed as a separate DB transaction.
Iu2019ve told them that in order to make it work on u201CCreateu201D transactions I would have to do all sorts of custom development to re-architect how standard SAP uses GOS and ArchiveLink. This would of course be a big rework of standard SAP across many transactions. It would be a complicated piece of work where we would have to do some sort of a loose/late coupling in the link table. This is a path that I for sure donu2019t want to go down because it would be a Pandorau2019s box of stuff.
I mentioned to them that we could maybe use a different scenario where the attachment comes in as part of a workflow which triggers the u201CCreateu201D transaction and then as a final step attaches the document, but this isnu2019t what they are looking for, they want to attach various documents at the time of creation of the business transaction. Iu2019ve told them that they will have to use the u201CCreateu201D transaction, save and then use the u201CChangeu201D transaction so that they can access the ArchiveLink functionality.
Iu2019ve been explaining this to them, but unfortunately people donu2019t seem to believe me that every project would have this same problem and that it is a result of how SAP has architected the archive link functionality via the GOS button. They are asking me to check with other projects, so I wanted to find out if anyone had this same issue at their clients and if you have found a work around. I figure from what Iu2019ve seen of how SAP has architected it that there wouldnu2019t have been any easy work around.
I wanted to see if you had come across one other annoying thing about how SAP does ArchiveLink functionality. If you use the GOS button to go to u201CAttachment Listu201D to view a document that has been stored via u201CCreate->Store Business Documentu201D then the title of the document is always listed as the Document Type and it doesnu2019t show the individual file name. Iu2019ve debugged through the standard SAP code and have seen that they donu2019t store the file name for business documents (Only for attachments stored in the SAP Database), but I wanted to see if anyone had had experience with any customers complaining about this. It ends up being annoying for users because for example they may attach to a customer master record multiple files for a document type called u201CCustomer Info Sheetu201D and now from the u201CAttachment Listu201D there is no way to differentiate between them. Seems that SAP didnu2019t think it through entirely I guess.
Any help is appreciated.