Sometimes not the leading edge technologies are causing you headaches, but also solid requirements like synchronizing your Document object’s attributes with SAP.
In this blog post I will explain the differences and purposes of the OpenText Documentum Archive Services for SAP and OpenText Documentum Content Services for SAP as well as the challenge to synchronize only modified SAP data into OpenText Documentum.
OpenText Documentum Archive Services for SAP
The main purpose of the OpenText Documentum Archive Services for SAP (ASSAP) is to accept content (e.g. the printable bill) delivered by SAP. For this, the ASSAP exposes as ArchiveLink server. With the ArchiveLink protocol, SAP is not only able to archive content but also able to retrieve that content for display purposes. Such content can be for example billing documents. So the active part is SAP. OpenText Documentum is the passive part. The ASSAP will create the link information with SAP archive maintenance data.
OpenText Documentum Content Services for SAP
In short, if you want to interact with SAP in another way than using the ArchiveLink protocol, you need the OpenText Documentum Content Services for SAP (CSSAP).
The mapping is defined by the Document configuration objects, which are text based.
Configurations can be e.g. a mapping of a SAP attribute to an OpenText Documentum attribute or a query executed either against OpenText Documentum or SAP.
If you have the content first in OpenText Documentum and want it to link with SAP, a barcode link is a possible way to archive this. The available barcodes inside OpenText Documentum have to be published to SAP. With this, the user can link e.g. a SAP billing document with an available (external) barcode. After this, the Document object (and its content) is linked to the appropriate SAP object and the content can be retrieved via the ArchiveLink interface (exposed by the ASSAP).
You want to pull metadata e.g. from a billing document from SAP to OpenText Documentum. For this, suitable search criteria are needed (the receipt number, the ArchiveLink ID, etc.) to build a query against SAP. All matching SAP objects are then mapped to OpenText Documentum objects and all configured attributes are copied from the SAP object into the corresponding OpenText Documentum object. Mapping of attributes might not need necessarily to be linked to the same OpenText Documentum object holding the content. It is up to you how you want to define the mapping rules.
You can also modify SAP data based on OpenText Documentum objects’ values. However pulling data from SAP can be performed with standard RFC calls. For pushing data to SAP, the best way is to utilize a custom BAPI created especially for that purpose.
The CSSAP works best for one-time synchronizations based e.g. on missing data or on specific lifecycle status names.
However with some tweaks you can get the best value of CSSAP and enable delta synchronization abilities:
- Perform a query against SAP to determine all modified SAP data. For this, weave into the SAP query conditions (query parameters) conditions for querying e.g. a modification date.
For example a regular query parameter inside ASSAP looks like this:
Change this line e.g. to
Modification Date=‘00000000’ OR AEDAT GE ‘$modified’ OR ERDAT GE ‘$created’
$DQL=select max(any_tracking_creation_date) as created, max(any_tracking_modification_date) as modified from your_object_type
With this change all creations (field ERDAT) and modifications (field AEDAT) can be identified.
- Based on the result of the above query mark all OpenText Documentum objects subject to synchronization (to be more fault tolerant).
- Now perform a query against SAP to match all objects in scope of the synchronization. Inject e.g. the receipt no into the SAP query of all pending OpenText Documentum objects. Consider to limit the amount of injected parameters (e.g. the amount of receipt numbers and by this the amount of retrieved receipts) to avoid a synchronization process which will span over a too long time period. Due to the split into a mark and a synchronization step, postponing object synchronization to subsequent synchronization runs is no problem. Either abort of the synchronization step is no problem. The next run will synchronize missed objects. The limitation of the amount of objects can be done e.g. by the DQL hint “return_top N”.
- Consider increasing the amount of objects within a single transaction (CSSAP configuration) from 1 (default) to a huge amount of objects. By this, the mark step will get fault tolerant and nevertheless the amount of objects processed by ASSAP is limited by the above mentioned object limitation (enforced by the hint “return_top N”).
All taken together, you can achieve a delta metadata synchronization from SAP into OpenText Documentum.
Don’t hesitate to get in touch with me or to share your thoughts and ideas with me!