Advanced programming

collapse

#
- 1.) Application.config
- 2.) Basic concepts
  - 1.) Composite pattern
    - 1.) Lifecycle
    - 2.) Programming
  - 2.) Properties
    - 1.) Local
    - 2.) Network
    - 3.) Persistance
    - 4.) Configuration
    - 5.) Logging
  - 3.) Synchronous Methods
    - 1.) Virtual methods
  - 4.) References
    - 1.) 1 Object
    - 2.) N Objects locally
    - 3.) N Objects Network
  - 5.) Events
  - 6.) Asynchronous methods
  - 7.) Configuration
    - 1.) Config storage
    - 2.) Overriding
  - 8.) Messages and Alarms
    - 1.) Alarms
  - 9.) Database
    - 1.) Usage
    - 2.) Extend
      - 1.) EF 4.0
      - 2.) EF 7.0
    - 3.) Persistable queries
  - 10.) Designs
    - 1.) GUI Design
      - 1.) Set and convert Properties
      - 2.) Styles and Setter
      - 3.) Property trigger
      - 4.) Datatrigger
      - 5.) Events & trigger
      - 6.) Animations
      - 7.) Resources
    - 2.) Reports
      - 1.) Programming
  - 11.) Diagnose and Debugging
  - 12.) Updates
- 3.) UI-Controls
  - 1.) UI-Library integration
  - 2.) iPlus-Controls
  - 3.) Custom Controls
- 4.) Application programming
  - 1.) Multithreading
  - 2.) Businessobjects
    - 1.) Navigationless
    - 2.) Navigable
    - 3.) Context dependant dialogs
    - 4.) Background Tasks
  - 3.) Manager classes
  - 4.) Process applications
  - 5.) Workflow classes
  - 6.) External systems
    - 1.) Mobile devices
    - 2.) OPC UA Communication
      - 1.) Server
    - 3.) Simatic S7
  - 7.) Bit masking
- 5.) []

;

The interfaces gip.core.datamodel.IACConfig and gip.core.datamodel.IACConfigStore are used to save and read configuration values (see chapter Configuration memory). In the "iPlus-MES" data model ("gip.mes.datamodel") there are a number of tables that implement these interfaces. Most of them are primarily used to store configuration parameters for workflows. Workflow classes that are later instantiated at runtime have their special tasks. Their behavior is primarily based on the configuration of virtual methods, their own configuration parameters and the routing rules certainly. Depending on the purpose, workflow classes access various application tables. Which data is to be read, added or manipulated depends on the configuration of these workflow classes but also on the progress of the business process itself. The behavior of a workflow class or the later instance therefore depends on the context of the data with which it works and its progress. For this reason, configuration parameters must be saved depending on the context and, depending on progress, may need to be adapted or changed. We call this principle strict separation of entities with increasing concretization" or technically speaking "overwriting of parameters".

Parameters are overwritten by reading the tables that serve as configuration memory (which implement IACConfig and IACConfigStore) in a predetermined order. The following picture explains this, using production orders from the "iPlus-MES" data model:

The red rectangles are the configuration memory tables. The direction of the override is shown from left to right. The following sequence then results:

gip.core.datamodel.ACClassMethodConfig (IACConfig). Table that stores configurations for the master data workflows. The data context is gip.core.datamodel.ACClassMethod (IACConfigStore).
gip.mes.datamodel.MaterialWFACClassMethodConfig (IACConfig). Table that stores configurations for material workflows. The data context is gip.mes.datamodel.MaterialWFACClassMethod (IACConfigStore).
gip.mes.datamodel.PartslistConfig (IACConfig). Table that stores configurations for Bill of materials. The data context is gip.mes.datamodel.Partslist (IACConfigStore).
gip.mes.datamodel.ProdOrderPartslistConfig (IACConfig). Table that stores configurations for manufacturing orders. The data context is gip.mes.datamodel.ProdOrderPartslist (IACConfigStore).

The order therefore also reflects the level of concretization. Settings made in (1) master data workflows generally apply to all subsequent levels that refer to this workflow. Settings made at the last level only apply specifically to this one production order.

Selection of the data context

On the one hand, workflow parameters

are managed via the user interface,
and read from the workflow instances (active workflows) in the background.

In both cases, the program needs to know

which configuration memories are required (IACConfigStore),
in what order they are read
and which is the current configuration memory under which the parameters are saved (current data context).

This is done using the following interfaces:

A. User interface

In the programs (business objects) for managing material workflows, bill of materials, production orders, picking orders, etc. there is a tab in which workflows are displayed graphically. The parameters that are changed and added via the control dialog (gip.core.autocomponent.VBBSOControlPW) must be stored in the correct configuration memory. The control dialog receives this information via the property "IACConfigStoreSelection.CurrentConfigStore" of the currently selected graphic workflow object (property "VBBSControlPW. CurrentPWInfo"). The graphic object in turn is an instance of a class that implements "gip.core.datamodel.IACComponentPWNode":

PWOfflineNodeMethod: Model-class for displaying workflow nodes at the time of definition (inactive workflow).
PWBase : Base class for all workflow nodes that are instantiated on the server side (active workflow).
PWNodeProxy : Proxy class for PWBase (client-side instances).

The overwrite sequence is defined using the "IACConfigStoreSelection.MandatoryConfigStores" property. It is a sorted list of configuration memories (IACConfigStore). All IACComponentPWNode must therefore provide this list so that the control dialog can display the configuration memories for which a certain parameter has been overwritten.

The interface IACConfigURL is required so that the correct parameter for the selected workflow node can be read and written from the configuration memory . It is used to uniquely address a configuration parameter within a workflow. Through "IACConfigURL.ConfigACUrl" the current configuration table ("IACConfigStoreSelection.CurrentConfigStore") is filtered by property "IACConfig.ConfigACUrl". The ConfigACUrl is formed from "IACConfig.PreConfigACUrl" and "IACConfig.LocalConfigACUrl".

The PreConfigACUrl is required for "subroutine calls" - when a workflow calls a subworkflow, the PreConfigACUrl points to the calling workflow. This "call stack information" is provided by "IACConfigURL.PreValueACUrl". Since IACComponentPWNode inherits from the IACConfigURL interface, the workflow instance itself knows from which "parent workflow" the "subworkflow", to which the workflow instance belongs, was called. The "call stack" - that is the call sequence of workflows - provides the property ACConfigMethodHierarchy from interface IACConfigMethodHierarchy. IACComponentPWNode also inherits from this interface.

During the declaration phase, when workflows using PWOfflineNodeMethod-Instances are presented, there are actually no subroutine calls. This is only possible during runtime if PWBase derivatives are instantiated. If configuration changes are made during runtime, the corresponding live workflow instances must be informed so that they can reload the changed configuration from the database just-in-time. Since changes are only accepted into the database with the "Save" button, it can happen that several sub-workflows into which the user previously navigated are affected at the same time. The relevant BSO must remember this information. For this reason, BSOs that display workflows must implement the IACBSOConfigStoreSelection interface. Every time a configuration parameter is changed via the control dialog, it informs the corresponding BSO of the workflow (or subroutine) in which the parameter was changed by calling the "IACBSOConfigStoreSelection. AddVisitedMethods()"-method. The BSO then remembers all subroutine calls in the property "List <ACClassMethod> VisitedMethods" until the storage process is carried out on the database. If the save process is successful, the active workflows (on the server side) are notified using the "ConfigManagerIPlus.ReloadConfigOnServerIfChanged()"-method - a class, that implmenents IACConfigProvider .

B. Background

The logic described under A. is extensive on the one hand, and on the other hand it is also required in the background, if workflows or workflow nodes are active and have to read their own configuration. Ultimately, it is about reading or manipulating configuration parameters and hiding the complexity of parameter overrides (sequence of configuration memories) in combination with subroutine calls.

This is guaranteed by means of the IACConfigProvider interface. Derivatives of PWBase and the control dialog (VBBSOControlPW) use the methods provided there. The class gip.core.autocomponent.ConfigManagerIPlus implements this interface. ConfigManagerIPlus is stateless and is provided as a local service at "\LocalServiceObjects\VarioConfigManager". ConfigManagerIPlus only works with configuration memories from the "gip.core.datamodel" data model. The derived class gip.mes.processapplication.ConfigManagerIPlusMES is used for "iPlus-MES", that can handle configuration memories from the "gip.mes.datamodel" data model.

Usage and Programming

One of the most important places that IACConfigProvider uses is the method GetConfigForACMethod() from "gip.core.autocomponent.PWBase". It is the base class of all workflow classes. Since all derivatives have to read the corresponding configuration parameters for routing rules, function calls or themselves, they use GetConfigForACMethod() to fill the parameters of an empty ACMethod (see, in particular program lines with the comment 1. and 2.):

Here are some program parts of workflow classes that use GetConfigForACMethod () to read your own configuration parameters:

A. User interface

B. Background

Access to the own configuration parameters of a workflow class:

Configuration parameters for function calls:

Access to the routing rules via IACConfigProvider:

A. User interface

B. Background

Access to the own configuration parameters of a workflow class:

Configuration parameters for function calls:

Access to the routing rules via IACConfigProvider:

Cookie settings