Example: You want to update many objects with the same attributes, but some of your result sets should not be updated. Or you must update a selection of objects with different attributes.
One of the possible solutions is to create many unique update statements or WHERE conditions. Or you create a big IN or NOT IN condition with many object_ids.
The best practice is to create a dummy dm_document object in your repository (i.e. with the DQL Tester). The included or excluded objects_ids are stored in the keywords of the dummy dm_document object. The dm_document object can store a huge number of keywords (> 10 000). In practice I have saved more than 30k object_ids in one document. The SELECT or UPDATE statement is very easy and is issued like this:
SELETCT r_object_id, r_lock_owner, object_name, r_lock_date
FROM r_and_d_document (ALL)
NOT IN (select keywords from dm_document WHERE object_name=<dummy name>)
ORDER BY 4 DESC
This statement selects all checked out documents except a number of predefined documents. You can execute many select statements to select the excluded documents. This has the advantage that all of your results are documented.
Select all Documents which are currently running in a Workflow
d.object_name as document_name,
d.r_object_id as doc_identifier,
f.object_name as wfl_name,
f.r_act_name as wf_type,
f.supervisor_name as started_by,
f.r_object_id as wf_id
from dmi_package p, dm_workflow f, dm_document (all) d
where r_workflow_id in (select r_object_id from dm_workflow)
AND p.r_workflow_id = f.r_object_id
AND p.r_component_id = d.r_object_id
ORDER BY 5 ASC
Documents attached to workflow tasks in a user’s Inbox that are overdue
SELECT DISTINCT r_object_id,due_date
FROM dm_dbo.inbox_docs i, dm_document (ALL) d
i.r_object_id = d.r_object_id
AND i_latest_flag = 1
AND DATEFLOOR(day, due_date)<=DATEFLOOR(day, DATE(NOW))
AND due_date IS NOT NULLDATE
ORDER BY due_date,r_object_id
In this case I defined two simple reports, one as a target (contains the data to be shown in addition of the base report’s data) and the other as a base report (contains the data to be improved by the data from the target report) thereby following the best practice to design the target report first and the base report afterwards. The base report is defined as a table chart type and the target report is defined as a pie chart type.
Data Sources are selected by pulling items from the palette area on the left side into the white area in the middle. After pulling the items there one can select how to query the items and how to treat them in the report.The different items selected and processed here influence what is usable in the next step.
3. Select either Pie, Bar, or Table as the chart type.
Process Reporting Services offers Table by default. Attention: The selection made in step 2 influences what is displayed here. Depending on what you selected before you get different information messages (red text in this screenshot saying: “no data available”)
There are combinations of items that are not compatible with every chart type. In this case an error message is issued warning against the compatibility problem.
If you get error messages there - e.g. “y-axis must be numeric value” -, you will have to change that within Chart Data. There you can steer which data belongs to the different axes. If everything works fine, it should look as follows:
The drill-down itself
First create another simple report which will be the base report. For this follow steps 1 – 3. For a better visualization I chose table type as chart type.
4. Within the Chart Data tab locate the series or column for which you are defining a drill-down report.
Click in the Drilldown field. To find it you must open the columns first:
5. To define a drill-down to another report:
a. Select the Report radio button.
b. Browse to and select a target report.
The report selected here is the one created in steps 1-3. It can be selected from a picklist after creation.
The column the drill-down has been designed for changes in color. So the link to the target report is shown. Clicking on the coloured items take the user to the target report.
c. Click the Filter button(to be found under the drill-down button) to define a filter expression.
d. Select a filter tab and filter tree item and move it to the Filter Expression field by double-clicking.
e. Place your cursor within the single quotes and press the Ctrl and spacebar keys on your keyboard simultaneously. This provides a list of dynamic filter values.
f. Double-click a dynamic filter value and click Ok to close the Filter window.
6. To define a drill-down to a URL, select the URL radio button and enter a URL in the field
Note: The URL must be absolute and specify the location of a web page in full. For example:
The result of a functioning drill-down looks as follows: clicking on the changed columns directly takes the user to the drill-down target report. If the drill-down works, it shows in the header like this: base report > target report.
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 are metadata associated with the Documentum object which is passed between activities in an existing process. Package data is persistent.
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 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.
remove an attribute from the SDT
decrease the length of a string value (increase the length can be done at any time)