Axway Composer > Working with objects > Managing revisions -Transfer CFT & Messaging > Rules for managing revisions

Rules for managing revisions

As described in Revision management and object dependencies, Composer must maintain coherence between object revisions and their object dependencies. Whatever action you perform on an object, you must always be able to return to a previous configuration. The management rules described here are designed to ensure coherence and avoid a situation where a previous object organization is irretrievable:

Rule 1: Object revision names

The object revision function enables you to create several instances of the same object. Each new object revision has the same name as the original, but also has a revision name, or tag,that uniquely identifies it.

For example: MyObject_[1], MyObject_[2] and so on.

When an object has at least one revision, its original name (MyObject) is no longer modifiable. The object is then identified by its name and its revision name (or tag). Composer checks that the name/revision name couple is unique in the database.

Rule 2: Only one revision of an object can exist on the Axway Server

When you send objects to Server, the relationship between the various object revisions must remain coherent on the Axway Server.

In the following example, you cannot send object C[1] to Server on the same Axway Server as object A[1]. A[1] uses B[1] and C[1] uses B[2], so two revisions of object B would be on the same Axway Server.

To overcome this constraint, Composer:

 

Rule 3: Deleting object revisions

You cannot always delete object revisions if they are used by other objects.

In the following example, a new revision of object B[1] was created - B[2] with the status Checked.

In this example, you cannot delete object B[2] because object C would no longer be linked to any object.

 

 

Rule 4: You can only modify the most recent revision

If several revisions of the same object exist, only the latest revision can return to Checked status. Any previous revision that you replace on a Server is Archived.

This means that you can only modify the most recent revision.

For example:

Action

Result

Send A[1] and B[1] to Server

Objects A[1] and B[1] are CommittedCommitted icon on a Axway Server.

Create new revisions of A[1] and B[1]

New revisions A[2] and B[2] have the status Checked Object checked iconand are modifiable in Composer.

Send A[2] to Server on a different Axway Server from A[1]

A[1] and B[1] are CommittedCommitted icon on one Axway Server

A[2] and B[2] are CommittedCommitted icon on another Axway Server

Remove A[1] and B[1] from the Server

A[1] and B[1] are no longer Committed. However, because they are not the most recent revisions, their status is set to Archived Archived icon(and not Checked).

Remove A[2] and B[2] from the Server

A[2] and B[2] are no longer Committed. Because they are the most recent revisions, their status is set to Checked Object checked iconand they are modifiable in Composer.

 

Tip: Use the Server Browser to check which objects are on each Axway Server.

Rule 5: You can only create a new revision based on the most recent revision

The current version of Axway Composer does not manage parallel versions of an object.

This means that you can only upgrade the most recent revisionof the object. You cannot, for example, upgrade a previous revision from the History Browser. You can, however, use the History Browser to send a previous revision back to Server.

 

Single version of an object