AyMINE back-end Scripting & Automation

• Common object-method calling
  • Command object
  • Response object
• Basic framework objects
  • Common Persistent object ancestor
  • Module Initialisation object
  • Common module functionality

AyMINE back-end services implements support for universal scripting with thousand of methods defined both by framework and modules

Complete AyMINE ecosystem logic is encapsulated in object methods. Methods can be called directly or indirectly through the internal SOA events.

Common object-method calling

AyMINE support publishing methods that are callable by client, through the AyMINE API or internally. Published method should follow the fix structure

public static function <method>(Command $command [, internal optionall attributes]): Response

The 1. st attribute should be Command $command - both name and type of the attribute is controlled. (The control protects undesirable call of not-published method).
Published methods has allowed other attributes as well but they are not published. They must be optional and they are never used from outside
Both Command a and Response object are defined by the AyMINE framework.

Next section introduce object in brief, details are available in the documentation for developers.

Command object

Command object pass information to the published method:

class Command {
  /** Commad source - Function that are not universally desinged, should check that they are called from allowed source
   * Uses constant comSource.. or interally defined other value.
   *
   * The Predefined values are generally supported but modules could support other values (e.g. middleware)
   */
  public comSource $source;
  
  /** Command action - always = server */
  public string $action;
  
  /** Command to execute, at the begining, field contains the whole command lately processed by the commandManager */
  public string $command;
  
  /** Path - part of the command, used to call stored method */
  public string|null $path;
  
  /** Optional link to the obj record processing the command - assigned only for preOp, postOp functions */
  public ObjRecord|null $objRecord;

  /** request for lock on object. Send to client together with request for single object
   * Accepts only values from Command::wLockRequest_   */
  public string $lockAction;
  
  /** Optional subpart of the object to lock - name of the lock part */
  public string $lockObjPart;
}

Command object pass attributes from the caller. All attributes are available via the methods that sanitize the content.

Response object

All published methods return response by the Response object. Missing the response would cause system exception but it does not stop process execution.

class Response {
  /** Status of the method processing */
  public string $status;
  
  /** Message for caller */
  public string $message;
  
  /** Optional return data - blob or the attributes (iAttr object) */
  public mixed $retdata;
}

Response is returned as an object with methods for work with return attributes. It is also returned as a response to the client application or by API call. Return is object in the json base64 encoded format.
if retdata attribute is used in the response, message always contains specification of the retdata values:

• __ATTRIBUTES__: Values in retdata are common attributes

Basic framework objects

Common Persistent object ancestor

Persistent object is a common ancestor of all persistent business objects. It encapsulates:

• Save / Load
• Safe creation of new object
• Support of user-defined fields, variant fields stored in the object json structure and back-end internal fields (not directly available for client)
• Object client separation
• Right-access control

Notes: Business functionality is not limited to the persistent object. Scripts can any object.

Module Initialisation object

Modules can publish initialisation object Init with metod for client initialisation getUserInfo. Method is called with first used login and then periodically (every few minutes.)

Object and initialisation method are not required. Further object usage depends on module. Basic framework module (frm) as well as some business modules (e.g. BSC) don't use it.

Common module functionality

Modules can encapsulate common non-object related functionality to the object (e.g. sysSys for sys module). These objects

• Publish server definitions of enumerations constants that are not related with single object
• Common methods and access to the module settings for clients.

Object publish initialisation and clearing module

• addToClient - called when a module is assigned to the client. It can initialise it usage by client (preset its configuration)
• removeFromClient - called when module is removed from client. It can delete its client-based configuration.

frmFrm object

Common framework object contains definition of broadly used enumerations like common object status.

Module provides information about

• Modules installed in the environment
• Modules used by client
• Description of available objects and their relationship

sysSys object

Common framework object contains definition of broadly used system-wide enumerations like currencies and langauges.