Skip to content

Modularization

Jump to bottom
Johannes Heucher edited this page Oct 12, 2022 · 4 revisions

Modularization allows Runtime Contexts to partition the project into separate Runtime Contexts, which are called required Runtime Contexts or Requirements. By defining a Requirement towards another Runtime Context the given Workspace or Application is allowed to use the required Runtime Context's content, e.g. XMOM Objects and Order Types (cf. fig. 1). An Application Definition is a blueprint of a future Application and can also define Requirements, which will become the new Application's Requirements. In terms of modeling all of the XMOM Objects provided by required Runtime Contexts may be used to build new XMOM Objects, e.g. Workflows. The objects foreign to the workspace currently opened are write-protected.

Table of Contents

Common Problems

The work with several required Runtime Contexts comes along with problems concerning missing or conflicting items. In most cases missing objects are resulting from missing or removed Requirements. Conflicting items will arise, if there are Requirements of one Application in several versions (cf. fig. 2).

Please note: Requirements are hierarchical and have to be non-conflicting with regard to all participating items.

Managing Requirements

The Requirements between the different Runtime Contexts can be managed in the Workspaces and Applications sections of the Xyna Factory Manager:

Problems like those mentioned above are also monitored in this section:

Prepare Existing Applications for Requirements

An Application, which didn't make use of Requirements yet, needs a litle care, before it is ready for including other Requirements. Normally an Application, which uses Requirements, has to require at least the Application Base in version 1.0 or higher. This can happen by having an explicit Requirement towards Base or requirering another Application, which requires Base (in)directly. The Problem with requiring Base for the first time is that nearly all of those older Application consists of XMOM Objects, which can than be found in Base (which again was the main idea in including them in a separate Application) (cf. fig. 4). In most cases there is no problem in simply delete those duplicates from the old Application.

The following process illustrates the preparations in detail:

  1. Load the content of the old Application into a new or existing Workspace. This will create a fitting Application Definition including all XMOM-Objects of old Application.
  2. Set ''Base'' as required Runtime Context
  3. Display the problems inside the Workspace. The Runtime Context Problems box will now show an error with the conflicting items (cf. fig. 3).
  4. Remove the conflicting objects
  5. Verify, that there are no problems left, and build a new Application from the Application Definition created before
Please note: Normally all conflicting objects can be replaced by those from Base because of their shared evolutionary history. In rare cases the older objects were changed later, which makes it impossible to migrate those changes by simply deleting the older objects. These cases need special treatment depending on the situation and can't be explained here in detail.

It is strongly recommended to use Xyna Factory functions whenever possible. Thus, a project can benefit from bug fixes, performance improvements and additional implemented features by upgrading the dependent Xyna Factory application.

It is not recommended to use imported copies of Xyna Factory feature or use even private patched versions. Sooner or later these copies will lead to inconsistencies or unexpected behavior when they are in conflict with Xyna Factory functions.

See Also

Clone this wiki locally