transition Command

transition [TRANSITION_ITEM];

• TRANSITION_ITEM can be one of the following:

  Transition Item	Description	For More Information
  attribute	Copies or converts the existing values for an attribute to values for another attribute. This command modifies the attribute, it does not create a new attribute.	Transition Attribute
  cestamp	Updates the cestamp for specified attributes.	Transition cestamp
  changesov	Changes the Secondary Ownership Vector (SOV) for policies. For more information, see .	Transition ChangeSOV
  dynamic-relationship	Mutates existing PLMInstance relationship types and instances to be dynamic relationships.	Transition Dynamic-Relationship and MQL Concepts: Dynamic Relationships
  interfacerulesflag	Updates the cInterfaceRulesFlag on business objects.	Transition Interfacerulesflag
  relationship	Changes a relationship into a pathtype.	Transition Path Relationship
  path split	Changes the pathtype based on an existing pathname and two matching attribute/value pairs.	Transition Path Split
  project_org	Updates the project and organization for all objects governed by specified policies.	Transition Project_Org
  published-flags	Fixes the published/best-so-far bits in the mxIdent or lxRev field based on the state of the object.	Transition Published-Flags and MQL Concepts: Published States
  relationship	Changes the relationship type of an existing connection to another relationship.	Transition Relationship
  revisions	Creates major versions from existing data that has been mapped to minor revisions by the upgrade command.	Transition Revisions
  updatestamp	Updates the values of the updatestamp for an attribute.	Transition Updatestamp

transition cestamp ATTRIBUTE_NAME;

CEStamp (Concurrent Engineering Stamp) implements optimistic offline lock, a method to prevent conflict between concurrent transactions by detecting a conflict and rolling back the transaction. When you have the cesstamp value, you can pass it to a program to validate a modification.

The changesov access allows a user to change explicit SOV or inherited SOV access.

The MQL syntax for the Transition ChangeSOV command is:

transition changesov policy POLICY_NAME {POLICY_NAME};
transition changesov access OLD_MAKS NEW_MASK SEARCH_CRITERIA {SEARCH_CRITERIA}

The transition changesov policy command lets you define the policies to be modified to add changesov access.

The transition changesov access command lets you change any accessbits except read and show on a set of objects identified by SEARCH_CRITERIA consisting of:

comment COMMENT {,COMMENT}...
policy POLICY_NAME {,POLICY_NAME}...
type TYPE_NAME {,TYPE_NAME},,,

The search criteria is met if the comment for a business object is in (comment1 OR comment2 …) AND the policy is in (policy1 OR policy2 …) AND type is in (typ1 OR type2 …).

You cannot use the transition changesov access command to add or remove read or show access.

Using this business object as an example:

business object t1 bo 0
    access[12920.19594.16848.60946|key2].access = changeowner
    ownership[org1|prj1|key1].access = read
    ownership[12920.19594.25120.26862|key2].access = changeowner
    ownership[12920.19594.1572.29463|key3].access = changeowner

Execute this transition command:

transition changesov access changeowner changesov,checkout comment key1,key2 type t1;

In this command, the OLD_MASK is changeowner, and the NEW_MASK is changesov,checkout. The comment is key1 OR key2, and the object type is t1.

The business object is evaluated because its type matches the type in the transition command. The access definition is not updated because the transition changesov command only affects explicit or inherited SOV, not access.

The first ownership definition, ownership[org1|prj1|key1].access, is not modified because its existing mask does not match the mask in the transition command ( read vs. changeowner).

The second ownership definition, ownership[12920.19594.25120.26862|key2].access, is modified from changeowner to changesov,checkout because both the mask and comment match the mask and comment in the transition command.

The third ownership definition, ownership[12920.19594.1572.29463|key3].access, is not modified because the comment does not match (key3 vs. key1 OR key2). The modified business object is modified:

business object t1 bo 0
    access[12920.19594.16848.60946|key2].access = changeowner
    ownership[org1|prj1|key1].access = read
    ownership[12920.19594.25120.26862|key2].access = changesov,checkout
    ownership[12920.19594.1572.29463|key3].access = changeowner

transition dynamic-relationship type REL_TYPE;

This command converts the administration definition of the relationship type, and also migrates all connections that are of that type. It toggles the dynamic bit on the MXRELTYPE entry. It also removes the data from LXRO and creates new data in LXDRO/ MXFAMILY to make those PLMInstances point to the now major versions.

transition path relationship RELTYPE ATTRIBUTENAME ATTRIBUTENAME ATTRIBUTENAME ATTRIBUTENAME 
ATTRIBUTENAME ATTRIBUTENAME filename FILENAME separator [SEPARATOR_STRING] recordseparator [SEPARATOR_STRING];

Or:

transition path relationship RELTYPE ATTRIBUTENAME ATTRIBUTENAME ATTRIBUTENAME ATTRIBUTENAME 
ATTRIBUTENAME ATTRIBUTENAME map TYPE_MAP_ENTRY;

• RELTYPE is the relationship to transform into a pathtype.
• ATTRIBUTENAME are attributes currently defined for the relationship to be moved to the pathtype. Only the attribute listed here are moved to the pathtype. Any other attributes on the relationship are not moved.
• FILENAME is a file that contains a list of relationships and their attributes to be transitioned to pathtypes.

  The filename option is used instead of supplying the list of attribute names. Use one method or the other, not both.

• SEPARATOR_STRING for the separator defines the separator between attributes, and for the recordseparator defines the separator between relationships.
• TYPE_MAP_ENTRY

  string string BusinessObject [TYPE_MAP_ENTRY]

  string string Connection

  string string Connection [TYPE_MAP_ENTRY]

For more information, see pathtype Command.

transition path split ORIGINAL_PATHTYPE NEW_PATHTYPE 
attribute ATTRNAME1 ATTRVAL1 ATTRNAME2 ATTRVAL2 ownertype 
TYPE kind businessobject|connection;

For any ORIGINAL_PATHTYPE , if the specified attributes have the specified values, then the Transition Path Split command transforms the ORIGINAL_PATHTYPE to the NEW_PATHTYPE. The Transition Path Split command ensures that the NEW_PATHTYPE includes all attributes of the ORIGINAL_PATHTYPE.

The ownertype defines the name of the type or relationship, and the kind clause defines whether that type is a business object or a relationship (connection).

The Transition Path Split command will not create the new pathtypes and will throw an error if the pathtype referenced in the command does not exist. The mxPathType table must be upgraded with any new pathtypes prior to running this command.

Examples:

transition path split SemanticRelation NewSR attribute Role 1 Semantics 3 ownertype t2 kind businessobject;
transition path split SemanticRelation NewSR attribute Role 1 Semantics 3 ownertype r2 kind connection;

transition project_org policy POLICYNAME [project PROJECTNAME] 
[organization ORGNAME] [!overwrite];

By default, the overwrite flag is false.

POLICYNAME can be a comma-separated list of policies. You cannot use wildcards to specify the policies. You can use the defaultproj and defaultorg keywords.

You can only define a single project (collaborative space) and a single organization. You can specify a single project AND a single organization, or a project OR an organization, but you must specify at least one project or organization.

This table describes the actions taken depending on the combination of parameters:

This command generates SQL statements. For example, if you specify this command:

transition project_org policy pol1,pol2,pol3 project defaultproj 
organization defaultorg

The generated SQL command is:

update lxBO_<latticesuffix> set lxLxaltown1=<defaultprojid>,lxAltown2=
<defaultorgid> where lxPolicy in (pol1_id,pol2_id,pol3_id);

The overwrite flag was not included, but is false by default.

transition published-flags policy NAME;

This command finds business objects governed by the specified policy that are in published states, sets the new bit in lxBO.lxFLAGS, and creates mxFamily entries for the business objects’ minor revision families.

transition relationship totype RELPATTERN;

This command changes the relationship type of an existing connection to the relationship specified by RELPATTERN. You can include the force option to force updates to the lxRO table.

transition relationshiptype from OLD_RELTYPE to NEW_RELTYPE set SET_NAME [size N];

Here OLD_RELTYPE and NEW_RELTYPE are the relationship type names. SET_NAME is the name of the set of business objects. size N is an optional parameter. If you define this parameter, the process is broken into chunks of size N instead of processing the entire set in one operation.

The following actions are performed.

• All relationships of type OLD_RELTYPE are identified in the set of business objects defined in SET_NAME.
• The identified relationships are changed to relationship type NEW_RELTYPE.
• Attributes that are in OLD_RELTYPE, but not in NEW_RELTYPE are removed.
• Attributes, with standard default values where appropriate, that are in NEW_RELTYPE, but not in OLD_RELTYPE are added.
• A history entry is added for the relationship type change.
• If the MX_CHANGE_CESTAMP environment variable is specified as true, the CEStamp is updated.
• If the MX_CHANGE_MODIFIED_DATES environment variable is specified as true, the modified date is updated.

The syntax for the transition revisions command is:

transition revisions policy NAME_PATTERN major;

This command allows the modification of a policy to add a major or minor sequence definition, and to update all business objects that are governed by the policy to update their policies.

The NAME_PATTERN argument can be either the name of a single policy or a pattern to specify a list of policies (either a comma-separated list or a wildcard pattern). When a pattern is specified, all policies matching that pattern are transitioned atomically. If during processing business objects are found that are in a policy that is not in the list specified by NAME_PATTERN, the command errors out and leaves the data untouched.

The command also modifies the access masks on all states to ensure that any access rule that specifies revise access is updated to specify both revisemajor/reviseminor access in the same way. It also examines access filters to determine whether they use the "revise" string to refer to an access. If so, it replaces this reference with "revisemajor" or "reviseminor."

Since the Transition Revisions command changes the revision string for the business objects in the specified policy, this would require an update of any unique keys (including mxTNR) and indices that contain the revision selectables. The Transition Revision command detects any such problematic unique keys and indices and refuses to work until these were explicitly disabled. You can use the additional force modifier, which when used indicates that Transition Revision should itself temporarily disable the unique keys and indices, run the transition, and then re-enable everything that was disabled. This ensures that unique keys and indices are kept in synchronization with the updates to the business object’s revision strings.

You can use transition revisions policy NAME_PATTERN major to convert a minor-only sequence into a major-only sequence.

transition updatestamp ATTRIBUTE_NAME;

The stamp value is a DCE UUID 16 byte ID used by applications to mark significant changes to the businessobject.

The dynamic relationship feature adds an additional requirement for the definition of the database user for Oracle installations: the user must now have Create View privileges.

Transition commands produce no history records. Apart from the fact that a policy is transformed in such a way as to give it a new majorsequence and a new minorsequence, there is no way to tell that the policy was migrated using a Transition command.