The Extremely Efficient Efficiency Hold – Special use cases based on the OpenText Documentum Life Sciences Solution Suite (Part 1)

The Extremely Efficient Efficiency Hold – Special use cases based on the OpenText Documentum Life Sciences Solution Suite (Part 1)

by | Feb 20, 2018 | Documentum, ECM, Life Sciences, OpenText

Case Study

A manufacturing life sciences company is installing a new centrifuge for a production plant producing drug substances. In order to avoid operating errors, every employee who will operate the device in the future must undergo compulsory training tailored to the device. Within the training course, among other things, the work instructions created for the device are explained.

The work instruction passes through the obligatory document management processes prior to the training. Within the company’s own electronic document management system (DMS), those responsible for production operations approve the work instructions digitally. The approval takes place on 15 January. A document coordinator specifies February 1 as the effective date for the document. The device is to be used as of this date. The DMS ensures that the working instructions receive a corresponding electronic watermark automatically on February 1. Furthermore, the DMS automatically copies the watermarked document into the company’s own intranet (publishing).

Due to regulatory requirements, the work instruction may only be effective after all relevant employees have been trained by the DMS.

Two employees cannot attend the training due to illness. Since the training took place only a few days before the effective date and not all employees were able to complete the training, a responsible document coordinator must ensure that the document will not be effective from 1 February. Only when the remaining employees have completed the training, the work instructions may be effective. To do this, the coordinator sets a lock on the document: An Effectivity Hold. After the employees have been trained, the document coordinator removes the lock from the document. As soon as the lock is removed, the DMS transfers the work instruction to the effectivity status including the above-mentioned publishing.

Solution from the user’s point of view (excerpt)

The document coordinator sets an Effectivity Hold to an approved work instruction.

A reason must be given that is recorded in the audit trail of the document:

The attribute page of the document displays the Effectivity Hold information read-only:

Technical implementation (excerpt)

The outlined business process is implemented on the basis of the OpenTextDocumentum Life Sciences Solution Suite. Customer-specific adaptations at D2 level ensure that the Effectivity Hold functionality is seamlessly integrated into the Life Sciences Suite.

A D2 Property Page provides the input fields for the document coordinator:

A D2 uniqueness condition within the D2 lifecycle blocks the effective setting:

Do you have any questions or wish further information?
Simply fill in our > contact form or visit our > OpenText Documentum Life Sciences Solution Suite landing page.

Here you can find the second part of my blogpost series »Special use cases based on OpenText Documentum for Life Sciences«: > The Mysterious Case of TDC

Synchronizing OpenText Documentum Metadata with SAP

Synchronizing OpenText Documentum Metadata with SAP

by | Aug 24, 2017 | Documentum, ECM, Life Sciences, OpenText

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.

Scenario 1:
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).

Scenario 2:
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.

Scenario 3:
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.

Delta Synchronizations

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:
      • Modification Date=20170401

    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!