Working with Message Definitions

The File Manager is used to manage message and mapper definitions and all other files used to configure Rhapsody routes and communication points. It provides a single location where these files may be viewed and modified.

Adding a Definition to the File Manager

To add a definition to the File Manager, click the Add button to open the Add Existing Definition dialog to locate and select an existing definition file to add to the locker of your choice. Alternatively, click the arrow to the right of the Add button to display the EDI submenu from which you can:

• Add Existing Definition - open the Add Existing Definition dialog to add an existing definition file.
• New EDI Definition - launch the EDI Message Designer to create a new message definition.
• New Mapping Definition - launch the Map Designer to create a new mapping definition.

Adding a definition to the File Manager copies the definition file to the Rhapsody engine and to the user's local definition store (therefore, do not attempt to add definition files from your local definition store). When a definition is initially added, it is automatically checked out to the current user and other users can open a read-only version of the file. The message definition will not become active until it, and its associated route or communication points, are checked in.

Editing Message Definitions

Often a message definition must be changed as a result of changes to the structure of the messages it describes. This is especially important for non-standard message formats that develop along with the system, or for custom formats created to satisfy the specific needs of an organization.

If a user wants to modify a message definition, they must 'check out' the message definition. The definition is flagged as being checked out to that user and cannot be modified by any other users.

When a definition is checked out, the copy of the file held in local storage is overwritten by the copy held on the engine. Any associated Rhapsody routes or route components do not have to be stopped for this to happen, which means the engine can continue processing messages while the modifications are being made. When all changes have been completed, the definition is checked in and the definition file held on the engine is overwritten by the version from local storage. Again, nothing needs to be stopped for this to happen, so the route immediately starts processing messages with the new definition once checking in is complete. Checking in also releases the lock on the definition file so other users can check it out.