To simplify the process of moving from Documentum’s user platform WDK to the configurable user platform D2, SmartWave proposes the solution SmartContent.
SmartContent does not turn a WDK application into a D2 configuration. Setting up the D2 configuration based on the business rules remains a manual task. However, because of the flexibility that is provided by a configurable client, there is also the need for a flexible solution to adjust the business data accordingly. This is where the strength of SmartContent is: adjusting the business information along with the business logic in the D2 configuration and reusing exactly that logic.
This document describes several typical use cases that are encountered when changing technology from WDK or WDK based applications to D2 and the impact it has on the data model.
Use Cases
When upgrading or migrating from WDK to D2 the focus of adjusting the application to the business rules moves away from development towards configuration. To get the maximum out of the configuration possibilities of D2 it is very likely that the data model for document storage is adjusted or enlarged respectively to allow the business to make full use of D2.
The legacy data needs to be adjusted accordingly to match the new configuration rules of D2. SmartContent helps both the IT department as well as the end users achieving this goal. SmartContent can be used along with the configuration of D2 in the agile approach of moving towards a new user interface. Each time the D2 configuration is changed, SmartContent is available to prepare the metadata of the legacy documents in the system following that change.
Document location: from BOF to the D2 auto-link mechanism
Let’s assume that the legacy WDK-based application uses the business objects framework (BOF) with its type based or service based objects to set the location of the documents in the repository, based on hardcoded criteria in the BOF. The documents are linked to folders that follow the structure continent/country/city, e.g. Europe/France/Paris.
When using D2 with its configuration this can be done by using auto-link on one attribute with multiple values, such as “smw_location [0]/ smw_location [1]/ smw_location [2]”, or building the path with multiple attributes, such as “smw_continent/ smw_country/ smw_city”.
The full path of the link location is split in three parts by using the forward slash character (/). Then these three parts are then populated into the one location attribute, or if required, into the three separate attributes, continent, country and city. This functionality is available in SmartContent and can be applied on any source attribute.
Obtaining the full path of a document and splitting it into several parts is a two-step process. First, the location is stored into an attribute, and then this attribute is split into multiple values of the same or another attribute.
While trying out which configuration suits the business best, SmartContent can be used to convert the meta-data of the documents and keep linking the documents to the correct folders by invoking the D2core after each data conversion. With the invocation of the D2core, SmartContent synchronises the meta-data with the configuration in D2.
Document type consolidation
All the Documentum client applications before D2 are using the internal Documentum data dictionary. This data dictionary is not directly maintainable and was historically created and/or defined using the deprecated Documentum Application Builder.
Attribute labels in D2 don’t have to come from the Documentum data dictionary anymore. D2 does respect the attribute label from the Documentum data dictionary if no label is set in the D2 configuration, but with D2 and its own dictionaries, it becomes a lot simpler to present the correct label to the end user, even in a multi-lingual environment.
SmartContent helps extracting the Documentum data dictionary values and using them to populate the D2 attributes so that they match the values in the D2 dictionaries.
For example, we have an attribute smw_language that contains language names (English, French, German, etc.). There is a dictionary with keys that maps abbreviations for languages to their names, such as “en” for English, “fr” for French and so on. It is now possible to transform the value of smw_language into the key value of the dictionary and store the result for example in an attribute smw_lang.
Dictionaries: from internal Documentum dictionaries to D2 dictionaries
All the Documentum client applications before D2 are using the internal Documentum data dictionary. This data dictionary is not directly maintainable and was historically created and/or defined using the deprecated Documentum Application Builder.
Attribute labels in D2 don’t have to come from the Documentum data dictionary anymore. D2 does respect the attribute label from the Documentum data dictionary if no label is set in the D2 configuration, but with D2 and its own dictionaries, it becomes a lot simpler to present the correct label to the end user, even in a multi-lingual environment.
SmartContent helps extracting the Documentum data dictionary values and using them to populate the D2 attributes so that they match the values in the D2 dictionaries.
For example, we have an attribute smw_language that contains language names (English, French, German, etc.). There is a dictionary with keys that maps abbreviations for languages to their names, such as “en” for English, “fr” for French and so on. It is now possible to transform the value of smw_language into the key value of the dictionary and store the result for example in an attribute smw_lang.
Lifecycle: from the Documentum lifecycle to the D2 lifecycle
The Documentum lifecycle is an object, and the link between a document and the lifecycle is stored in two attributes, the id of the lifecycle and the state of the lifecycle in which the document currently is.
D2 on the contrary does not know the concept of lifecycle objects. Lifecycles are defined by the states they have and what happens if a document moves from one state to another. A document is attached to a lifecycle if there is a match between the document and the lifecycle in the D2 configuration matrix, i.e. if the document fits within any of the D2 contexts that are connected to a lifecycle.
SmartContent is used to “translate” the information duplet (object id of the lifecycle and current status) into the information that the D2 configuration needs to assign the correct lifecycle definition. By default, this is done using the standard application attribute a_status but any other attribute can be used for this purpose as well.
For example, in WDK there is a lifecycle with id ‘4600112233440011’ and the following statuses:
- Draft value 0
- Review value 1
- Final value 2
- Published value 3
- Archived value 4
and in D2 a lifecycle has been defined based on the attribute a_status that can have the following values:
- Draft
- Review
- Published
- Archived
then SmartContent can be used to update the attribute a_status based on what is in the attribute r_policy_id and r_current_state of the document.
NOTE: setting the attribute a_status to a new value does not mean that all “change state tasks”, as they are defined in D2-Config, are executed as well. If this is needed, it will have to be done with a custom plugin that is executed after the attribute change.
Metadata normalization / standardization
If pick lists have not been implemented in a WDK application, and the user has a free text field to put his text, then it is likely that all sorts of variations for the same information occur in the repository. With D2 it is really easy to use dictionaries or DQL queries to assign a pick list to an attribute and to ensure that data consistency is better in the future.
For the legacy data, however, a metadata normalisation or standardisation needs to be performed, so that the old documents also match with the pick lists as defined in D2. SmartContent offers this functionality, especially because it allows the usage of regular expressions to do complex replacements, but also value maps that can “translate” multiple different values into one consistent value.
For example, if the language attribute in WDK was a free text field, then the language “English” could be spelled in all sorts of variations of spelling and language:
• English
• English
• Englisch
• Anglais
• E
• En
• EN
• …
All these values can be mapped to a single value, for example “en”. SmartContent will identify all the different variations and replace them with one single consistent value.
Data clean up
Data cleanup is not a typical WDK topic; it applies to all applications and it is something that is easily forgotten or neglected. The data clean up that is referred to here is not the disposal of documents that are no longer needed, but the cleanup of the meta data that go along with the documents.
With SmartContent data clean up does not have to be done within the IT department. On the contrary, the simple set up of SmartContent allows end users with an understanding of the data model to do the cleanup themselves, without help from the IT department.
The previous section “Metadata normalization / standardization” already gives an example of such a cleanup exercise.
Another clean up exercise could be to remove typical spelling mistakes, misspelled names of people, but also the re-categorization of the metadata. There are numerous examples, a couple of them could be:
- An organizational unit gets a new name
- A product gets a new description
- A project code is changed
- A person changes his/her name
- Abbreviations are replaced with the full text or vice versa
