Lifecycle Configuration Elements

• org.wso2.jaggery.scxml.aspects.
JaggeryTravellingPermissionLifeCycle
• org.wso2.carbon.governance.registry.
extensions.aspects.DefaultLifeCycle 

• literal - Use this option when the lifecycle configurations are setup using the ES Management Console.
• resource - Use this option when the lifecycle configurations are setup via the registry.xml file.

This is the element that contains the new, SCXML-based configuration. State Chart XML (SCXML) is an open standard that ES supports. Up to this point of the configuration, there can be only one of each of the elements described above. They all provide metadata about the lifecycle (name, class, and other information). The subsequent elements are the actual SCXML configuration.

http://www.w3.org/2005/07/scxml

Defines the initial state of the lifecycle. The initial state does not have to be the first state of the configuration. Furthermore, by changing the value of this attribute, you can easily modify the initial state and the flow of the lifecycle.

Defines the states of the lifecycle. A lifecycle can have multiple states and if needed, you can define more than one state element in the configuration.

This element contains all the custom elements, which are defined in the lifecycle model. Based on the SCXML specification, you can define a data model to a lifecycle state and you can use this extension to define custom elements.

Custom data elements (according to the SCXML specification) serve to define check items, transition permission, transition validations, transition scripts, transition executions and transition UIs. This element describes the data of its child elements.

Defines the extension point (e.g., Transition Validators, Transition Executors, Transition User Interfaces and Transition Scripts) that is used in the lifecycle.

You can define only one extension point of a kind, because the underlined implementation ignores multiple elements and takes only one into consideration.

For transitionApproval, the following rules apply regarding roles and votes:

• • roles="" - Any user can vote
  • roles="admin" - Only users with an admin role can vote
     
  • votes="2" - Two votes are required for approval.

• checkItems - If the user is defining check items as its child elements.
• transitionValidations - If the data element defines transition validations.
• transitionPermission - If the data element defines transition permissions.
• transitionScripts - If the data element describes the transition scripts.
• transitionExecution - If the data element defines programmable executions for transitions.
• transitionUI - If the data element defines custom UIs that accept user input for transitions.
• transitionApproval - If the data element defines lifecycle transitions that need user approvals.

These elements contain the check items for each state. There can be more than one of these elements.

This element defines permissions for that specified action and holds more than one child element that defines permissions. Under check items, the permissions element defines the users that have the capability of checking (check/uncheck) that check item. If a user does not have permissions to check a check item, then the management console will display that specific item in disabled mode. Thereby, this helps a user to clearly identify what items he/she has the permission to check.

This element is a child element of the permissions element and will define the roles that have permissions to do the specified action. Here, the attribute roles accepts a comma (",") separated list and these roles should be present in ES.

Defines the validations that ES completes for each action. This element can contain one or more validation elements. Check Item validators are one of many well-defined extension points supported by ES.

This element defines the event and the validation class that is invoked at runtime.

Defines the event for which this validation should be performed. This gives you the flexibility to define validations for each event. As you have the ability to define validations for check items, it makes it easy to validate different things at different levels.

The parameter elements are used to pass parameters to the validation and execution classes. It is up to the user to define the name value pairs. A validation element or an execution element can have more than one parameter element, and it is up to the user code to handle this. The underline implementation of the DefaultLifeCycle class will pass all the parameters in a map object.

Defines the name used to identify the parameter.

ES lifecycle configuration has the ability to allow JavaScript functions to execute on both the server-side and the client-side. The js element defines the scripts that is executed for different events.

Defines the respective transition for which the JavaScript function is executed.

Defines the JavaScript function that ES needs to execute on the client-side.

Defines the name of the function that is executed when an asset moves from one lifecycle state to another.

Contains the actual JavaScript code segment. You can use this section to define any code segment.

The scripting language that is supported by ES.

This is the same as the console function and the only difference is that this element defines the scripts that are executed on the server-side.

Defines the name of the function that is executed at an asset transition from one state to another.

An executor is business logic that is executed once a state transition takes place in a lifecycle. The execution element defines the event and the execution class that is invoked at runtime.

Defines the event for which this execution is performed. This gives you the flexibility to define executions for each event.

The name attribute defines the name of the parameter and value attribute defines the corresponding value of the parameter. This parameter element is defined under the <execution> element.

This attribute defines the name of the parameter. 

• currentEnvironment - This defines the fully qualified path of the underlying resource at its current state (before the transition takes place).
  
  
• targetEnvironment - This parameter defines the fully qualified path to which the particular resource is transited when a particular state transition takes place which is defined in the "forevent" attribute of the <execution> element. 
   
• service.mediatype - This parameter denotes the MIME mediatype of the given service under the state transition.
  
  
• wsdl.mediatype - This parameter denotes the MIME mediatype of the WSDL file for the corresponding service under the state transition.
  
  
• endpoint.mediatype - This parameter denotes the MIME mediatype of the endpoint for the given asset type when the particular state transition takes place.

A UI element is a mechanism to associate a user interface with a particular event during a given transition. This allows you to pass inputs that would be utilized when performing a transition. Note that you can not define an external reference link as the href attribute value. Instead you need to provide a relative path in the Carbon server as the value of the href attribute.

Defines the event for which the UI appears.

Defines the transitions, by specifying the name of the lifecycle state and the target lifecycle state, instead of using static transitions. Any number of transitions for one lifecycle state are supported.

Defines the transition event name, e.g., Promote, Demote or any name that the user specifies.