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:
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.
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:
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.
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 Committed on a Axway Server. |
Create new revisions of A[1] and B[1] |
New revisions A[2] and B[2] have the status Checked and are modifiable in Composer. |
Send A[2] to Server on a different Axway Server from A[1] |
A[1] and B[1] are Committed on one Axway Server A[2] and B[2] are Committed 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 (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 and they are modifiable in Composer. |
Tip: Use the Server Browser to check which objects are on each Axway Server.
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.