Messaging Workbench Compact Profiles
A Method for Implementing Library Based Inheritance Among Profiles
The ability to save profiles in compact form has been available in the MWB since its earliest releases. This optional file format was originally intended simply to reduce the size of MWB profiles. It is smaller in size because a compact profile inherits all element definitions from the specified constituent libraries; none of the element definitions are actually stored in the profile.
A consequence of saving in this format is that any changes made to the constituent segment libraries are automatically apparent in any compact profile that uses these libraries as the source of element definitions. In essence the compact profile ‘inherits’ from its constituent libraries. While implementation of inheritance was not the primary intent of the compact format, as it turns out, it is probably the most beneficial effect. It permits rapid update of a group or class of any number of profiles by making changes to the library only. Because of inheritance it is not necessary to open each profile in the class to make the corresponding change.
In earlier releases, the inheritance mechanism was very rigid. It was useful only if every element in every profile was exactly the same. This stricture applied to all attributes of all elements in the segment libraries. So for instance if a change was made to an implementation note for a particular field in the library, all compact profiles using that library would have the same implementation note for that field. This release eases that restriction to the extent that individual elements may have attribute values that differ from the library while inheriting the others. All public attributes (i.e. those that may be edited ‘Element Parameters’ section of the ‘Message Definition’ tab) may have values that differ from the parent library. The only exception is the data type attribute which must be the same as that in the library for all fields in the child profiles.
This inheritance mechanism in other words permits overriding of the basic element definition. As each compact profile is opened in the MWB its constituent elements are initialized to the state of the element in the parent library. Deviations or overrides to the library are stored is a separate section of the profile file and are applied over the library initialized element. This has an effect on the size of the profile that is directly proportional to the number of deviations from the library that must be maintained within the profile. While profile size will undoubtedly be greater with this modification, the consideration of profile size has assumed a backseat to ease of profile maintenance gained from the inheritance feature.
Keep in mind that compact profiles are incomplete without their constituent libraries. In other words, to share a compact profile for development purposes, both the profile and its constituent libraries must be given your partners. An attempt to load a compact profile in the absence of the parent libraries will result in a warning message, and the MWB will try to reconstitute the profile from available active libraries. In this case it will also change the profile status from compact to normal.
Note that this stricture only applies if you want to share the profile for editing or further development. You can always save a compact profile as a normal profile in which case it is a standalone unit that may be viewed and edited in the regular fashion, but will no longer actively inherit from the active segment libraries.
To create a Compact profile, you simply save it as a compact profile. This option is available on the File menu.
Saving a profile in a
compact state
To be effective though, application of the inheritance mechanism requires some initial planning and thought. The key to the inheritance mechanism is the selection of libraries. In most cases it would probably be prudent to create and use a project specific library or set of libraries for this purpose. Creating libraries is covered in other help articles and won’t be discussed here.
For example, an interface project that was centered onADT messages would probably employ a segment library of constrained ADT segments such as PID, PV1, NK1 etc. All of the compact profiles in the project could then inherit the constrained segment definitions as a baseline. Each profile could also maintain its specific character (e.g. notes, example values, value lengths etc). Whenever a change is made to these parent libraries, their corresponding child elements in all of the compact profiles in the project automatically inherit the change.
A couple of points of clarification are appropriate at this point. First there is nothing to preclude the use of the standard libraries as the parents of a compact profile. It can be done however since the standard libraries are not constrained, that chore would have to be done for each profile in the group, which defeats the productivity gains of the use of customized segment libraries as well as that of the new inheritance feature. Customized segment libraries significantly increase the productivity of individual profile development. The use of compact profiles extends these productivity gains to the management of libraries of related profiles.
Second, changes to a parent library will appear in a child profile only if the change does not affect previously overridden attribute values. For example lets assume that my library initially had a value of 100 for the length of PID.5.1, but I overrode the library value, making it 105 in my compact profile for ADT^A01. If I later change the library length attribute value for PID5.1 to 200, the value for that element in my ADT^A01 profile will remain at 105. In other words, local profile attribute values override library attribute values for any given element.
Finally, multiple segment libraries may be used as the basis of inheritance for a given group of profiles. In the example above, I might have employed a localized ADT segment library and an enterprise specific Z segment library. Keep in mind however that only one definition will prevail for inheritance purposes. In other words if there is overlap of segment definitions among the parent libraries, only the definition of the first encountered in the list will be used for inheritance. This is analogous to the library processing rules for regular profiles discussed elsewhere.
As mentioned above, creation of a compact profile is accomplished through the act of saving the profile. A compact profile is opened just as a regular profile is; either from the file menu or by double clicking on a ‘.mwb’ file. The MWB recognizes and distinguishes a compact profile from internal aspects of the file organization. An attempt to open a compact profile without the availability of its parent libraries will result in the following warning message:
Missing Compact Library
Warning
If on the other hand the parent libraries are available, then the profile will be loaded, just as a regular profile is. Once loaded a compact profile is only distinguished from a regular profile by the highlighted caption over the message tree. Otherwise it may be manipulated as a regular profile within the MWB.
Highlighted Message Tree
caption indicating loaded compact profile
As noted above though, data types may not be changed in child profiles. An attempt to do so will result in the following warning message:
Data type change restriction
message
When the profile modification session is complete and the profile is to be saved, an option to save the profile as compact or regular is presented.
Saving compact profile
Select ‘yes’ to continue saving the profile in compact form, or no to save it as a regular profile. Again, if you save it as a regular profile it will no longer inherit from the libraries and no longer requires their presence to be complete. The regular profile format is appropriate for sharing with interface partners that are not expected to make changes to the profile, or whose potential changes are of no concern to the issuing enterprise.
Again, the basis of the productivity gains with the use of compact profiles is the ability to make changes to just the library which then are inherited by all related profiles. The formal mechanism for making library changes involves making changes to individual profiles and then compiling the profile into the target segment library. This mechanism (details discussed elsewhere) is still in place. In support of managing compact profile libraries a more direct albeit less versatile method of library update is being introduced with this release.
The method involves a library maintenance feature existing in earlier releases (“Rebuild Lib from Segs”),
Creates a pseudo profile
from active segment libraries
and a new library maintenance feature “Create Lib from Current Profile”.
Saves the currently loaded
profile in the form of a segment library
The former feature permits treating an entire library (or set of libraries) as a pseudo profile which may be manipulated just as any message profile. The later feature saves this pseudo profile (or any other profile for that matter) as a segment library.
In combination these two library maintenance options are
intended to give the profile library manager a quicker and more direct way of
making incremental changes to the libraries used by compact profiles. Be aware
that the pseudo profile that is loaded represents all of the segment libraries
on the Active segment library list (accesable via the tool bar as discussed elsewhere).
If you intend to conserve the distinctive nature of each of the segment libraries (e.g. separate standard based library and separate Z seg library), then you want to be sure to restrict the active library list to just one segment library when you initiate the library edit session via this method. On the other hand if you wish to combine segment libraries into a single segment library, initiate the edit procedure with all segment libraries used in the project on the active segment list. The result of saving this pseudo profile will be a single segment library that incorporates the segment definitions from all of the active segment libraries. This later approach may be of benefit if you wish to manage a single project specific segment library as opposed to a collection of individual enterprise segment libraries.