Upgrading from Earlier Releases › Upgrading from CA Plex r5.1 › Case 1: Multiple Inheritance Call Resolution › Background

Background

CA Plex r3.5 introduced support for multiple function inheritance by changing the behavior of the FNC is a FNC verb. As a result, even existing CA Plex functions could inherit from more than one function without keying any extra triples. Another consequence of this was to allow two or more different inherited Calls triples to be Visible in the Object Properties corresponding to the same original action diagram call. Only one call is appropriate in any inheriting action diagram and CA Plex determines which of the available functions should actually be called when it is loaded.

Prior to r5.0, CA Plex did not explicitly handle such action diagram calls. As a result, the resolution of the call did not always follow the usual rules of the inheritance engine. At r5.0 and later a mechanism was put in place to handle such calls. This mechanism has been refined a number of times, most recently at r5.5.

Example 1: The Filter Pattern

A common example of multiple inherited action diagram call can be seen in instances of the Filter.FilteredGrid function. Consider these triples:

EditDetailFilter is a ENT STORAGE/RelationalTable
EditDetailFilter is a ENT FOUNDATI/EditDetail
EditDetailFilter is a ENT FOUNDATI/Filter
EditDetailFilter.Edit replaces FNC UIBASIC/Grid
                …by FNC EditDetailFilter.FilteredGrid

When you look at the calls for the EditDetailFilter.Edit you will see calls to two different BlockFetch functions:

Note that both calls are visible (the Vis column is checked). You can see this same behavior in r5.0 and r5.1. So which BlockFetch is actually called in the action diagram? This determination is made at action diagram load time. The result is sensitive to changes in the inheritance engine in recent CA Plex releases. The intention is that the Filter.BlockFetch should be called. To get this result at r5.5, CA has entered an additional replacement triple on the FOUNDATION pattern library:

FOUNDATI/Filter.FilteredGrid replaces FNC UIBASIC/UIBasic.Grid.BlockFetch
                       ….by FNC FOUNDATI/Filter.Filter.BlockFetch

Previously, the BlockFetch function was not explicitly replaced. Instead the replacement was made only on the scoping view:

FOUNDATI/Filter.FilteredGrid replaces VW UIBASIC/UIBasic.Grid
                          …by VW FOUNDATI/Filter.Filter

With the revised algorithm used in CA Plex r5.5, this was not sufficient to force the required function replacement to occur. By adding an additional, explicit replacement on the BlockFetch itself, CA has been able to retain the required behavior in r5.5. Similar actions may be necessary in your own functions that exhibit this behavior.

Example 2: Diamond Inheritance

Consider the following set of triples:

This type of scenario is known as diamond inheritance due to the shape of the resulting inheritance hierarchy as shown by the following diagram.

The inheritance hierarchy starts at An Entity, diverges, and then the two branches are brought back together at Our Entity. This situation is quite complex but the examples in real customer models are often even more complex with further branches and layers of inheritance involved.

If you view the Object Properties for the function Our Entity.Our Function then you can see the two calls triples, both visible. There are two important points to note:

• There is only one actual action diagram Call explicitly entered in this set of functions but two possible calls were resolved in Object Properties
• This scenario can be reproduced in any CA Plex release from 3.5 onwards

The only way to determine which function is actually called is to examine the action diagram code. This example again shows the changes in the inheritance engine over recent releases: At r5.0, Our Entity.Your Validation Function is actually called, but in all other releases including r5.5 it is Our Entity.Our Validation.