Orchestration scripts

Orchestration between client and server interlinks server-based business logic with the client application UI.

Orchestratin is a strong mechanism how is the AyMINE application developed. Orchestration described here orchestrates client with server.

Documentation how are orchestrated server modules see the system messaging chapter.

• Actions
• Script examples
  • Example 1:
  • Example 2:
  • Server side of the script
• Related sources

Orchestration scripts can be processed both by server and client but their major usage is in the client behaviour definition.

Orchestration commands grouped to the set of actions and each command is form a single action group. Some actions are supported only in some running environment (client application / server – php server / node – node server)

Actions

The list in the [ ] describes in which running environment is the action group available.

• form [application only] – open a new form (window);
• window (application only) – commands operated by a single window
• clip [application only] – command operated by a clip
• server [application, server] – commands operated by php server; when called by application, server is called to process the operation
• server [application, server] – commands operated by node server; when called by application, node server is called to process the operation (only available in the AyMINE Business edition)
• script [application, server] – manages operations that control script processing
• run [application, server] – operations not related with any object but supporting the script processing
• js [application only] – start command from included module library. Supports client extension by modules

Scripts are designed both for server and client side but curently used almost only by the client management a orchestration between client and server. Client processing of the scripts is described in detail in the Application section.

Script examples

Example 1:

Let’s look on the simple example:

"replanTasks":{"icon":"calendar__link", 
   "command":[
      "window.save",                              // Save opened object if not yet saved
      "server.tskTask.replanTask(operation=area)",// call server function and send attributes
      "window.reload"                             // reload window to get new data from server
   ] 

Single function contains just 3 lines and creates functionality that can be assigned to the application button or menu field or called from somewhere else.

Example 2:

"window.save",        
"select.sysUser.list.usersForAssignment(
      purpose=selectOne, 
      tskAreaID:linkID=@oAttr:tskAreaID, 
      hint=selectNewAssigned, 
      location=modal)",
"window.userInput(
      question=qAssignMsg,
      enumType=optUserEnum,
      enum=tsk/Task-AssignmentReason)",
"server.tskTask.assignTask(oper=assign)",
"window.close"

The script manages several steps:

• Save the window to send actual data to the server
• Request user to select user
• Request user to provide some additional information about the operation
• Request server to start business method of the object tskTask
• Close the application window after the result

Server side of the script

At the server side should be defined object tskTask that defines business logic called from the script:

class tskTask extends tskPersistent
{

   /** Replan single task  */
   public static function replanTask(Command $command): Response
   {
      $tskTaskID = $command->attrVal('tskTaskID');
      $oper = $command->attrVal('operation');
      $reject = static::checkRightsInt($tskTaskID, operC::update, $task);
      if ($reject) return $reject;
      . . . // make the business logic
      return Response::OK();
   }
   . . . 
}  // end of busienss object definition

Let's look on the method line-by-line

   class tskTask extends persistentObject 

Each business object is descendant of the persistentObject. The persistentObject encapsulates framework functionality.

   public static function replanTask(Command $command): Response  

Business function has common interface – it gets all attributes in the Command object. There are all attributes defined by the orchestration script and other attributes that describes the environment:

• What object defines the script
• What is the active object
• Where was the script activated (view)
• What are other object related with the view

   $tskTaskID = $command->attrVal('tskTaskID');
   $oper = $command->attrVal('operation'); 

Business method has got all data fields from the $command attribute. It can request single attribute or got all of them as a single object to operate with

   $reject = static::checkRightsInt($tskTaskID, operC::update, $task); 
   if ($reject) return $reject; 

Before object method at the server is called, the framework checks user statically-defined rights to user the object. However, static rights are not always (mostly) sufficient in the business environment and the dynamical rights should be checked. Each business object implements function checkRightsInt that evaluates dynamically-defined rights. It also loads the necessary part of the object and provides it back to the further processing so that object is not loaded twice.

If object method does not approve the user right to perform the operation, function returns permission error back to the users and the script is interrupted.

return Response::OK();

Functions returns result by the Response object. They can set attributes or even complex data and send them to the Application for further processing.

Business objects functions are used also during the back-end managed operation. The business method interface is universal for all kinds of methods that created the object public interface.

Related sources

• Look at the video tutorial how is a method in the application framework made in 5 minutes. You can also look for the slideshow summary here.