Email: info@axon.network

FAQs

A common issue that can occur with users new to installing WordPress themes is a "Broken theme and/or stylesheets missing”
error message being displayed when trying to upload or activate the theme.

Quick Navigation

Action

The actions define the type checking at the behaviour level. An action consists of many elements of other types. Signal operators, turn an action into a signal. Complementary signals interact. During interaction, the element values specified in the action move from the source signal to the destination signal. Only if the values pass the type of the elements specified then the interaction is successful.

Action in Axon language defines signal type. The signal is the actual experience of the signal in the axon processor.

Structure of an action can be seen below:

<Element>ElementName</Element>

<ActionName>ActionName</ActionName>

</Action>

Element (<Element>…</Element>)

This gives the name of the element. The element should be defined earlier as part of the element repository. The Action checks with the element repository to ensure that the element name exists. At the time of interaction of this action, this element is the carrier of the data and ensures that the type is transmitted appropriately.

Action Name (<ActionName>…</ActionName>)

The action name gives the name of the action which contains these elements.

Actions take part in an interaction and move the process forward based on binding. Elements are tags which define the type of data to be carried in the actions when an interaction happens for an action.

Agent is used to define the dynamic nature of the application. Like in the case of the subroutine in traditional programming, Agent can be used to do reuse. Agent consists of signal operators and configuration operators. The signal and configuration operators are employed to specify system behavior Agents can have a separate process space based on how you define it. User file is also effectively an agent but is the main file which provides access to actions for new users in the use case flow defined by you.

Advantages

The project execution can be planned as soon as the Use case is finalized. However, due to the removal of the Design phase completely, timeframes for the development would be based on the complexity of the Use case documentation.

The project execution for MasterKube is from the Use case documentation. The design phase (class and database steps) is removed completely.

Agent

A system in Axon consists of Agents which interact with each other. What travels between the source agent and the target agent during an interaction is defined by signal. By default, data in an agent is private and is shared only when an interaction happens between it. The agent is free to remove this signal so the data is not shared at any time. This freedom of agent to appear and withdraw from the network make these agents autonomous. The system defined in Axon language is compiled into the axon processor.

These autonomous agents are experienced by external systems or people when it expresses signals from actions. These signals are exposed to external systems or people as REST Urls. The external systems or people can interact with this autonomous agent by interacting with the signals

Agents are reusable components. Agents are used to group actions into a coherent entity.

The agent when it is instantiated can be either be part of the current agent namespace or it could spawn a new agent namespace.

When the agent adopts the current node/namespace it takes the namespace of the agent that it got initiated in. When an agent triggers a new namespace/node it creates a new node of the type that is specified in the “Processname” tag of the agent definition

The agent configuration operators in axon language triggers agent functionality. The Axon language which defines and triggers agent are as follows:

Agent in the current node

<Agent>

<AgentName>AnnualLeaveAgent</AgentName>

</Agent>

This code snippet is introduced in the axon code to add all signal sequences into the current node. This can be called over and over again to bring out the same signal sequences.

Agent spawning a new node

<Agent>

<AgentName>AnnualLeaveProcessAgent</AgentName>

<ProcessName>AnnualLeave</ProcessName>

<AvatarName>EmployeeName</AvatarName>

<Element>EmployeeName</Element>

<Element>DepartmentName</Element>

</Agent>

This code snippet defines an agent that spawns a new node. In the case above it spawns a new autonomous agent node of type “AnnualLeave”. Each instance of the agent node is identified by the avatar name i.e in this case it is identified by the “EmployeeName”. The “EmployeeName” and “DepartmentName” is injected into this node from outside thru a ASK signal operator.

Agent triggering with a signal operator

<AgentName>AnnualLeaveAgent</AgentName>

<Ask> <action> <actionName>TriggerLeave</actionName> </action><internal>true</internal></Ask>

</AgentCommand>

This code snippet spawns the node “AnnualLeaveAgent”. It is spawned after the interaction on signal “Triggerleave”.

Agent triggering with no signal operator

<AgentName>AnnualLeaveAgent</AgentName>

</AgentCommand>

This code snippet spawns the node “AnnualLeaveAgent”. It is spawned automatically when it is encountered in code.

Other agents are of 3 types,

Arithmetic Agent
Decision Agent
Timer Agent

This is used for arithmetic calculations. The arithmetic expression to be evaluated is given in the tag “AgentExpression”, on triggering this agent, the variables in the right-hand side would be exposed as ASK actions. On binding of all these variables, the arithmetic expression is evaluated and the answer i.e the left-hand side of the expression is exposed as TELL action.

The arithmetic agent has the structure of,

<ArithmeticAgentCommand> <AgentExpression> Perform mathematical calculation </AgentExpression> </ArithmeticAgentCommand>

The arithmetic agent can be used for expressions that are hardcoded. It can also be used for dynamic expressions that are invoked from actions.

This is used for some arithmetic calculations. For example of the expression to be evaluated is orderamount=ordertotal+tax. Then when the agent is activated, the ordertotal and tax as exposed as ASK action. On binding of ordertotal and tax the right-hand side i.e, the order amount is evaluated. On evaluation, the order amount is exposed as a TELL action.

This is used for some arithmetic calculations. This allows a dynamic way of computing for specifying arithmetic expressions.

The arithmetic agent on activating raises an ASK signal with the name in the ActionName tag in the arithmetic expression. So for example, in the case below, “Invoicetotalexpression” signal is raised as ASK signal.

<ArithmeticAgentCommand> <ActionName> invoicetotalexpression </ActionName> </ArithmeticAgentCommand>

A process can now inject arithmetic expression through this exposed action, using a complementary “Invoicetotalexpression” TELL signal. This expression is evaluated like in the earlier case and the output TELL for the right-hand side of the expression is generated. In the event that the passed expression is not valid then it raises a “ValidationError” TELL signal.

The purpose of this agent is to arrive at a decision and drive processes. Unlike all other agents we mentioned before, this can be inserted anywhere in the overall process. This can be composed to create to make decisions. Imagine a set of rules that need to be evaluated all the time in a process, to make sure the process is consistent. This tag can be used to create that. This can also be composed to create a decision agent, which gets executed all the time to keep the overall process complete and valid.

For example, this can be used as a sentinel to monitor a stock so it always look at the stock balance and reorder quantity and raises appropriate stock out signals.

The overall structure of the code is as below:

<TrueEvent><Ask><action><actionName>Sweet16</actionName></action></Ask></TrueEvent>

<FalseEvent><Tell><action><actionName>Gottcha</actionName</action></Tell></FalseEvent>

</Decision>

<Decision>….</Decision>

This defines the overall decision. It consists of decision expression and a true event and false event. The expression, takes a logical expression, and if it is true then it triggers the action in the <TrueEvent> and if false it triggers the action in the <FalseEvent>.

<Expression>….</Expression>

The expression is the normal logical expression. The variables that need value gets published to the interaction space and this needs to be provided. On all the values arriving, the decision expression is evaluated. If the expression is turned true, then the true action is executed. Otherwise, the false action is executed.

<TrueEvent>…..</TrueEvent>

This is the true event. This can have any ASK or TELL signal.

<FalseEvent>…..</FalseEvent>

This is the False event. This can have any ASK or TELL signal

The Timer agent is a service offered by Axon processor to trigger signals at defined date. This can be used to trigger signals to different processes. For example, this can be used to signal an arrival of a patient on a specific date. It gets the system time and generates timer events. This can be used to raise appropriate invoice aging signals enabling a real-time reporting of payment health.

The syntax of the timer agent is given below:

<Timer>

<Ask><action><actionName>Schedule</actionName></action></Ask>

<DateElementName> StartDate </DateElementName>

</Timer>

This is for a ASK signal. On the specified time mentioned in the DateElementName triggers the ask signal “Schedule” on that date.

<Timer>

<Tell><action><actionName>Schedule</actionName></action></Tell>

<DateElementName> StartDate </DateElementName>

</Timer>

This is for a TELL signal. On the specified time mentioned in the DateElementName triggers the tell signal “Schedule” on the start date.

Architecture

Modern digital era applications are network applications. Unlike present-day algorithmic programming, the network application does not have a central program counter but is a network of devices or people or autonomous agents. These agents, people and devices signal each other to advance.

Axon processor executes network application. The systems in the axon are a network of autonomous agents that interact with each other. Axon processor transforms the sequential machine on which Axon is hosted into a concurrent machine executing network application.

The axon Language is directly deployed on axon processors to create network-based applications. The Axon language is used to create processes as a network of autonomous agents that interact. Any events that happen in the Axon processor are logged.

The Axon architecture can be divided into four different layers. The different layers are a) REST Layer, b) Axon Processor, c) Axon Language and d) Smart Interaction Design Layer.

The Axon Language provides the tools which can be leveraged by the creators to execute digital Experiences on Axon processor. Complex smart systems and Hyperconnected digital era solutions are delivered by leveraging the axon language.

The axon coordination language models interactions and not computations. Each interaction in axon is exposed as a REST URL. Axon, is one of the very few machine architectures that is fundamentally built on REST (Representational State Transfer) architecture. The REST Layer provides the REST property for Axon. Due to this REST Implementation, the Axon processor has no proprietary interface and hence is completely open. All resources like surround systems (eg, ERP systems, CRM systems) or other resources like devices can easily be plugged into Axon Fabric. The REST layer is delivering REST by leveraging RESTLET technology

Axon Language layer compiles the Axon Language to the Axon processor natively and executes on the Axon processor. The axon Language (consisting of signal and configuration operators) defines the different agents in a process network and how they interact with each other thru actions.

On the axon processor, signal operators create signals. The signals are how agents in axon agent network talk to each other and to outside actors. These outside actors could be either a Human or another computer. The configuration operator in Axon Language is used to sequence when these signals are exposed.

The business process layer adds features that are required for the execution of business processes. The different concepts that are introduced by the Business process layer are User Roles, Security, document storage and Presentation. It leverages on the functionalities provided by the Axon language to execute business processes.

Complex smart systems like smart cities, smart factories, smart supply chains etc. can be directly modelled and executed on axon processor with the help of axon language.

Arithmetic agent

The arithmetic agent has the structure of,

<ArithmeticAgentCommand> <AgentExpression> Perform mathematical calculation </AgentExpression> </ArithmeticAgentCommand>

The arithmetic agent can be used for expressions that are hardcoded. It can also be used for dynamic expressions that are invoked from actions.

This is used for some arithmetic calculations. This allows a dynamic way of computing for specifying arithmetic expressions.

<ArithmeticAgentCommand> <ActionName> invoicetotalexpression </ActionName> </ArithmeticAgentCommand>

Ask

ASK signal operator sets up the potential to receive information from another autonomous agent. When the information is received, Axon processor ensures that the values entered are of the right type. On receiving it advances the autonomous agent to the next signal(s).

When an Ask operator has an element of type name. Then axon processor ensures that during the interaction what comes on that is a signal that is open and available. In the Console UI, it lists all autonomous agent(s) which have that signal. The user can select from the list of autonomous agents shown. On selection, the selected action would be locked from further interactions and that name would be moved as part of the interaction to the process with the ASK signal.

The Ask (<Ask>…</Ask>) operator has the following XML structure:

<Ask>

</Ask>

<Ask>…</Ask>

The required information that is defined in the action definition is collected from the user or from the source process (process with the TELL operator). The action is included with their names in the <actionName> tag.

<action>…</action>

The required action to deliver information after process binding by using Tell operator is put into this action block with the specified name of action.

<actionName>…</actionName>

This actionName defines which action is to be performed by the tell signal operator. We can use more number of actions for a single Tell operator by using their action name. This publishes a new action. The action name would be generated dynamically.

<internal>…</internal>

This internal block will be responsible for controlling actions. That means it realizes whether the actions are shown to the user page or admin page. The value of internal may be true or false. If internal is set to true then the actions are only controlled and viewed by admin, but if this value is set to false then the actions defined within this internal is shown to the user also. This is an important block of process creation. The internal block is optional. If this internal is not defined, by default assigned to false.

general/{domain}/{process}/{pid}/{action}/{id}/Ask – complete description of ASK signal

Use this URL pattern, to get all the details that can be exposed by the action. This is defined in the actions repository.

Axon Components

Axon technology consists of two components. They are a) Axon processor and b) Axon Language. The Axon Language runs on the Axon processor and delivers network applications. In addition, the language operates at the business level, so it can be used to create complex business processes coordinating people, devices and organizations.

Language itself consists of two components: one defines the signal, and the other defines the sequence in which these signals interact. The Actions and Elements in language define the signal definition. The agent defines the signal interaction pattern.

Axon Language

A typical enterprise application’s purpose is to deliver interactions (input screen, report, etc). When these interactions have to be exposed, is collected in the use case documentation. Currently, sequential code is used to manufacture these interactions. With Axon, these interactions can be directly expressed without writing code to do Create, Read, Update and Delete. Axon accomplishes this by a simple series of Configuration and signal Operators written into a file divided as Agents, Actions and Elements. The Signal operators make the interactions visible. The Configuration operators specify the sequence of how these signal operators turn on and off to create the application.

There is no compilation of code. When the components of code, Agent, Action and Element are loaded, it is syntax checked. Once the files are loaded into Axon processor the signals are activated and start listening for the next interaction. Axon processor is not a code generator, it is a new type of processor.

Writing code in Axon can be started as soon as your design flow is clear. No technical requirement documents are needed. Code can be written using the Use cases identified. First define your Actions and elements which are separate files. After this link your actions in the desired flow using the Agents.

There are no errors that can come up while you run your code. The only area of failure would be if your signals are not linked up correctly. This can be investigated using breaks in your flow by adding TELL signals and reviewing current state of data in signals from the Axon database/ Admin console. Based on the current state you can determine why the binding of signals is not occurring.

Actions and elements file can be uploaded only once and cannot be over-written. If this needs to be done, database needs to be refreshed with an earlier instance of the image. Action is the definition of the interaction and changing this will have implications in other parts of the system. Hence Axon will not allow this to be updated. Agents on the other hand can be uploaded any number of times.

Signals do not publish data. Signals only bind and take the interaction forward as designed. By doing an ASK and TELL on an action, binding occurs and the interaction moves forward. Data moves from Source to Target. Data is shared to external clients in the form of URLs. This is the fundamental differentiation of Axon and it truly conforms to the REST framework of Hyper text as an engine of state (HATEOAS).

Information from a Channel can be published any number of times to different process spaces. However it needs to be done by generating new names which are pointers to the action defined. This is how you can move information to multiple process’s with a single line of code. In short we are just defining pointers to URLs based on a defined structure for the client to consume. It is with these pointers that we can move control from one process to another.

While uploading files into Admin console you will receive errors if syntax not used properly for signal and configuration operators. These syntax errors will appear in the apache log file.

Axon Name Space

Axon processor is an interaction machine. Data is accessed by interacting with these interactions after navigating through it. These interactions are available as REST endpoints, and hence can be directly accessed by external systems. Each interaction can point to other interactions. External systems can navigate this access space to explore data.

Each signal or interaction is identified to the external system as a URI. Each time a signal is created it creates a unique namespace. The URI signal namespace is a hierachial space. The namespace consists of the following basic components, The structure of this signal URI namespace is DomainName/ProcessName/PRocessID/Actionname/Sequenceid/(Tell or ASK).

Domain Name: The top most name in the Axon system is the domain. A domain can refer to a different company. This way it is possible to have two companies or tenants to share an Axon processor Installation.

Process Name: An agent can create a separate process or it can be part of a particular process. An agent with a process tag, creates a new process. The tag <ProcessName>Invoice</ProcessName> in the agent creates a new process. In the instance, it creates a new process called “Invoice”.

Process ID: An agent creates a new process, a new process id is created. This is a unique number generated by Axon.

Action Name: The data in Axon is hidden. It is exposed only through actions. Each action gives the signature of the data that is exposed. Depending on the action name the appropriate data is exposed. If an action is tagged as hidden then it will not appear in the api output.

Sequence ID: The sequence id ensures that the signal is unique. This is used to make sure only one interaction happens at any point in time. When an interaction happens on this signal, then a new number is generated. Right now this is a sequence number, but this can be changed to make an opaque numbering scheme to increase security. Each TELL or ASK operator creates a unique id.

TELL or ASK: Depending on the type of signal the appropriate TELL or ASK is shown here.

Below are the list of common URLs to get information from Axon processor on the Business flows designed:

/general/{domain} – Obtain All processes in a Domain
/general/{domain}/{process} Obtain all processes id’s in a Process and Domain
/general/{domain}/{process}/{pid} – Obtain all actions in a Process id and Domain
/general/{domain}/{process}/{pid}/{action} – Obtain all actions in a Process id, Domain for an action type
general/{domain}/{process}/{pid}/{action}/{id}/Tell – Obtain complete description of TELL signal
general/{domain}/{process}/{pid}/{action}/{id}/Ask – complete description of ASK signal
reports/general/{domain} – Obtain all actions in a domain.
reports/general/{domain}/{action} – Obtain all action instances in a domain.
search/{domain}?element=searchterm – List of all actions for search term in a particular domain.
search/{domain}/{process}?element=searchterm – List of all actions for search term in a particular domain and process.
search/{domain}/{process}?action=actionname&element=searchterm – List of all actions for search term in a particular domain and process with a given view.
search/{domain}/{process}?pid=processid&element=searchterm – List of all actions for search term in a particular domain and processid .
/history/general/{domain}/{process}/{pid}- History for a given process instance.
/history/general/{domain}/{process}/{pid}/{action}/{seqId} – History log detail
/settings/{domain} – Settings URI for the Axon domain

/settings/{domain}/actioncache – Get all cache actions for a domain

/general/{domain} – Obtain All processes in a Domain

It is possible we would like to know all processes available now under a domain. This URL can be used to interrogate Axon for this. On getting a request of this type, Axon responds with the list of processes under that domain.

/general/{domain}/{process} – Obtain all processes id’s in a Process and Domain

Use this URL to interrogate Axon to obtain all processes ids available now under a domain and process. On getting a request of this type, Axon responds with the list of process ids under the requested domain and process id.

/general/{domain}/{process}/{pid}/{action} – Obtain all actions in a Process id, Domain for an action type

With this URL pattern, It is possible to know all actions available under a domain, process id and action type. This URL can be used to interrogate Axon for this. On getting a request of this type, Axon responds with the list of same type of actions under a given domain and process id.

general/{domain}/{process}/{pid}/{action}/{id}/Tell – Obtain complete description of TELL signal

With this URL pattern, it is possible to obtain all the elements in a particular action instance or interaction. The elements are defined in the actions repository.

general/{domain}/{process}/{pid}/{action}/{id}/Ask – complete description of ASK signal

Use this URL pattern, to get all the details that can be exposed by the action. This is defined in the actions repository.

reports/general/{domain} – Obtain all actions in a domain.

Use this URL pattern, to get all the actions available in a domain. Since the actions are dynamic, this gives all actions currently available in a domain.

reports/general/{domain}/{action} – Obtain all action instances in a domain.

Use this URL pattern, to get all the action instances for a specified action {action} in a domain {domain}. Since the actions are dynamic, this gives all action instances for the specified action currently available in a domain.

search/{domain}?element=searchterm – List of all actions for search term in a particular domain.

Use this URL pattern, to get all the actions where the particular data value exists.

search/{domain}/{process}?element=searchterm – List of all actions for search term in a particular domain and process.

Use this URL pattern, to get all the actions where the search term exists in a particular domain and process.

search/{domain}/{process}?action=actionname&element=searchterm – List of all actions for search term in a particular domain and process with a given view.

Use this URL pattern, to get actions of a particular type (given in actionname) with in a domain and process that has the value in search term.

search/{domain}/{process}?pid=processid&element=searchterm – List of all actions for search term in a particular domain and processid .

Use this URL pattern, to get actions in a particular instance with the given search term. If the search term is not available in the process instance given then it returns empty.

/history/general/{domain}/{process}/{pid}- History for a given process instance.

Use this URL pattern, to get all the actions that happened in this process instance in the past.

/history/general/{domain}/{process}/{pid}/{action}/{seqId} – History log detail

The objective of this uri is to get information for a instance in a log

/settings/{domain} Settings URI.

Use this URL pattern to get all the settings url.

/settings/{domain}/actioncache Get all cache actions for a domain

The objective of this uri is to get all the cache setting actions for a domain.

A channel (this is identified by element of type name) has many purposes. The different purposes are a) Connect different autonomous agents to communicate values, b) Create reference between two autonomous agents (This is exposed as URLs in HATEOAS, c) By hiding a name and sharing it, it can be used to share values privately (mobile scope), d) A channel can contain itself to create circular dependencies.

Axon Processor

While uploading files into Admin console you will receive errors if syntax not used properly for signal and configuration operators. These syntax errors will appear in the apache log file.

Better Reliability

Technical defects avoided

Deadlock & Racing conditions
Simpler software leads to fewer defects
No Exception & Concurrency management

Reduce software defects

20% defects injected during the design phase
Removing design phase reduces these defect possibilities

Cache

/settings/{domain}/actioncache Get all cache actions for a domain

The objective of this uri is to get all the cache setting actions for a domain.

Choice Operator

The choice operator ensures that all the signal operators in the ChoiceOption of the Choice operator are activated. But only one signal operator in the choice option is allowed to be interacted with. On selection of one, the other signal operators in the choice are de-activated.

<Tell><action><actionName>ViewLoadEGMList</actionName></action></Tell>

</ChoiceOption>

<Ask><action><actionName>LoadToShipWithCurrentPlace</actionName></action></Ask>

<Tell><action><actionName>SendContainerMove</actionName></action></Tell>

<Tell><action><actionName>LoadToVoyage1</actionName></action></Tell> </Compose>

</OptionAction>

</ChoiceOption>

<Ask><action><actionName>EnterMarksAndNumbers</actionName></action></Ask>

<Tell><action><actionName>SendContainerMove</actionName></action></Tell>

</Compose>

</OptionAction>

</ChoiceOption> </Choice>

In the above case, the signals “ViewLoadEGMList”, “LoadToShipWithCurrentPlace”, and “EnterMarksAndNumbers” become observable. On interaction on one, the other activated signals deactivates. I.e when “LoadToShipWithCurrentPlace” is interacted with, the signals “SendContainerMove” and “LoadToVoyage1” are activated. The signals “ViewLoadEGMList” and “EnterMarksAndNumbers” disappear from view.

Coding

The signal defines the interface. It defines the name of the interface and the values communicated when the signals are interacted. The signal is generated from the action with the signal operator.

A Signal contains two parts to it. One is the Signal or action name and the other is the elements carried when the signals interact.

The elements define the values carried when interactions happen. This is similar to parameters or data dictionaries in the case of algorithmic programming. When an element is defined it should also mention the type of element. The elements ensure the type checking at the element level during signal interaction.

<Element><elementName>Name</elementName><type>string</type> </Element> is the structure of the element definition. Each XML tag defines an attribute. Many elements can be defined together and uploaded into the Axon processor Repository.

The element tag defines the overall element. Each element tag has sub tags which give more information on the tag. The different sub tags are <ElementName> and <type>.

The element name defines the name of the element. This should be unique otherwise it will throw an error when it is added to the repository. The element name should not have spaces between it.

The element type gives the type of the element. When the actions interact, the system ensures that the elements passed are type checked. Axon ensures that only after type checking is successful would the interactions be considered complete. The different types available are a) string, b) date, c) number, d) boolean and e) name. Besides these defined element types, it is possible to have custom data types.

The string type accepts string. It takes alpha numerical string. There is no restriction for string.

The Date type accepts date. It has to be always in the DD/MM/YY format. Axon processor always checks to make sure that the parameter passed is of type date.

The element of type number accepts only number. This can take upto size of double i.e. Axon processor always checks to make sure that the parameter passed is of type number. The interaction will not take place if the passed element is not of type number.

The element of type name allows the system to share signals between processes or autonomous agents. This facility of the passing of names gives system flexibility and dynamism. With this, the system structure adapts, a globally unique first. This is also used extensively to share information privately in network applications.

In Axon language, if an element is defined as a type name with the name “approval” then it can carry only a signal of type “approval” through that element. This way the signal of type “approval” can be shared between two autonomous agents. This ensures that the system structure grows in a controlled manner in axon processor. I.e. information cannot be leaked to another agent in an unspecified manner.

In Axon processor, the signal is used to control the structure of the system and also how the data moves from one agent to another. Once the name moves from one autonomous agent to another, the autonomous agent that originally had the name would lose the name and it will move to the new autonomous agent. It is this property of axon processor of moving or mobile scope.

Axon processor does not limit the usage of names. I.e it allows circular references to the type name. I.e. it is possible to have an element of type name and it can itself contain the same type. This is not possible to be accomplished in any algorithmic-based systems.

As mentioned earlier the element type defines where data would be stored and ensures the element that is accepted by the system is valid. For fixed data type, these handling of data is automatic. But for custom data type, this needs to be explicitly defined. For example, to add a custom data type called “SocialSecurityNumber”, then the validation URL for the custom data type is provided in the validation URL and the storage is mentioned on the storage URL field. Only if the validation URL passes will the data be stored in the Storage URL.

Action in Axon language defines signal type. The signal is the actual experience of the signal in the axon processor.

Structure of an action can be seen below:

<Element>ElementName</Element>

<ActionName>ActionName</ActionName>

</Action>

Element (<Element>…</Element>)

Action Name (<ActionName>…</ActionName>)

The action name gives the name of the action which contains these elements.

In axon processor, systems are a network of interacting autonomous agent nodes. These nodes interact with each other through signals. For an interaction to happen there should be two potentials of the same type (same action name). One is the potential/capability/signals to deliver the information on this action and the other is the potential/capability to receive the information on the same action. Only when these two complementary potentials/signals come together the reaction or interaction happens.

Setting up the potential for an interaction and its configuration is left to the Operators. Axon language specifies these autonomous agent nodes and the interactions. signal operator and the configuration operators of the axon language setups up the node interaction sequencing.

Interaction is the movement of data from the source signal to the destination signal. The action by itself defines what types of elements will come across. It does not specify when and how the interactions have to happen. This is accomplished by converting the action into a signal by the TELL operator.

The interaction happens when signals of the same type but with the opposite delivery potential come together. A potential of information source is given by the TELL operator and the potential of receiving information is given by the ASK operator. When axon processor sees these operators, it sets up the connection potential or synapse.

Axon processor when it sees the two potentials does the interaction and moves the processes forward.

A potential of information source is given by the TELL operator. The “Tell” operator publishes the potential of the process to deliver information. This TELL signal is exposed as an internet wide nonce as a REST URL. If this is encountered in the process engine, then the process engine will wait till the complementary (published using the ASK operator) is published.

The Tell has the following structure,

<Tell>

</Tell>

<Tell>…</Tell>

Tell tag provides detailed description about particular action. It will wait for some other signal with the same name for process binding and step through the process to the next level. Within this tag, we have to define action which describes requested information from the user process and shown it to user. This action is defined like <action>…</action> and within this the action to be taken is mentioned with action name like <actionName>…</actionName> tag.

<action>…</action>

The required action to deliver information after process binding by using Tell operator is put into this action block with the specified name of action.

<actionName>…</actionName>

This actionName defines which action is to be performed by tell signal operator. We can use more number of actions for a single Tell operator by using their action name. This publishes a new action. The action name would be generated dynamically. This defines the signal type. Only signals of the same type interact.

<internal>…</internal>

This internal block will be responsible for controlling action visibility. The value of internal may be true or false. If internal is set to true then the actions are hidden and is not visible outside the autonomous agent. If it is false then it is visible outside the agent and can be accessed by any agent by only by its unique signal name. By default it is false. I.e it is public.

Tell operator publishes signals of the type that is specified in the action name. A signal can be hidden by making the internal turned to true. The hidden signals will not be visible to external systems. It will be hidden from view and will be available only to internal systems. A hidden signal can be accessed with signal name. If the TELL operator is encountered in the process engine, then the process engine will wait till the complementary (published using the ASK operator) is published.

The Ask (<Ask>…</Ask>) operator has the following XML structure:

<Ask>

</Ask>

<Ask>…</Ask>

<action>…</action>

The required action to deliver information after process binding by using Tell operator is put into this action block with the specified name of action.

<actionName>…</actionName>

<internal>…</internal>

The objective of Axon processor is to turn on and off what can be observed by a client. Things become observable when signal operator is activated. The sequence in which signals (signal operators) are activated and deactivated is accomplished by the configuration operator.

The different types of operators that make this possible are a) Sequence operator, b) Compose operator, c) Choice operator and d) Replicate operator.

The sequence operator ensures that all signal operators within the scope of the sequence operator, activate in sequence.

<Ask><action><actionName>AddPassage</actionName></action></Ask>

<Tell><action><actionName>InitiatePushToVoyage1</actionName></action></Tell>

</Sequence>

The code first turns on “AddPassage” signal, only on interaction of “AddPassage”, does it turn on “InitiatePushToVoyage” signal.

Other operators can be used within the sequence operator. This way of combining different configuration operators within sequence operator creates complex business processes.

<Ask><action><actionName>AddPassage</actionName></action></Ask>

<Ask><action><actionName>InitiatePushToVoyage1</actionName></action></Ask>

<Tell><action><actionName>InitiatePushToVoyage1</actionName></action></Tell>

<Tell><action><actionName>InitiatePushToVoyage2</actionName></action></Tell>

</Sequence>

</Compose>

<Tell><action><actionName>FinalInteraction</actionName></action></Tell>

</Sequence>

In the above case Compose is used within a sequence and Sequence is again used in compose. There is no restriction in the use of configuration operators. When this code sequence is activated, it will show “AddPassage” signal. On Interacting with “AddPassage”, it will activate compose node.

In the compose node, “InitiatePushToVoyage1” signals interact and what will be remaining will be “InititatePushtoVoyage2” signal. After the compose node reduces, and then “FinalInteraction” comes activated.

At end of this, only signals “InititatePushtoVoyage2” and “FinalInteraction” will be visible.

Compose operator ensures that all signal operators within the scope of this operator, are activated simultaneously.

<Ask><action><actionName>AddPassage</actionName></action></Ask>

<Tell><action><actionName>InitiatePushToVoyage1</actionName></action></Tell>

</Compose>

With this code, both “AddPassage” and “InitiatePushToVoyage1” signals become observable simultaneously.

Other operators can be used within the Compose operator. This way of combining different configuration operators within Compose operator creates complex business processes.

<Ask><action><actionName>InitiatePushToVoyage1</actionName></action></Ask>

<Tell><action><actionName>InitiatePushToVoyage1</actionName></action></Tell>

<Tell><action><actionName>InitiatePushToVoyage2</actionName></action></Tell>

</Sequence>

</Compose>

In the above case, Sequence is used within a Compose. There is no restriction in the use of configuration operators. When the above signal sequence is activated, it first activates the complementary InitiatePushToVoyage1, this interacts with each other and leaves “InitiatePushToVoyage2” signal as the final observation.

<Tell><action><actionName>ViewLoadEGMList</actionName></action></Tell>

</ChoiceOption>

<Ask><action><actionName>LoadToShipWithCurrentPlace</actionName></action></Ask>

<Tell><action><actionName>SendContainerMove</actionName></action></Tell>

<Tell><action><actionName>LoadToVoyage1</actionName></action></Tell> </Compose>

</OptionAction>

</ChoiceOption>

<Ask><action><actionName>EnterMarksAndNumbers</actionName></action></Ask>

<Tell><action><actionName>SendContainerMove</actionName></action></Tell>

</Compose>

</OptionAction>

</ChoiceOption> </Choice>

All data in the agent in Axon is global. i.e signal operators expose the same data elements in all the activated signals. If those signal operators are in a Replicate then it will have its own private data.

<Ask><action><actionName>PortToVoyageStore</actionName></action </Ask>

<Tell><action><actionName>ViewBeginningOfPassage</actionName></action></Tell> <AgentCommand> <AgentName>EditVoyagePortAgent</AgentName>

</AgentCommand>

</Compose>

</Sequence>

</Replicate>

Other operators can be used with in the Replicate operator. This way of combining different configuration operators with in Replicate operator creates complex business processes

<Ask><action><actionName>PortToVoyageStore</actionName></action </Ask>

<Tell><action><actionName>ViewBeginningOfPassage</actionName></action></Tell> <AgentCommand> <AgentName>EditVoyagePortAgent</AgentName>

</AgentCommand>

</Compose>

</Sequence>

</Replicate>

In the above case, the first signal is “PortToVoyageStore”. Each time this is activated, it creates a new private data store. Without the Replicate, the signal “ViewBeginingOfPassage” will point to the same data every time.

Agents are reusable components. Agents are used to group actions into a coherent entity.

The agent when it is instantiated can be either be part of the current agent namespace or it could spawn a new agent namespace.

The agent configuration operators in axon language triggers agent functionality. The Axon language which defines and triggers agent are as follows:

Agent in the current node

<Agent>

<AgentName>AnnualLeaveAgent</AgentName>

</Agent>

This code snippet is introduced in the axon code to add all signal sequences into the current node. This can be called over and over again to bring out the same signal sequences.

Agent spawning a new node

<Agent>

<AgentName>AnnualLeaveProcessAgent</AgentName>

<ProcessName>AnnualLeave</ProcessName>

<AvatarName>EmployeeName</AvatarName>

<Element>EmployeeName</Element>

<Element>DepartmentName</Element>

</Agent>

Agent triggering with a signal operator

<AgentName>AnnualLeaveAgent</AgentName>

<Ask> <action> <actionName>TriggerLeave</actionName> </action><internal>true</internal></Ask>

</AgentCommand>

This code snippet spawns the node “AnnualLeaveAgent”. It is spawned after the interaction on signal “Triggerleave”.

Agent triggering with no signal operator

<AgentName>AnnualLeaveAgent</AgentName>

</AgentCommand>

This code snippet spawns the node “AnnualLeaveAgent”. It is spawned automatically when it is encountered in code.

Other agents are of 3 types,

Arithmetic Agent
Decision Agent
Timer Agent

The arithmetic agent has the structure of,

<ArithmeticAgentCommand> <AgentExpression> Perform mathematical calculation </AgentExpression> </ArithmeticAgentCommand>

The arithmetic agent can be used for expressions that are hardcoded. It can also be used for dynamic expressions that are invoked from actions.

This is used for some arithmetic calculations. This allows a dynamic way of computing for specifying arithmetic expressions.

<ArithmeticAgentCommand> <ActionName> invoicetotalexpression </ActionName> </ArithmeticAgentCommand>

For example, this can be used as a sentinel to monitor a stock so it always look at the stock balance and reorder quantity and raises appropriate stock out signals.

The overall structure of the code is as below:

<TrueEvent><Ask><action><actionName>Sweet16</actionName></action></Ask></TrueEvent>

<FalseEvent><Tell><action><actionName>Gottcha</actionName</action></Tell></FalseEvent>

</Decision>

<Decision>….</Decision>

<Expression>….</Expression>

<TrueEvent>…..</TrueEvent>

This is the true event. This can have any ASK or TELL signal.

<FalseEvent>…..</FalseEvent>

This is the False event. This can have any ASK or TELL signal

The syntax of the timer agent is given below:

<Timer>

<Ask><action><actionName>Schedule</actionName></action></Ask>

<DateElementName> StartDate </DateElementName>

</Timer>

This is for a ASK signal. On the specified time mentioned in the DateElementName triggers the ask signal “Schedule” on that date.

<Timer>

<Tell><action><actionName>Schedule</actionName></action></Tell>

<DateElementName> StartDate </DateElementName>

</Timer>

This is for a TELL signal. On the specified time mentioned in the DateElementName triggers the tell signal “Schedule” on the start date.

Axon natively supports only Data, String, number and name data type. Further datatypes can be supported by using the feature of Axon processor to create additional data types. Creating such data types, allows users to extend the type system of Axon. The Axon system, ensures that the type is validated and stored in the assigned resources.

Process ID: An agent creates a new process, a new process id is created. This is a unique number generated by Axon.

TELL or ASK: Depending on the type of signal the appropriate TELL or ASK is shown here.

Below are the list of common URLs to get information from Axon processor on the Business flows designed:

/general/{domain} – Obtain All processes in a Domain
/general/{domain}/{process} Obtain all processes id’s in a Process and Domain
/general/{domain}/{process}/{pid} – Obtain all actions in a Process id and Domain
/general/{domain}/{process}/{pid}/{action} – Obtain all actions in a Process id, Domain for an action type
general/{domain}/{process}/{pid}/{action}/{id}/Tell – Obtain complete description of TELL signal
general/{domain}/{process}/{pid}/{action}/{id}/Ask – complete description of ASK signal
reports/general/{domain} – Obtain all actions in a domain.
reports/general/{domain}/{action} – Obtain all action instances in a domain.
search/{domain}?element=searchterm – List of all actions for search term in a particular domain.
search/{domain}/{process}?element=searchterm – List of all actions for search term in a particular domain and process.
search/{domain}/{process}?action=actionname&element=searchterm – List of all actions for search term in a particular domain and process with a given view.
search/{domain}/{process}?pid=processid&element=searchterm – List of all actions for search term in a particular domain and processid .
/history/general/{domain}/{process}/{pid}- History for a given process instance.
/history/general/{domain}/{process}/{pid}/{action}/{seqId} – History log detail
/settings/{domain} – Settings URI for the Axon domain