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

What is the data transfer latency?

What is... This is a short answer and question category.Explanation: The BAM Server collects events from the audit trail database that occurred 30 seconds in the past. This delay ensures that late arriving audit trail events are collected.

Function: On high load environments where Process Engine handles large volumes of workflows simultaneourly (> 100 concurrent WF events) the Content Server takes more than some second to complete the transaction.
Default latency is 30 second. On high load environments the latency up to 300 seconds and more.
–higher latency = longer delay for update the report data in the dashboard–

Relevant products: Business Activity Monitor, Content Server, xCP, Process Engine

additional information:server step size

What is... This is a short answer and question category.What is the GAP-filler?

Explanation: The gap-filler-feature is part of the Content Server and stores data between the Content Server and the Business Activity Monitor (BAM) database.

Function: The Content Server continuously writes audited data into the audit trail table regardless of whether the Business Acitvity Monitor Server monitors the data.
If the BAM database goes offline the gap-filler-feature stores the data and fills the backlogged data into the BAM Server after a preconfigured period.
Default period is 5 Minutes. There is no numeric imitation to the period time accept the BAM memory size.

Relevant products: Business Activity Monitor, Content Server, xCP

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