Kategorie Archiv: Documentum

Understanding Process Data

Understanding Process Data

xCP 1.x compatible

There are three kind of process data used in Process Builder:

  • Package attributes are the metadata associated with the object
  • Process variables can be single attributes or a complex hierarchy of attributes named Structured Data Types (SDT)
  • Process parameters are predefined values used in all instances

Packages

Packages are metadata associated with the Documentum object which is passed between activities in an existing process. Package data is persistent.

Process variables

Process variables are not persistent. This kind of variables must be mapped in the Process Data Mapping Activity to a package attribute if the value of the variable should persist beyond the life of the process instance.

Structured Data Types are not persistent. They are global and can be used by any process.
It is not possible to delete or modify used SDT attributes. New attributes to an existing SDT can be added. SDT should be used to group logically related business data.
SDTs are more lightweight than object attributes and are better for performance and scalability. Replace as many process variables as possible with SDT attributes (xCP Performance Tuning Guide).

Process parameters

Process parameters are fixed values defined in the process template and available for all process instances. Administrators can change process parameters without uninstalling the process. The changed parameter value is used in all process instances after saving the value.

Any changes to the data model require uninstalling, saving and reinstalling the form and process templates. 
Example: to change a SDT or SDT attribute after implementing you must break the data binding in Forms Builder and rebind the renamed SDT.

Updating process data

To modifying an SDT  – variable it brings a lot of trouble in your environment.
To change the SDT properties you must delete the selected SDT from the environment and recreate the SDT including the old properties and the changed properties.

Modifications:

  • remove an attribute from the SDT
  • decrease the length of a string value (increase the length can be done at any time)
  • change the type of an attribute
  • change from repeating to non-repeating
2012-08-24Permalink

Understanding Accelerated Content Service (ACS)

The Accelerated Content Services is a lightweight server that handles read and write content operations for web‑based client applications (Webtop, Taskspace or D2). ACS server is not available to handle content read and write requests for users on Desktop client applications.The ACS server runs in the Java method server.
By default ACS caching is disabled (Distributed Configuration Guide 6.5 ). To enables ACS caching set the acs.cache.enabled property to true.

There is one ACS server for each Content Server host installation. It communicates with one Content Server for each repository in the host installation. The ACS server is installed automatically when the first repository on the installation is configured.
If additional repositories are added to the installation, the ACS server’s configuration information is updated so that the server can communicate with the primary Content Server for the new repository.

These are the acs.properties file and acs config objects. Each ACS server has one acs.properties file and at least one acs config object. The file is created when the ACS server is installed. The acs config object is created when a repository is configured. The acs config object resides in a repository. Each repository served by an ACS server must have an acs config object for that ACS server. ACS config objects can be modified only through Documentum Administrator, located here Administration -> Distributed Content Configuration -> ACS Servers.

An ACS server cannot access content in other types of storage areas. Nor can it directly access encrypted or compressed content or virtual documents or XML documents. If an ACS server receives a request for a document that it cannot access, the request is forwarded to its associated Content Server, which will service the request and send the result back to the ACS.

ACS servers by default are configured in push mode for communications with a Documentum Message Services (DMS*1) server. They cannot be run in pull mode.
A Branch Office Caching Services (BOCS) server can communicate with a DMS server in either push or pull mode.

UCF*2 provides support for distributed content by providing integration with ACS and BOCS. Both these technologies providen performance optimizations when content is distributed across different repositories in distant network locations.

*1A DMS server is a message routing server. It runs in the application server. Although part of the Content Server product, DMS is packaged separately, with its own installer and is installed on a host that is different from the Content Server host. It is not installed with Content Server.

*2 Unified Client Facilities (UCF) is a proprietary, lightweight client-server application used for managing content transfer between Documentum repositories and UCF-enabled clients. UCF is a remote content transfer application, and is available in the productivity layer in Java (remote mode only) and .NET.

References

  • EMC® Documentum® Documentum Administrator, Version 6.5, User Guide
  • EMC® Documentum® Content Server, Version 6.5, Distributed Configuration Guide
  • EMC® Documentum® Documentum Foundation Services, Version 6.5 SP2, Development Guide
2012-08-21Permalink

ProcessBuilder: Process Correlation

Process Correlation

xCP 1.x compatible

You can use external systems or technologies using a variety of transmission protocols (e.g. SMTP, FTP or Java Messaging Services).
Correlation identifiers are similar to the r_object_id attribute and implemented as a 32 character string containing hexadecimal letters.

The Process Integrator handel two types of communication:

  • Synchronous – a request is sent and the response is immediately received (no real time, negligible delay)
  • Asynchronous a request is sent, but the answer might never be received or will be received at a later time

Correlation ID vs. Correlation Set

Correlation ID explained using the example of the email activity.

The correcation idenifier can be embedded in the subject header of an outgoing email. The email inbound activity parsed the Subject header and extract the correlaction identifier.

The correlation identifier is embedded in the email subject. The correlation ID must be set in the Input Message Mapping window of the SMTP activity.
The name of the correlation ID, in this example $transaction must be set in the email inbound activity.

Positve: easy and fast to use
Negative: Subject header of the incomming email could only contain the correlation identifier and no other additional text. If the matching process instance is not found a correlation error occurs:

ERROR com.documentum.bps.email.inbound.runtime.EmailTask - Could not process the message for 'Process - simple_email_action Activity - Email Inbound - Step'
Listener: 'Process - simple_email_action Activity - Email Inbound - Step'
Workflow: 'null' - 'null'
Workitem: 'null'
Process: 'simple_email_action' - '4bde75d18000853d'
Activity: 'Email Inbound - Step' - '4cde75d1800082b2' - Activity Template: 'Email Inbound - Step'

com.documentum.bps.inbound.WorkflowNotAvailableException: Workflow not found

Correlation Set

Only process variables or properties of the SDT are selectable.

The correlation set can be defined in the Process Properties in the Advanced tab. The set can contain process variables and structured data taypes. Process Parameters or Package informations are not allowed and available.

The Process integrator will always attempt to use a correlation identifier (not correlation set). If the ID is not available the preconfigured correlation set will be used.
Remember: a correltion identifier in the email subject is not an effective way to match the correct process instance.
Best practice is to create a additional set of Process variables. One of these variables is named message_ID or transaction_ID and contains the internal identifier of the outbound SMTP activity.  In the email inbound step the email attribute Reference will be mapped to the Correlation Set attribute transaction_ID (ref. screenshot).

Displayed the second page of the activity Inspector of the Email inbound activity. The attribute ‘Reference’ is mapped to the correlaction set attribute ‘transaction_ID’

 

Table: Protocol and correlation ID

protocolcommunication typeCorrelation ID
EmailasynchronousCorrelation Header
FTPasynchronousCorrelation Pattern
HTTPsynchronous *Correlation Property
Web Servicessynchronous *
Java Messaging Servicesasynchronous
DQLsynchronous
SQLsynchronous
* can be uses in an asynchronous fashion

Additional information: Process Integrator page and Understanding Process Data article

2012-07-25Permalink

WF vs Lifecycle

Here you can find a short overview of two of the automation features that documentum offers. It helps you keep in mind the most important differences. In combination with aliases they even can be transferred from one repository to another. For further information please refer to the corresponding documentation.

LifecycleWorkflow
A lifecycle is what happens to an object.A workflow is what people do to an object.
A lifecycle is a set of linearly connected states.A workflow is a network of activities.
artifact in a Documentum project, to be installed or uninstallednot implemented as a project. Using Project builder WFs can be changed using a checkin / checkout function.
Documentum ComposerWorkflow manager and Process Builder, but not in Documentum Composer.
instance of dm_policyinstance of dm_process
without run-time instanceswith run-time instances (When a user starts a workflow, the server uses the definition in the dm_process object to
create a runtime instance of the workflow. Runtime instances of a workflow are stored
in dm_workflow objects for the duration of the workflow. )
definition states: draft, validated, installed (states that have absolutely nothing to do with the states in the LC which are stored in attributes i_state_no, state_* and others in dm_policy object)definition states: draft, validated, installed
2012-07-16Permalink