How to Model

The following figure explains how most methods are handled.

Y and Z do have lookup entries, but they will not be invoked from the outside, because their names do not match existing BID names. Requests for X are forwarded to Y or Z (or both, depending on the method).

Y uses the BII name ‘Y’ as its business object name. It also uses this name for its top-level component. So it doesn’t use the name ‘X’ as defined in the BID. In the same way Z uses ‘Z’ as its name, not ‘X’.

The following figure shows the flow for the PublishEvent() and ShowAndPublishEvent() methods:

The basic idea for the event handling is as follows:

• Application events are handled in X. This means X also contains the subscription for application events. The application can use the PublishEvent or ShowAndPublishEvent from Y or Z, but in that case Y and Z will do nothing else than forward it to X. The application can also use the PublishEvent from X directly. However, the ShowAndPublishEvent for X usually will not work, because the business interface implementation for X does not have a mapping to tables.
• Standard events (create, change, delete) are handled in Y and Z. This is needed, because the publisher uses the mapping to tables and columns to detect the events.