X

Technical info and insight on using Oracle Documaker for customer communication and document automation

  • December 17, 2015

Resource Management Practices with Documaker

Andy Little
Technical Director

In this post I aim to unleash a great deal of information on resource management practices and procedures as well as configuration with respect to Oracle Documaker. Most of this information is interchangeable between Standard and Enterprise editions. In Documaker 11.5 and newer, document template resources are
stored in a set of tables collectively called the Master Resource Library, or
MRL.  The MRL houses the resources in a
proprietary compressed storage medium that resides within the MRL tables stored
in the database. In addition, the MRL also stores metadata about the resources.
Resources are version-controlled and can be tagged with metadata elements to
categorize and segment according to implementation-specific criteria. Library
Manager is the name for the management structure around the library resources –
and is an integral component of the integrated development environment used to
author and manage resources in the MRL (Documaker Studio).

Library
Configuration Types and Table Names

There are two possible configurations of Library Manager
resource libraries - database and file-base. Note that for ODEE, the database
model is the only model allowed, however file-base models can be used for
development environments where ODEE is not used[1]. In the
database model, the MRL tables are stored in an ODBC-compliant database. The
tables generally feature a standard naming convention (libraryname_table) as
shown in the table below, however the name of the tables can be anything that
suits corporate standards. The default name prefix for MRLs used with Oracle
Documaker Enterprise Edition (ODEE) is DMRES.

In the file-based model, this same information is carried in a
set of 3 files, all with the same filename (e.g. MASTER) and different
extensions (.MDX, .LBY, and .DBF). The table below shows the tables/files and
their purpose.

Name Prefix

Name Suffix/Extension

Purpose

DMRES

LBYI

LBYC

LBYD

Index

Catalog

Data

MASTER

MDX

LBY

DBF

LOG

Index

Data

Catalog

Change Log

Schemas
and Assembly Lines

A typical ODEE footprint encompasses multiple environments (e.g.
Development, Test, Performance, DR, Production, etc). Each of these
environments is connected to a data tier that contains a database. The database
contains two schemas, which may be named using any convention desired. The
default schema names are DMKR_ADMIN, which houses system tables for ODEE, and
DMKR_ASLINE, which houses the ODEE processing tables

ASLINE is shorthand for “Assembly Line”
which roughly corresponds to the single MRL. It should be noted that certain
ODEE components have a 1:1 relationship with an Assembly Line, such as
Documaker Web Services (DWS), Documaker Interactive (DI), Document Factory
(Factory), and Docupresentment (IDS). These components are tied to a single
Assembly Line. If multiple Assembly Lines are used, each must have a dedicated
instance of these components. Other components, such as Documaker Administrator
(DA) and Dashboard are used across Assembly Lines. It is possible, therefore,
to reduce the footprint of the enterprise installation by consolidating
multiple processing MRLs into single assembly lines where possible by creating
Business Definitions (represented by BDFs within the Library). There may be
additional requirements that stipulate the use of separate assembly lines.

Resource
Lifecycle

A typical resource lifecycle includes the following environments
and uses:

· DEV environment – where
resources authors/content developers use Documaker Studio to create or add
resources to the MRL. Unit testing of functional requirements satisfied by
development activities occurs in this environment.

· QA environment – where
quality assurance testers to validate the satisfaction of functional
requirements.

· UAT environment – where
testers to validate the satisfaction of technical and operational requirements.

· PROD environment – where
end-users to perform business operations.

Accordingly, the resources contained in the MRL must be promoted
between each of these environments in accordance with project management,
testing management, and standard operating procedures to ensure changed
resources are fully tested and satisfy requirements before being promoted into
the PROD environment.

Once a resource has been promoted beyond the DEV environment, no
further changes should be made to that version and revision of the resources -
all changes should result in a new revision and/or version. During the course
of developing a resource for initial implementation, there could be dozens of
revisions for a single resource - incremental check-ins by resource developers,
for example. Only the latest revision of a resource is necessary in production,
so for this reason it is recommended to collapse revisions upon promotion from DEV.
The management of the resource lifecycle is further augmented by the use of
Library Project Management. Prior to work with resource lifecycle, the
libraries should be configured.

Library
Setup

As mentioned previously, each library has a set of tables that
contain the resource data. In order to promote between the libraries, each
library must be defined to the user(s) who have access to perform
promotions.  The process of defining a
library can be done inside Documaker Studio - consult the Documaker Studio
Administrator Guide for additional details. The following instructions will
explain how to configure a users
installation for multiple libraries using the INI files. This will allow you to
copy the configuration from one machine to another if you have multiple users
to configure.  Two important points to consider:

· Do not place library configurations into a user’s
INI files if that user should have access to the library or environment.

· These same configurations can be used for
creating INI files for automated deployment using LBYPROC/LBYSYNC.

1. Locate the FSISYS/FSIUSER INI files for the users workspace. Typically these files are found in
c:\fap\mstrres\dmres, however each installation can be different. These changes
can be placed in either file, however it is best to open both and locate the
existing control groups and settings where possible.

2. Create the library section. The name of the
library should match the LBYI (library index table) name - see the special note
at the end of this section for table name conversion.

< Library:UAT _DMRES>

                        ;the following values
(right side of =) must be defined!

                        CATALOG         = UAT_LBYC

                        DBTable           = UAT_LBYD

                        LBYLogFile      = UAT_LBYL

                        USERFile         = UAT_USER

3. Create the DBTable
definitions for the previous settings. Note that the value of the <DBTable:xxxx> should match the corresponding table in
the database (e.g. UAT_DEVC might actually be UQY0_DMRES_DEVC, so the control group would be <DBTable:UQY0_DMRES_DEVC>). If the names are the same
across all environments, see the note after this section.

<
DBTable:UAT_USER >

    DBHandler               = UAT_DB

    DefaultTag               = UNIQUEIDTAG

    UniqueIDTag           = UNIQUEIDTAG

    UniqueTag               = IDTAG

<
DBTable:UAT_LBYC >

    DBHandler               = UAT_DB

    UniqueTag                = CATALOGID

<
DBTable:UAT_LBYD >

    DBHandler               = UAT_DB

    DFD                             = DEFLIB\carfileora.DFD

    UniqueTag                = ARCKEY+SEQ_NUM

<
DBTable:UAT_LBYL >

    DBHandler               = UAT_DB

    UniqueTag                = DATE+TIME

<
DBTable:UAT_DMRES >

    DBHandler               = UAT_DB

4. Create the DBHandler
section. This is used and referenced by the DBTable
sections. Encrypt[2]
the connection settings so users do not gain access to resources outside of
Studio or the command-line tools.

< DBHandler:UAT_DB >

       AlwaysSqlPrepare = Yes

       Class      = ODBC

       CreateIndex =
No

       CreateTable =
No

       Debug    = No

       PassWd   =
~ENCRYPTED xxxxxx

       Server   = ~ENCRYPTED xxxxxx

       SubClass =
ORA

       UserID = ~ENCRYPTED xxxxx

5. Add the library to the <LibraryManager>
section. The name used here needs to match the <Library:XXX>
name you have created.

            <
LibraryManager >

                                    Library
= UAT_DMRES

By default, the table names listed in <DBTable:xxx> are used to match table names in the
database - so if the names shown in the <DBTable:xxx>
do not match, add the conversion section below.

6. Repeat these steps for all environments this
user should access.

Note - if your database schema uses the same
table names across environments (e.g. DEV uses DMRES_LBYC, and QA uses DMRES_LBYC
then you must use a special
conversion section and nomenclature for your INI settings. The < ODBC_FileConvert > section is used to provide internal conversion of table names. The
left side of the notation is the table name used in the INI, whereas the right
side is the database table name. Use this table to create internal conversions
so naming of your tables does not get confused in the INI settings. Note that
the “LBYI” table is used as the main library table.
Then, in your settings shown above, use the environment-specific INI name
defined here.

< ODBC_FileConvert >

            ;INI
NAME = DB NAME

            DEV_DMRES    = DMRES_LBYI

            DEV_FLDB                   = DMRES_FLDB

            DEV_USER                  = DMRES_DMUSER

            DEV_LBYC                   = DMRES_LBYC

            DEV_LBYD                  = DMRES_LBYD

            QA_DMRES    = DMRES_LBYI

            QA_FLDB                     = DMRES_FLDB

            QA_USER                     = DMRES_DMUSER

            QA_LBYC                     = DMRES_LBYC

            QA_LBYD                     = DMRES_LBYD

            UAT_DMRES    = DMRES_LBYI

            UAT_FLDB                   = DMRES_FLDB

            UAT_USER                   = DMRES_DMUSER

            UAT_LBYC                   = DMRES_LBYC

            UAT_LBYD                   = DMRES_LBYD

            PRD_DMRES    = DMRES_LBYI

            PRD_FLDB                   = DMRES_FLDB

            PRD_USER                   = DMRES_DMUSER

            PRD_LBYC                   = DMRES_LBYC

            PRD_LBYD                   = DMRES_LBYD

At the end of this configuration, the user will now be able to
promote between the libraries defined in these INI settings, using either
Studio or command-line tools.

Promotion

This section discusses non-Library Project Management (LPM)
promotion. For information on LPM Promotion, please proceed to the Library
Project Management section.

Typically, increasingly strict governance surrounds the
promotion process as resources move upwards to production. Usually only trusted
gatekeepers are allowed to push resources to production, whereas developers
usually have free reign to push resources from DEV to QA environments.

Resource promotion can happen in several ways using a different
combination of methods and configurations. The following list illustrates some
of the common configurations used. There are two methods for executing
promotions - Studio-based or command-line based. Studio-based promotion
provides a user interface for selecting resources for promotion and executing
the promotions. The command-line promotion provides a utility to define
resource selection criteria and execute promotions. Note that the Studio-based
method actually invokes the command-line tool to perform promotions, so each
method has the same functionality. The command-line tool may be preferred
because it can be automated.

· Studio-based promotion into all environments -
in this method, one or more Studio installations are configured with access to
libraries for promotion. This method is considered to have the highest ease of
use.

· Studio-based promotion into interim format - in
this method, one or more Studio installations are configured to promote from
one environment into a local, file-based MRL. The file-based MRL is then
transferred to the target environment and then promoted locally into the
database MRL. This method is generally considered to be more secure by
preventing Studio users from accessing non-development libraries.

· Command-line based promotion into all
environments - in this method, a Documaker installation is configured with the
appropriate libraries, and the promotion is done via command-line.

· Command-line based promotion into interim format
- this method is the same as the Studio-based promotion into interim format,
using command-line tools.

There is a final possibility and that is for Studio users to
generate Library Script Control (LSC) files which defines the resource
migration properties (e.g. which resources to migrate, source and target
properties, etc). This script can then be used with the command-line utilities.

The promotion process works in this fashion:

1. Identify resources for promotion - in this step
resources are identified for promotion. This can happen in a number of ways. If
the resources are already classified (for example by Project) then the user can
easily filter the library by project name. Otherwise the user can select the
resources individually from the library.

2. Set target library - this is simply selecting
the target library to receive the resources.

3. Set target classification properties - this sets
the properties of the promoted resources in the target library.

4. Set source properties - this sets the properties
of the promoted resources in the source library.

5. Execute/Preview - this performs the promotion
and sets the properties as noted, or previews what the promotion will do.

Promotion
Steps

1. Prior to initiation a promotion, the user should
delete the MASTER.* library files from the local machine - this step is only
used if the “interim files” option is used.

2. User logs into Studio - user must have Library
Manager and Perform Promotion rights.

3. User opens Libraries, selects source library.

4. User clicks Promote from the Library menu tab.

5. User selects appropriate resource(s) to be
promoted, or can open an existing Library Script which has been saved from a
previous promotion. The Library Script can identify the resources to be
promoted and can be saved and executed multiple times.

6. User selects the appropriate target library (“MASTER”
if using the interim files option)

7. User selects appropriate promote commands (e.g.
Promote Selected Files Only and/or Include Descendants in Promote)

8. User commits promotion.

If using Interim files option, the user can then take the
MASTER.* library files and copy to the target environment in the documaker/mstrres/dmres/deflib directory, and then run the documaker/mstrres/dmres/deploysamplemrl.sh script to migrate
resources from the interim file into that systems library.

Library
Project Management

Library Project Management (LPM) was introduced in Documaker
Studio 12.0 to facilitate management of resources using concepts borrowed from
the software development life cycle model. Using LPM means that access to
resources can be tightly controlled based on roles, and assures that resources
cannot be migrated to downstream tiers (libraries) without approvals. All LPM
functionality is built within Documaker Studio. For reference, refer to the Documaker Studio User Guide, page 349.

Tiers

LPM uses the concept of tiers to correlate a repository of resource library tables in a
given environment with a logical development phase. Each tier has a set of
tables that reside in the database, as well as a directory present in the
Documaker Studio workspace (either on the local users workstation or in a network location if using
shared workspaces). A tier is assigned a category that characterizes the
tier according to its function. An implementation can have any number of tiers
of any category, but must have one DEV tier, which is required. Generally it is
recommended to have a tier established for each environment.

Roles

There are multiple roles that persons can fulfill within the
workflow of form generation and development. It is possible that a single
person could perform multiple roles and the system supports this. Note: these
roles correlate to use of LPM, some roles could be consolidated (e.g. Reviewer
and Tester).

Role

Description

Developer

Creates/edits resources

Reviewer

Reviews and approves changes to resources

Tester

Validates functionality resources

Administrator

Administers the LPM system configuration

Performs promotions between tiers

Classifications

An MRL resource can have one or more metadata[3] elements
defined and assigned to it. Documaker Studio provides four metadata elements,
called classifications, and each element can have many possible values
defined. The classification of resources, or tagging, is paramount for proper library management. Refer to
the Documaker Studio guide page 487 for information on how to configuration
classification properties. These properties are configured to provide
selectable values that a user may choose from when editing resource
information. Remember that these are only recommendations; properties can be
defined according to business requirements - however when LPM is used, some of
the properties take on special meanings. The available properties of
classification are:

Classification

Description

Action

This property is used only when LPM is enabled. The Action
property specifies the activities that a user may perform with the resource.
When the Action is performed, the status of that resource is changed.

Mode

This field could specify where in the development cycle the
resource is. The recommended usage is to correlate Mode to the environment or
tier (e.g. DEV, TEST, PROD). In LPM, the Mode is used to categorize resources
into tiers to determine what actions are available.

Status

This field could indicate whether a resource has passed or
failed testing. Recommended values are TEST, PASSED, FAILED. In LPM, the
Status indicates the last action performed on a resource.

Class

This field could indicate a large grouping of similar
resources that share a common functionality or usage (some uses are to
organize by state/province or business function).

Project

This field could indicate a smaller sub-grouping of resources
that can span classes and are correlated by business purposes. The
recommended use is to create project values that are synonymous with change
management (e.g. all resources for “Project 001”
are grouped together for migration).

State

This property is only used when LPM is enabled. The State
property is a combination of tier, mode, and status and determines which
roles have access to the resource and what actions can be performed on the
resource.

Securing
Resources

Roles are used to collect specific rights and functions within
Documaker Studio when LPM is used in a library. A user is assigned one or more
roles by a user with Administrator capabilities in Documaker Studio. Note that
this role configuration is wholly separate from Entities and Ability Sets used
by Documaker Interactive (DI) - recall that DI is a product targeted for use by
end users, whereas Documaker Studio is purely for resource developers and
administrators.

The recommended security settings by role are shown in the table
below. Refer to the Documaker Studio Administrators Guide pages 84-87 for additional details,
including additional settings required for LPM.

Role

Authorizations

Developer

Full Access on all Manager rights, except Deployment Manager

Reviewer

View Only Access on all Manager rights except Deployment
Manager

Tester

View Only Access on all Manager rights except Deployment
Manager - note this may need to be modified to allow the tester to adjust
resource classifications using the “Limited Property
Modifications” right.

Administrator

Library Administrator rights - performs promotions. Can
selectively give certain users rights to perform promotions using the “Limited
Property Modifications” and “Perform Promotions”
rights.

It is possible to secure specific resources to a user, so only
that user can change the secured resource. To lock specific resources by user
ID, see the Enabling Securing Resources in the Documaker Studio User
Guide, page 90.

Promotion

The following steps outline the basic workflow of the LPM
lifecycle, and how users in specific roles interact with LPM.

Dev Environment

In the DEV tier, Developers and/or Administrators perform the
following functions:

· Identify resources to be created or modified
pursuant to business requirements.

· Determine appropriate classification value (e.g.
Project classification = “BR101.3”)
to be used for the development effort.

· If necessary, create any classification values
needed.

In the DEV tier, Developers perform the following functions:

· Create or modify resources according to business
requirements or test results.

· Assign classification values to resources (e.g.
PROJECT value)

· Unit test all resources created or modified for
the Project classification.

· Identify all required components for promotion.
Studio can help in this regard - e.g. if a form is being promoted that has a
new section added, it will, if requested, automatically select the applicable
section(s). However if a section has a field that is defined in the XDD, Studio
will not automatically select the XDD – the developer must know
what resources have changed.

In the DEV tier, Reviewers perform the following functions:

· Validate that all resources set for promotion
are ready and feature complete.

· Notify Administrators to perform promotion of
specific resources.

In the DEV tier, Administrator performs promotion in the
following steps:

1. Select all resources identified for promotion.
The selection criteria can be saved to an external file for re-use. This file
is called library script file and typically uses the extension LSC.

2. Set Target Library = QA.

3. Set classification properties

a. Target Mode = TEST

b. Target Status = TEST

c. Source
Mode = DEV

d. Source
Status = PROMOTED

e. Target Project = Source Project

4. Select “Promote Selected Files
Only”

5. Select Include Descendants in Promote to include
child resources (e.g. forms
sections) - this step is optional, but remember to include ALL required
resources in promotion.

6. Click Preview to see intended results of
promotion.

7. Click Promote Now to perform promotion - Studio
will promote the resource from the source to the target and update the
classification properties of the resources in each environment as
necessary.  Note that the settings of the
promotion can be stored to an external Library Script Control (LSC) file and
repeated. The LSC file can also be used to execute the promotion using a
command line tool from the server environment.

8. Open the target Environment to ensure resources
promoted successfully.

QA Environment

In the QA tier, Testers perform the following functions:

· Validate functionality of the resources
introduced by the promotion set.

· If any resources fail tests…

o Set
classification property STATUS = FAILED for those resources.

o Revert
to developer to correct issues and follow promotion path. Resources of the same
promotion set should not be promoted until all resources pass.

· If all resources pass tests…

o Set
classification property STATUS = PASSED for all resources.

o Notify
Reviewers of readiness of promotion set. Classification properties are updated.

In the QA tier, Reviewers perform the following functions:

· Validate that all resources set for promotion
are ready and feature complete.

· Notify Administrators to perform promotion of
resources in the promotion set. Classification properties are updated.

In the QA tier, Administrators perform promotion in the
following steps:

1. Select all resources identified for promotion.

2. Set Target Library = UAT.

3. Set classification properties

a. Target Mode = UAT

b. Target Status = TEST

c. Source
Status = PROMOTED

d. Target Project = Source Project

e. Select “Promote Selected Files
Only”

f. Select Include Descendants in Promote to include
child resources (e.g. forms
sections) - this step is optional, but remember to include ALL required
resources in promotion.

g. Click Preview to see intended results of
promotion.

h. Click Promote Now to perform promotion.

i. Open the target Environment to ensure resources
promoted successfully.

UAT Environment

In the UAT tier, Testers perform the following functions:

· Validate functionality of the resources introduced
by the promotion set.

· If any resources fail tests:

o Set
classification property STATUS = FAILED for those resources.

o Revert
to developer to correct issues and follow promotion path. Resources of the same
promotion set should not be promoted until all resources pass.

· If all resources pass tests:

o Set
classification property STATUS = PASSED for all resources.

o Notify
Reviewers of readiness of promotion set. Classification properties are updated.

In the UAT tier, Reviewers perform the following functions:

· Validate that all resources set for promotion
are ready and feature complete.

· Notify Administrators to perform promotion of
resources in the promotion set. Classification properties are updated.

In the UAT tier, Administrators perform promotion in the following
steps:

1. Select all resources identified for promotion.

2. Set Target Library = PROD.

3. Set classification properties

a. Target Mode = PROD

b. Target Status = PROD

c. Source
Status = PROMOTED

d. Target Project = Source Project

e. Select “Promote Selected Files
Only”

f. Select Include Descendants in Promote to include
child resources (e.g. forms
sections) - this step is optional, but remember to include ALL required
resources in promotion.

g. Click Preview to see intended results of
promotion.

h. Click Promote Now to perform promotion.

i. Open the target Environment to ensure resources
promoted successfully.

PROD Environment

Resources here are in production mode and no changes should be
made to their revision and version numbers.

Configuring
a Workspace for LPM

This action should be taken on a single users system first - it will configure the system to
use LPM. Changes should then be copied into each users system to ensure that all users are configured
with the same LPM settings. A workspace must be enabled for LPM before it can
be used with LPM. To enable LPM, follow these steps:

1. Open Documaker Studio and select ManageàSystemàSettings
(or click the Settings button if youre
using the Ribbon bar).

2. Select Workspace Information and check Projects
Workspace, then click OK.

3. Open Documaker Studio and select ManageàSystemàSettings
(or click the Settings button if youre
using the Ribbon bar).

4. Click Libraries. Use tabs to review Modes,
Status codes, Classes, and Projects. Recommend Modes and Status codes remain
as-is. Define Classes and Projects as necessary – these are just ways to
categorize resources. Class could be used to correlate all resources for a
geographical region, for example. Project is usually used to correlate
resources across classes for a particular business objective (such as a new
product for all regions).

5. Click Library Tiers. Tiers are organized by type
(types are listed in the Tier section). The Types are shown below –
the first tier is a DEV tier called “001 –
Development”. This tier is

created automatically and cannot be deleted or edited. You can create any
additional tiers here – you can of course opt to not create all tier
types (for instance you can omit model office if you do all testing in system
testing, as long as you ensure adequate testing is performed before promoting
to production).

6. Click
“Create
Tier”.
Enter the details about the new tier.

a. Type – the type of tier (DEV,
UNIT, etc).

b. Path – the parent path of the
location where the tier configuration files

are stored – these are workspace-specific.

c. Tier Location – the folder inside the
Path location named for the tier

where the configuration files are stored. Recommended naming

convention is [library name]_[tier type].

d. Database Connection – enter
the details about the database connection. The tier can reside in the same
database[4]
as other tiers, but will require a different naming convention. The suggested
convention is [library_name]_[tier_name], e.g. DMRES_DEV or DMRES_UAT.

e. Library
Name
– it is recommended that it stay the same as the
library name defined previously.

f. ODBC Data source – click and select or
create the data source to your database where the library will be created. If
you are using the same database for the tier you are creating as an existing
tier, select an existing data source and provide the login credentials.

g. The file names can stay as they are shown. These
are automatically generated based on the library name.

h. Use Generate DDLs to create the DDL for a DBA to
use for creating the tables.

NOTE: if you are creating a tier that will be accessed by Document Factory and
the database is Oracle, please note: the “LBYD”
table DDL needs to be adjusted – the CARDATA column is
defined as RAW(1954) but needs to be changed to BLOB before committing the DDL.
Before committing any resources to the library, you must change the
carfileora.dfd present in the deflib directory. Open the carfileora.dfd in a
text editor and change the < FIELD:CARDATA > as
shown:

<
FIELD:CARDATA >

EXT_LENGTH = 8

EXT_TYPE   = BLOB

INT_LENGTH = 8

INT_TYPE = BLOB

KEY=N

REQUIRED=N

BLOB =N

If the change to the DFD is not made before the finalization of
the library creation, Studio will create default resources and add them to the
library –
these resources must be deleted and recreated after the DFD has been changed.

7. Click Next, then Finish. You can create
additional tiers. Click OK when done.

Assigning Roles – use this to assign users
to one or more LPM roles.

1. Open Documaker Studio and select ManageàSystemàUsers
(or click the Users button if youre
using the Ribbon bar). You will need to have the User Administrator or System
Administrator role in order to access this function.

2. Select a user and click Configure.

3. Select Projects and then add the desired role(s)
to the user, then click Ok.

4. Repeat for all users who will participate in
LPM.

Working
with LPM

Once you have resources loaded into projects, you can start
working with LPM. Note: If you want to strictly adhere to the LPM approach,
only perform actions on resources within the Projects manager. Managing
resources outside of Projects manager with a tool such as Library manager can
result in the status and mode combinations of resources becoming undefined,
thereby making the resources unusable by the Projects manager. Only
administrators should use the Library manager for other functionality. Open the projects manager, and then you can filter the list of
items shown in the project or perform actions on them.

Conclusion

Hopefully I achieved my goal of giving you enough information to help plan your resource management strategy. Questions and comments are welcome! 


Footnotes

[1] An example of this
would be a standalone development environment that is used for resource
development only and does not have an ODEE component.

[2] To encrypt settings,
use the command-line tool distributed with Documaker Studio cryruw32.exe. To run the tool, enter cryruw32 string_to_encrypt on the
command line. The resulting output can be pasted into INI files on Windows or
Linux platforms using the notation ~ENCRYPTED
encrypted_string

[3] Metadata means,
literally,
data about data. Metadata is information about an item.

[4] It is recommended
that production tiers do not reside in the same database or schema as
non-production tiers.

Join the discussion

Comments ( 3 )
  • guest Tuesday, December 22, 2015

    Andy, thanks for the great article! Regarding this statement:

    "Only the latest revision of a resource is necessary in production, so for this reason it is recommended to collapse revisions upon promotion from DEV."

    Could you clarify what you mean by that? Does this mean that only the latest revision should be kept in production? If so, wouldn't that hinder us from using the MRL as a source management repository that can be audited?

    Thanks!


  • Andy Tuesday, December 22, 2015

    I suppose that could be a little confusing, so let me clarify. Normally during the resource development process there could many check-outs/check-ins, which result in many extra revisions that aren't needed. You can collapse these revisions to eliminate additional unnecessary revisions in the library. The idea is that you'll only keep the revision(s) you intend to promote from development to test. If however you absolutely need to keep every revision made (even those revisions that are not promoted up to another environment) then you can of course do so.

    -A


  • Joe Hays Thursday, March 22, 2018
    Good article - better than the documentation. Question - Receiving the error message "Did not promote resource with same modification date..." in one of our test environments. We are using an LSC file to handle the promotions so these members keep showing up on every promotion. Is there a way to delete them?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.