This certification acknowledges competency in the basic operations of the Documentum/xCP platform. Associate (EMCPA) recognition for Documentum/xCP is achieved after passing the Content Management Foundations exam.
The total number of test questions are 66 and the pass % is 71.
Sections to be focused:
Users and Groups
Object Security
Administration
Architecture
Content Management
Workflow and Lifecycle Management
Some quick notes for preparing for certification
FSS (File Share Services)
FSS provides
- A lightweight set of content management features
- Access to the repository from your desktop (Windows Explorer or Macintosh Finder)
- FSS makes the repository look like a network drive.
Defining work queue override policies A work queue override policy allows the priority and aging of a task to be controlled based on the document properties and lifecycle. Override policies can be used when different document types with different processing needs are routed through the workflow. For example, applications for different types of loan products might have different priorities and different aging requirements. To use override policies, when you apply a lifecycle to the document, you define the alias set %wq_doc_profile to the override policy that you want the system to apply to the document. If there is no override policy associated with the document, the system uses the policy associated with the work queue to set the properties of the work item.
Work queue policies
A work queue policy contains the logic that the system uses to track and manage tasks in the work queue. This logic enables the system to assign an initial priority and age the priority of the task based on different values you set up in the policy.
The queue policy contains settings for priorities, management settings, thresholds, and other management functions. When a new item comes in for workflow, the server identifies the activity as a work queue item, checks the priority value in the policy, and assigns an initial priority to the item. After the task is in the queue, the aging job increases the priority incrementally based upon the policy until the task is worked on.
You also set up threshold values to trigger notifications to the queue manager when high priority items are not being processed or when a specific number of tasks are waiting in a work queue.
With a work queue policy, you can define settings that move an unworked task to a higher priority level when the priority aging job runs.
You can also flag a percentage of tasks to be routed for quality checks.
Priorities of tasks
For most queue processors, work items appear in the Inbox based on their priority—the highest priority items are assigned to be worked on before lower priority work items. Priority and aging settings are essential elements in the processing of work queue tasks. When the system creates a new work item, the server identifies the task as a work queue item and checks for logic to enable it to assign an initial priority to the item. After the task is in the queue, an aging job increases the priority of the task based upon other logic, which moves the task higher in the Inbox until the task is worked on. Priority escalation may trigger the queue administrator to redistribute tasks or reallocate resources between work queues.
The priority level at which a task first appears and the speed at which it increases in priority can be set either in the work queue policy or in the activity template for the task. For example, you set the initial priority for new tasks in a queue to 1, which means that all new tasks begin with a priority of 1. If you have set the Increment Priority to 10, then whenever the dm_QmPriorityAging job runs, the priority increases by a factor of ten, if the task has not been worked on. In this example, the task has remained in the queue and the dm_QmPriorityAging job has run three times, increasing the priority to 31. The maximum priority field is set to 30, so the system sends a notification to the queue managers group, warning that the task has surpassed its maximum priority and needs attention.
Defining work assignment matching filters
Each work assignment matching filter contains the skill definitions that enable the system to match a processor with a task based on the skills required by the task and the abilities or expertise of the processor. When you create the filter, you define the possible skill values, display labels, data types, and operators used by the system to compare the list of processor skills against the required job skills and assign the task to an appropriate processor.
The process template in Process Builder must have these skills defined for the task, as well.
Users with the queue_admin role can create, delete, or modify queue matching filters. Users with the queue_manager role can view the settings of the matching filters only.
Email Inbound - Initiate and Step
Email activity templates poll email servers for incoming messages and then process them according to the business logic you've specified. Within the Email Inbound activity template, you define the connection to the email server, select options for processing the message after it has been read, and map data from the incoming message to the process data that is used in the process.
For example, in a customer complaint business process, you can configure an inbound email template as the initiate activity in the process. The activity polls the email server and starts a new workflow when it receives a customer complaint email message. In the following steps of the process, the system routes the email through a manual activity to a person who reviews the complaint and resolves the issue.
Note: The email client must have encoding set to UTF-8 while sending and reading messages that use multi-byte characters.
HTTP Inbound - Initiate and Step
Use the HTTP Inbound activity template to receive and process HTTP messages sent by an external client. You configure the HTTP Listener to listen for a specific URL suffix and then read and process incoming messages. The incoming message can be mapped to process data using the data mapper.
The system then sends a synchronous response back to the client using the response type that you specify in the activity template.
Note: The browser must have encoding set to UTF-8 when sending the request to the inbound HTTP listener when multi-byte characters are used.
To configure the HTTP Inbound activity template:
1. Type the URL Suffix to which the URL request is sent. For example, if the HTTP request URL sent from the client is http://eng076:8001/bps/http/ReceivePO, then the suffix is ReceivePO.
Using an HTTP Inbound Initiate activity to create a new high-fidelity form instance
You can use an inbound activity to create a new high-fidelity form instance.
HTTP Post
The activity template for posting content using HTTP is the most straightforward of the integration activity templates. It has one required custom parameter and two optional parameters.
· URL - This required parameter is the complete URL of the site to which the activity posts content, starting with the protocol prefix http://.
· Timeout (sec) - This optional parameter sets the timeout value for the HTTP connection, in seconds. If you do not include a timeout value or set it to 0, the connection will not timeout.
· Send content from activity package - This optional parameter identifies which content the activity posts to the specified URL. The value is the name of one of the activity's inbound packages. If you do not provide a value, the activity sends the content of the first inbound package (the package at index 0). You can only post the content from one package.
· WS Inbound Initiate and Step
· This activity template is only supported for releases of Documentum Process Builder version 6.5 and greater. If an earlier version of Process Builder is used against a Documentum 6.5 repository, this template will not open.
· Note: The web service inbound listeners must be created before the WSDL can be accessed by the URLs.
· The following are the valid URL formats for accessing the WSDL:
· http://<hostname>:<port>/bps/webservice/<processID>?WSDL
· http://<hostname>:<port>/bps/webservice/<processName>?WSDL
· http://<hostname>:<port>/bps/webservice/<processName>/<version>?WSDL
· Use Web Service Inbound to create a new web services end-point for an activity that needs to provide an integration point and a WSDL to an external system.
· For example, you could use the Web Service Inbound activity template in a loan application process to start the process after it receives an incoming SOAP request. You can set up the activity with WS-Security to require that the applicant provide a username and password to secure the web service. If the loan application includes large documents, you can enable MTOM support for the activity that will enable the activity to send and receive optimized binary data as attachments.
· As a step in a process, the Web Service Inbound-Step activity can be used to receive information from an outside source. The activity can also be used to verify income or get other related information from an outside source. You can enable security to ensure that only authorized individuals can initiate the process.
HTTP Outbound
The HTTP Outbound activity template sends an HTTP request to a specified URL and can receive a response back from the server. The fields in the activity template enable you to specify data that can be mapped to the process data model.
To configure the HTTP Outbound activity template:
1. Type the complete URL of the site to which the activity posts content, starting with the protocol prefix http://.
2. If authentication is required by the server, select Authentication to require a username and a password.
Note:
Only Basic authentication is supported in the HTTP Outbound activity template.
3. Type a Username and Password if you are requiring authentication.
4. Select a Request Method that specifies the type of request to be sent to the server.
Valid values are GET, POST, and PUT.
SMTP Activity Template
Use the SMTP activity template to send email messages with attachments to lists of users. For example, you can add an activity template that sends an email message as a response to a customer complaint or send an expense report in the body of the email message for approval.
To configure the SMTP activity template:
1. Type the Host Name of the server host machine or its IP address.
2. Type the parameter that identifies the Port Number for the server.
If you do not provide a value, the activity uses the standard number based on the server type you choose.
3. Select the optional value to Use Encryption. The default value is None.
Note:
For SSL or TLS encryption, you must have an SSL certificate in your environment. See the Process Integrator Deployment Guide for instructions on importing SSL certificates to support encrypted connections for activity templates.
Overview of Process Reporting Services
Process Reporting Services (PRS) is a BAM tool used for creating reports and alerts on monitored processes. Reporting itself extends beyond PRS and involves a few other BAM components, as displayed in the following figure. The backbone of any report or alert is a data source. A data source is a query that runs against the BAM database (by way of the BAM server) and is defined with report entities and fields. All BAM report entities and fields are stored in the repository and are made available to PRS through the BAM server. Queries can be run against execution tables or any of the aggregation tables of the BAM database. Once data is returned to PRS, the report can either be formatted as a simple Flash-based chart, or made available to Crystal Reports for advanced formatting. Reports formatted in Crystal Reports are synchronized back into PRS where they, along with simple reports, are published to a BAM dashboard.
Understanding the data model
The data model represents the data that is created or modified in a process. It is a key foundation for the solution. A flawed data model leads to rework, which consumes valuable time. Therefore, the data model must be established as early in the implementation phase as possible.
Process data refers to the different types of data that flow through the process. Process data consists of:
· Packages, which capture metadata associated with Documentum objects such as documents or folders.
· Process variables, such as part numbers or customer addresses. Process variables can be simple data types (like String or Int) or structured data types (SDTs).
· Process parameters, which enable administrators to modify and control all instances of a given workflow template.
Process data can be used in transition conditions (where the next activity executing is dependent on the data values), conditional performers (in which the performer for a manual activity is selected based on a data value), and in creating service-specific messages (for instance, the creation of a SOAP message to invoke a web service). The process data model can contain transient data (modeled using process variables) as well as persistent data (modeled as packages). Define your data model early in the design process before you begin creating the process within Process Builder. Also consider the data requirements of the entire application, including the process, forms, and user interface (TaskSpace).
Package attributes versus SDTs
During the design phase, decide when you will be using packages and when you will be using process variables. The decision is important and is a key part of successful design and implementation:
· If the customer wants to store and search data in the task list template, use SDTs.
· If the customer wants to persist data beyond the process instance, use package attributes.
· If you want both, you must initially use SDTs and then map them to package attributes at the end of the process.
Some additional considerations include:
· To search on SDTs in the user interface, use a task list template for the search.
· If you delete or change the name of an SDT after implementing it, you will break the data binding in Forms Builder. You must delete the dangling control or rebind it to the renamed SDT.
· SDTs are more lightweight than object attributes and are better for performance and scalability.
Permissions for individuals
The basic permission levels of global access are:
- None. The user cannot see any object or any object attributes.
- Browse. The user can see attributes but no object content.
- Read. The user can see the attributes and the content of any object.
- Relate. The user can do everything that Read permission allows as well as add annotations.
- Version. The user can do everything allowed under Relate permission as well as change the object content, but the user cannot change content without updating the version and cannot alter attributes.
- Write. The user can do everything allowed under Version permission in addition to changing content without updating the version. Write also allows the user to alter object attributes.
- Delete. The user can do everything allowed under Write permission as well as delete any object.
You can also assign extended default permissions to individual users. If you grant a user one of these permissions, he or she can perform the function unless restricted by an object-level permission. The extended permissions are:
- Execute Procedure. The user can execute external processes.
- Change Location. The user can move the location of an object within a repository.
- Change State. The user can change the state of a lifecycle object.
- Change Permission. The user can modify the permissions of an object.
- Change Ownership. The user can change the ownership of an object.
- Extended Delete. The user can delete objects but cannot alter the content of object attributes.
The user can delete the object. The delete object extended permission is not equivalent to the base Delete permission. Delete Object extended permission does not grant Browse, Read, Relate, Version, or Write permission.
Best Practices in Naming Documentum Users and Groups
Constraints:
- The maximum allowed length for User and group names is 32 characters.
- Do not begin a name with the prefix dm. Documentum reserves this prefix for its own use.
- The name must consist of ASCII characters.
- User and group names are case sensitive.
- It is good practice not to choose names that conflict with DQL reserved words.
Figure 2. Database storage of unmaterialized lightweight object instances
The order record instances represented by objID_2 and objID_3 share the property values of
the customer record instance represented by objID_B. Similarly, the order record object instance
represented by objID_5 shares the property values of the customer record object instance represented
by objID_Z. The i_sharing_type property for the parent, or shared, rows in customer_record are set
to reflect the fact that those rows are shared.
There are no order record-specific rows created in customer_record_s for the unmaterialized order
record objects.
Because the order record object type is defined for automatic materialization, certain operations on
an instance will materialize the instance. This does not create a new order record instance, but
instead creates a new row in the customer record table that is specific to the materialized order
record instance. Figure 3, page 76, illustrates how a materialized instance is represented in the
The order record instances represented by objID_2 and objID_3 share the property values of
the customer record instance represented by objID_B. Similarly, the order record object instance
represented by objID_5 shares the property values of the customer record object instance represented
by objID_Z. The i_sharing_type property for the parent, or shared, rows in customer_record are set
to reflect the fact that those rows are shared.
There are no order record-specific rows created in customer_record_s for the unmaterialized order
record objects.
Because the order record object type is defined for automatic materialization, certain operations on
an instance will materialize the instance. This does not create a new order record instance, but
instead creates a new row in the customer record table that is specific to the materialized order
record instance. Figure 3, page 76, illustrates how a materialized instance is represented in the database tables.
Figure 3. Database storage of materialized lightweight object instances
Materializing the order record instances created new rows in the customer_record_s table, one row for
each order record object, and additional rows in each supertype table in the type hierarchy. The object
ID of each customer record object representing a materialized order record object is set to the object ID
of the order record object it represents, to associate the row with the order record object. Additionally,
the i_sharing_type property of the previously shared customer record object is updated. In the order
record objects, the i_sharing_parent property is reset to the object ID of the order record object itself.
Groups
When a group is created by a user with Sysadmin or Superuser user privileges, the group is public by default. If a user with Create Group privileges creates the group, it is private by default.
Role groups
A role group contains a set of users or other groups or both that are assigned a particular role within
a client application domain. A role group is created by setting the group_class property to role
and the group_name property to the role name.
Module role groups
A module role group is a role group that is used by an installed BOF module. It represents a role
assigned to a module of code, rather than a particular user or group. Module role groups are used
internally. The group_class value for these groups is module role.
Privileged group
A privileged group is a group whose members are allowed to perform privileged operations even
though the members do not have the privileges as individuals. A privileged group has a group_class
value of privilege group.
Domain groups
A domain group represents a particular client application domain. A domain group contains a set of
role groups, corresponding to the roles recognized by the client application.
How role and domain groups are used
Role and domain groups are used by client applications to implement roles within an application.
The two kinds of groups are used together to achieve role-based functionality. Content Server does
not enforce client application roles.
Note: Content Server does not enforce client application roles. It is the responsibility of the client
application to determine if there are role groups defined for the application and apply and enforce
any customizations based on those roles.
What a dynamic group is
A dynamic group is a group, of any group class, whose list of members is considered a list of potential
members. A setting in the group’s definition defines whether the potential members are treated as
members of the group or not when a repository session is started. Depending on that setting, an
application can issue a session call to add or remove a user from the group when the session starts.
Mixing dynamic and non-dynamic groups in group memberships
A non-dynamic group cannot have a dynamic group as a member.
A dynamic group can include other dynamic groups as members or non-dynamic groups as
members. However, if a non-dynamic group is a member, the members of the non-dynamic group
