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.) []

;

Introduction

In the chapter on business objects you learned how to create programs that can be started from the menu on a client. End users use business objects for their daily business (implemented business processes and functionalities).

On the other hand, there are ACComponent instances that exist in the application projects (or application trees ) on the server side and are also responsible for the automated handling of business and production processes. These can either be static process application instances or dynamic workflow instances that are loaded into the application trees during runtime.

Now, as a programmer, you want to avoid programming redundant code in order to be able to map the same business process functionalities on the client or server side. In addition, there is the problem that you often have to program project-specific changes that deviate from the standard, which should also be available on the client and server side. The customer may also need communication interfaces to external systems that also want to use the common functionalities. Or you would like to make these functionalities available on mobile devices ...

The service-oriented architecture of iPlus is predestined for these requirements, because you can provide the common code with so-called manager classes, which are organized under the address "\Root\LocalServiceObjects".

Local Service Objects and Manager Classes

You add manager classes in the development environment below "LocalServiceObjects":

All manager classes provided by iPlus are derived from the abstract base class " gip.core.autocomponent. PARole " and end with the word "manager". (The term " manager " was chosen because it should represent a bridge to the real world. People who want to use a service must turn to a central point in a company or the public service, eg the exhibition a passport; the salary you receive from the HR department; a work assignment that you receive from your supervisor. These central offices therefore assume a certain " role " or function in an overall system.)

So if you want to develop your own manager class, you should stick to this naming and also derive it from PARole.

We also recommend setting the start type to "If required", because it is sufficient to only instantiate the class when it is actually needed. In addition, instances in "LocalServiceObjects" cannot be persisted because each client and server instantiates these instances in its own application domain. Hence, manager classes must be stateless !

Programming guidelines for manager classes

Since the common functions of manager classes are called from different places at the same time (multi-threading), they must not have any private fields (stateless).
You have to program the class functionally . This means that all required data must be passed as parameters when the method is called. Internal method calls as well.
Manager classes must therefore not be secured with thread locks because there are no private field values (status).

Programming

The following example shows how to program a manager class:

The following method is declared in the base class PARole:

public static T GetServiceInstance<T>(ACComponent requester, string acIdentifier, CreationBehaviour creationBehaviour = CreationBehaviour.Default) where T : IACComponent

This static helper method returns the instance of any manager class. It searches for the instance in the following order:

Below the requesting component itself (child). If it wasn't found there, then it will
searched below "\ Root \ LocalServiceObjects" . If it wasn't found there, then it will
searched in the application project "\ Services" (network instance)

In the example code above, two methods (A) and (B) have been declared that use the GetServiceInstance <T> method. In your manager class that you want to program, however, you have to decide whether it should be available locally (A) or as a network service (B). Both as in the example above are not possible.

The other two methods (C) and ( D ) use GetServiceInstance () and create a smart pointer ACRef <T> .

The "SumLines ()" (E) method is intended for local use. Please note that all necessary data must be transferred as parameters because manager classes must be stateless.

The "SumLinesByID" (F) method is intended for use in a network.

Now let's look at how this "manager class" is used:

If you want to use your manager class locally , then you should program it as in the example under points (A) and (C) . To use it as a network-compatible instance, program it as described in points (B) and (D) .

Don't forget to disconnect the smart pointer in the deinitialization phase (E) .

Number generator

The best-known manager class is the number generator ( gip.core.autocomponent. ACVBNoManager ), which you already got to know when programming a New () method for a business object. The number generator is created under "LocalServiceObjects". Because it is needed very often, it can be accessed directly via the " IRoot .NoManager " auxiliary property . Since it is programmed stateless, all necessary data must be transferred via parameters:

string secondaryKey = Root.NoManager.GetNewNo(Database, typeof(InOrder), InOrder.NoColumnName, InOrder.FormatNewNo, this);
CurrentInOrder = InOrder.NewACObject(DatabaseApp, null, secondaryKey);

GetNewNo is a virtual method and has the following signature:

public virtual string GetNewNo(IACEntityObjectContext context, Type type, string entityNoFieldName, string formatNewNo, IACComponent invoker = null)

You can override this method in a derivation for project-specific behavior. In order for your class to be used, swap the class using the context menu in the development environment:

You can set the number range that the number generator should use in the " gip.bso.mes. BSONoConfiguration " business object .

Programming guidelines for manager classes

Cookie settings