Specialist Creation and Persistence Implementation

The workflow process definition tool for WEWE is an internet application with a thin client that allows users to create specialists and their rules through a JavaScript imbued interactive interface. With very little assistance from the backend (server), the client interface uses JavaScript objects (more specifically JavaScript object literals) to temporarily store the information inserted by an administrator user regarding all specialists and their attributes. Once the user is satisfied with all the attributes of a particular specialist and inserts it into the definition of the workflow, all the specialist attributes stored in the JavaScript objects is serialized into a compact JSON string [1]. This JSON string consisting of the specialist rules accompanied with the specialist’s metadata (name and description) is sent to the backend (server) of the process definition tool which then relays this information to the WEWE main engine to be stored as a record in Table B.1.

Table B.1: The schema for the table wewe_specialists.

Table “wewe_specialists”

field type(size) default/options/indexes/constraints specialist_id serial auto increment, primary key, not null

workflow_id integer foreign key (wewe_workflows:workflow_id) specialist_name varchar(100) not null constraint

specialist_description varchar(500) not null constraint specialist_rules blob not null constraint specialist_status integer not null constraint

From Table B.1, the specialist rules are saved as a JSON string in the ‘specialist_rules’ column. The format of this JSON string can be illustrated as an example in code listing B.1.

- - Rule 1 - - 

IF (var.action_A == true AND const.name == “Salman Noor”) <execute Action Set 1>

- - End of Rule 1 - - 
- - Rule 2 - - 

IF (var.action_B==true AND timelapsed.hours>=24) OR (var.action_C!=true) IF (const.studentNo==“0501698D”)

<execute Action Set 2>
- - End of Rule 2 - - 

CAN BE REPRESENTED USING JSON AS:

{ “attr1” : {

Rules : { if1 : { ruleGroup1 : [

{ field : “var.action_A”, operator : eq, value : true }, { field : “const.name”, operator : eq,

value : “Salman Noor”

}

]

} },

Actions : {<Execute Action Set 1>} },

“attr2” : {

Rules : { if1 : { ruleGroup1 : [

{ field : “var.action_B”,

operator : eq,

value : true

{ field : “timelapsed.hours”, operator : ge, value : 24 } ] }, { ruleGroup2 : [ { field : “var.action_C”, operator : ne, value : true }, ] }, }, { if2 : { ruleGroup1 : [ { field : “const.studentNo”, operator : eq, value : “0501698d” }, ] }, },

Actions : {<Execute Action Set 2>} }

}

Listing B.1: The format of the JSON string that stored specialist rules using an example.

From code block B.1, it can be seen that the format of the JSON string is ideal to store rules with nested if statements and antecedent conjunctions (AND) and disjunctions (OR). When a specialist is created, the specialist rules are loaded into the specialist object from this JSON string of rules stored in the database.

Actions to be executed in specialist rules are defined using JSON in the format shown in code listing B.2.

{

package_name : “The java package name”,

class_name : “The name of class within the java package”, method_name : “Method to execute within the class”,

interaction_mode : Can be set to either user or auto }

____________________________________________________________________________ An example of an action to an application program that performs SQL queries {

package_name : “za.ac.wits.dbqueryexecutor”, class_name : “DBQueryPerformer”,

method_name : “executeQuery”,

argument_list : [ “mysql”, “localhost”, “3306”, “test_db”, “root”, “pwd”, “insert into students values (‘Salman Noor’, ‘0501698d’)”

],

interaction_mode : auto }

Will execute a function with the signature:

void executeQuery(String dataBaseType, String connIP, String connPort, String DatabaseName , String username , String password, String SQLquery)

Listing B.2: The JSON format of a specialist action is shown.

From code listing B.2, each action defined should have an array of arguments that can be passed. An action can have no parameters and in this case an empty array of arguments will be passed. Code listing B.3 demonstrates how static and ad-hoc parameters can be defined.

An example of an action to an application program that performs SQL queries {

package_name : “za.ac.wits.dbqueryexecutor”, class_name : “DBQueryPerformer”,

method_name : “executeQuery”,

argument_list : [ “mysql”, “localhost”, “3306”, “test_db”, “root”, “pwd”, “insert into students values (‘const.name’, ‘const.studentNumber’, ‘timelapsed.days’)”

],

interaction_mode : auto }

Will execute a function with the signature:

void executeQuery(String dataBaseType, String connIP, String connPort, String DatabaseName , String username , String password, String SQLquery)

From code listing B.3, the first six parameters (“mysql”, “localhost”, “3306”, “test_db”, “root” and “pwd”) are defined as static parameters. They cannot change whenever this action executed. The last parameter contains a SQL query which contains ad-hoc parameters (‘const.name’, ‘const.studentNumber’ and ‘timelapsed.days’) that will be retrieved at runtime from the blackboard. When the specialist instance is being animated by the specialist animator, it scans all actions for access specifiers (const, var, timelapsed, timeout) that indicate ad-hoc parameters and replaces them with values that can be found on the blackboard.

Actions in action sets have to be placed in specialist condition-action pairs (specialist rules) that are saved in JSON format. An example of this is given already in this Appendix. The JSON format of how actions are saved in a specialist rule is shown using examples in code listing B.4.

An example of an action set with a specialist rule: {

rules : {set of specialist rules},

actions : {

actionset1 : [

{Action A}, {Action B}

], actionset2 : [ {Independent Action C} ], actionset3 : [ {Independent Action D} ] } }

Listing B.4: The JSON format of specialist actions within action sets.

From code listing 14, action set 1 contains two synchronous actions (Actions A and Actions B) where the latter action (Action B) might be dependent on the result of the first action. Action sets 2 and 3 each contain a single action that is set to be run independently.

Each application plug-in program needs to expose its actions (the methods) to WEWE. A common Java interface is defined that can be implemented by the applications plug-ins programs. This interface essentially provides a common contract between WEWE and the numerous application plug-in programs invoked by WEWE. Each application program must implement only one interface defined in code block B.1.

public interface AppProgram {

public String getFeatureName();

public void setSpecialist(Specialist theSpecialist);

public void setWorkflowProcessData(WFProcess theWorkflowProcessData);

public String getLastActionDoneDescription();

public boolean lastActionSuccessful();

public String getLastActionStatusCode();

public String getFeatureShortDescription();

public String getFeatureDetailedDescription();

public void setInteractionMode(int theInteractionMode);

}

Listing B.5: The interface that needs to be implemented by invoked application programs.

Each application program can offer many actions (methods) with different return types, names and input parameters. It can be seen that the interface defined in code listing B.5 does not deal with the definition of actions. This is due to the difficulty in using an interface to implement multiple actions (methods) that can possibly have vastly different signatures (return types, names and input parameters). Furthermore, these actions are defined as normal methods. This presents WEWE with the difficulty of how to identify them as actions and invoke them. Java annotations were used to identify action methods and provide metadata (information about the action) which avert all difficulties mentioned. Appendix B3 will mention how Java annotations are utilized to execute specialist actions.