Subsystems and Subsystem Threads (Magic xpa 3.x)
It is good practice to design your application in a way that gives each user the information and application facilities needed to work with and transfer extra information on demand. When you define your application layout, you should consider dividing your application into several subsystems.
A subsystem is a part of the application that handles a certain scenario in the application. For example, in an application that manages a factory, you may define the following facilities: Production Floor, Warehouse, Delivery, Human Resources, and so forth. Each facility should be defined as a subsystem. In this way, each end-user of each facility can access the information and functionality relevant to the scope of a specific facility.
The figure below illustrates how a factory management application may be divided into subsystems.
Subsystem Threads
A subsystem thread refers to a specific procedure within a particular subsystem. A subsystem thread usually refers to a defined flow of tasks. For example, the Order Entry procedure may be regarded as a subsystem thread within the Orders subsystem. Usually a subsystem thread appears as an option in the subsystem menu.
Subsystem Structure
Usually a subsystem is constructed of the following elements:
-
Subsystem initialization
-
Logon
-
Menu
-
Subsystem threads
The figure below illustrates a typical subsystem structure.
When you divide your application into subsystems, you achieve:
-
Improved application management
-
Reduced resources of the Enterprise Server
-
Compartmentalization
-
Minimized initialization phase
Improved Application Management
By splitting the application into separate subsystems you achieve better management of the entire application.
Reduced Resources of the Enterprise Server
Each context is kept and handled by the enterprise server process that created it. Other processes cannot handle a context’s request if the context was opened by another process. By splitting the application into subsystems, each subsystem opens a different context that can be handled by a different enterprise server process. In this way you can distribute the load of each end-user among the available enterprise server processes.
Usually each subsystem requires different global data resources, such as memory tables and global variables. By dividing the application into smaller subsystem units, the global data resources are only kept in the relevant contexts.
Compartmentalization
Subsystems are accessed via independent URLs, and each URL can open a different subsystem. In this way you can compartmentalize the application by providing each end-user the URL access relevant to the end-user’s specific role.
Minimized Initialization Phase
Quite often, each subsystem calls for a different initialization phase, in which different resources are set and different procedures are executed. By dividing the application into subsystems, you can specify that the initialization phase be executed only for the requested subsystem instead of having the entire application initialized.
