External CMIS document repository - Custom implementation

[egbertvenema_mybrand]

The main question: How can I get SAP to call a custom implementation of the CMIS interface?

Why would we want to? At our current project, we need to store specific generated documents on an external CMIS server. SAP provides a default implementation for this using CL_CMIS_OUTBOUND_API, which is working like a charm together with DMS on BTP. However in this instance, we are required to communicate using SOAP messages, which is not supported by the API. Additionally we need to add custom properties to the call, so one way or the other this is going to be custom coding.

I have a WSDL, with which I can create a service consumer and consequently call all available methods to work with CMIS objects. We will have to build and handle the messages manually, but ok, it is what it is.

After storing a document, we would like to be able to open it again using GOS. When saving/opening documents, the GOS framework looks at the business object, the document type, the repository and performs actions based on standard SAP coding. This is where we would like to implement our own version... but how?

What Document Area and Storage type should we use for such a requirement? Or am I missing a very obvious alternative?

Thanks in advance for the help!

[egbertvenema_mybrand]

Hi Karim, thanks for your answer. I've seen your plugin, you mentioned it in other threads related to this subject as well. And even though it might be a viable solution, it also feels a bit overkill for this scenario.

For now we saw no other option than to make a small change to the default class. In method GET_INSTANCE, we now check for a specific RFC destination (the one specific for the repository) and return our own subclass of CL_CMIS_OUTBOUND_API. In our subclass we redefine the methods required for our scenario.

By default, CL_CMIS_OUTBOUND_API is marked as final. Had to remove that checkbox as well.

Far from ideal from a technical point of view, but it does work.

We now have control over the implementation. For example when CREATE_DOCUMENT is called, we determine the document type and call functionality for that document. The method interface remains the same, we use the import en generate the output... just using a SOAP webservice instead of the default REST.