Contents 1 Workflow Modeling and Generation 1.1 Model Creation 1.2 Model Creation 1.3 Package and diagram Creation 1.4 Workflow design 1.4.1 Workflow Toolbar Modeling 1.4.2 Workflow structure design 1.4.3 Activate/Deactivate SIDE Builder 1.5 Application 1.5.1 Creation 1.5.2 Configuration List 1.5.3 Configuration 'Models' tab 1.5.4 Configuration Generation tab 1.5.5 Configuration Deployer tab 1.5.6 %%% Data structure generation & deployment

Workflow Modeling and Generation

Usually, ECM application requires advanced workflows, for instance, to approve documents integration or to define sequence of tasks between project members to manage documentation. The following paragraphs give for beginners a basic overview of workflow modeling and generation and for users more familiar a quick solution for the need at hand. For additional information, Refer to the SIDE Workflow Modeling Guide.

Model Creation

Model Creation

The NewSideProject has already been created with the data model, so continue with it. Right click on your existing 'form' folderOr create your 'workflow' folder 'File / New / Folder'Folder Name / Click on 'Finish'Let's create a workflow model: File / New / Other... / SIDE / Side Workflow Model / Click on Next

Figure 1.1.  Workflow Model Creation pane

Enter the name of your model, for instance 'Digitization',the type of diagram Workflow' has to be selected and click on 'Finish'. Two files are created in your project:

• 'Digitization.workflow' is the 'actors' and 'tasks' model containing all the designed workflow structure;
• 'Digitization.workflowdi' is synchronized with the workflow model and contains the designed workflow structure complemented with the graphical information necessary to position the actors and tasks objects in the SIDE workflow modeler.

The 'Digitization.workflowdi' model is automatically opened in the SIDE workflow modeler. SIDE Modeler Layout

Package and diagram Creation

For all models, a good practice is to initially create the package structure in order to organize your design (like for Java program development), especially when you work in a team. For instance, the workflow structure of the Digitization.workflow model is automatically create under the package configuration org/myCompany/YaMma (replace myCompany with the name of your company) ever used for the data model. In fact, generally the creation of the workflow diagram is due to the creation of a data diagram before. In this case the package creation is already done. It is just necessary to click on the folder called 'workflow' automatically created by the importation of the 'NewSideProject'; then: 'Right click on YaMma / New / Other... / SIDE / Side Workflow Diagram'Click Next

Workflow design

Workflow Toolbar Modeling

The toolbar's modelers differs depending on the objects and the links require for their design. Here is the which one you need to model the workflow diagram.

Figure 1.2.  Objects Workflow Toolbar

Actor: an actor represents the user that manages one or many tasks of the workflow process. It is a mechanism to specify that multiple tasks in the process should be done by the same actor. So after the first task instance is created for a given swimlane, the actor should be remembered in the process for all subsequent tasks that are in the same swimlane. A swimlane must manage at least one task. Task: a task must be performed by a swimlane. A task can have one or more attribute. It represents one task that is to be performed by humans. So when execution arrives in a task, task instances will be created in the task lists of the workflow participants. Node: a node is a task that are no performed by actor. The type node serves the situation where you want to write your own code in a node. A node for example can fire a node-enter event and a node-leave event. Start state: a Start state represents the first state of the workflow process. Note that a process without a Start state is valid, but cannot be executed. A workflow process must have only one Start state. End state: an End state represents the final state of the workflow process. Having one is mandatory, but there may be several on the model. Sub process: a sub process is a state that is associated with another process definition. When graph execution arrives in the process state, a new process instance of the sub-process is created and it is associated with the path of execution that arrived in the process state. The path of execution of the super process will wait still the sub process instance has ended. Join: a join assumes that all tokens that arrive in it are children of the same parent. This situation is created when using the fork as mentioned below and when all tokens created by a fork arrive in the same join. A join will end every token that enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the (unique!) leaving transition. Fork: a Fork splits one path of execution into multiple concurrent paths of execution. It inherits of a transition task. Decision: a decision evaluates the attribute 'condition' of the leaving transition. The leaving transition with a true condition will be taken. If all conditions are false, the taken leaving transition will be the one without condition. Timer: a timer represents a temporal constraint. If it is associated to a transition, the transition will be taken when the Timer expires. Action: an action is a Java code that is associated to a transition. An action includes a Java Script. Event: an event specifies a moment in the execution of the process. It is always relative to an element in the process definition like the process definition, a node or a transition. Most process elements can fire different types of events. Attribute: an attribute specifies properties for 'Task', 'Start state' and 'End state'.

Figure 1.3.  Links Data Toolbar

Transition: a transition represents a link between two nodes/tasks. The transitions must have a source node and a destination node. Manage: a manage represents a link between an actor ans a task. Initialize: an initialize represents a link between an actor and a Start task. Action: an action represents a link between a Java Script code to a transition. Has timer: an has timer links a Timer to a transition. Reference class: a reference class enables to create an association between a task and a class, when the data model has been linked to the workflow process.

Workflow structure design

Click on the Actor item of the objects list of the left panel. Then click in the Main panel. Click on the 'Digitization System' element and look on the down part of the IDE window. Click on Properties tab to access the Properties view. SetDigitization Systemto the Name and the Pooldactors. It isn't necessary to set the Actor ID corresponding to one user name, when a pooldactors is created. Next, complete Description and Documentation if necessary:

Figure 1.4.  Actor Element creation

Proceed the same way to create two other actors 'Mailand 'Manager' doing the same things and put actors in column, one below the other. Note: think about saving your model regularly! On the left part, click on StartState in the object list and then click on the'Main graphical working part, to put down this first task. Next click inside the green square and set 'Start' to the Name and 'Digitise' to the Title in the Properties pane. Next, complete Documentation and State Description if necessary. Then always on the left panel, click on the 'Manage' item of the Links list. Then click on the 'Digitization System' Actor and on the 'Start' task: two elements are linked by a blue arrow. Note: in the Properties pane the 'Initiator' line of the 'Start' Task is automatically completed by 'SwimlaneDigitizationSystem. Click on Task item in the Object list and then click on theMain graphical working part, and proceed the same way to create 'ManageMail' task manage by 'Mail' actor. In the Properties pane, change the default name 'TaskNode1' by 'ManageMail'. Write the same thing on State Description and on Title. Create also 'Approve' task manage by 'Manager' actor, and set 'TaskNode1', Title and StateDescription by 'Approve'. Click on Attribute item in the Object list and then put it down in the 'Approve' task. In the Properties pane complete the Name and the Title by'Comment'. Note that the Type is automatically completed byString, but you can be change by choosing other values in the list proposed. Click on Transition item in the Object list and then click on the Start Task and next on the 'ManageMail' task. Click on the Transition and complete the Name and the Title by 'MetadataInput'. The field 'To' is automatically completed by 'Task Node ManageMail'. Proceed the same way, and create a transition linking 'ManageMail' and 'Approve', called 'AskApprove'. Put an End State just called 'End' in the 'Main' pane and link it with 'Approve' by using a Transition' called 'toEnd'. 'Right click on 'Transition1''Choose 'Ajouter une action' [Add an Action] > Alfresco > Create new contentSpecify the code followed: var node =bpm_package.children[0]; node.specializeType('DigitizationProcess:com_bluexml_side_models_liste_InboxMail'); Validate your model by clicking on the green arrow present in the Eclipse toolbar. The final model looks like this:

Figure 1.5.  Final Workflow Model

Activate/Deactivate SIDE Builder

Activate or deactivate the SIDE builder enables to control the dependency between different models. In case of creation, extinction, modification, transfer or another action, the builder traces information, control and indicate dependencies in the 'Problems' pane near the 'Properties' tab. 'Right click on your project 'GTYaMma''Go to SIDE / Click on Activate/Deactivate SIDE builderThe SIDE blue circle icon turns green. A .metadata folder is created. If a problems occurs, a red arrow appears in the Problems pane indicating the resource concerned by the error (for example the .form), the path where to find, and the type of the error, whether this is an SIDE, EMF error. The error occurs only when the models are recorded. This basic workflow model indicates that three new content types have been created: one to declare specific content type associated to a document, others to declare an Inbox and Outbox mails contents. We will now proceed to the generation of the data elements on a targeted framework like Alfresco.

Application

Creation

Prior to generate the workflow model, we must create an Application model which will store the description of our application and its components. Right click on 'models' in the Navigation pane and select: New / Other / SIDE / Side Application Model

Figure 1.6.  Application model creation

Enter the File name 'Digitization.application' and click on Finish. The application model 'Digitization.application' is created in your project. Note that if your have modeled and generated a data diagram before, you already have a Digitization.application model. Reuse it for generate the workflow model. Select this file and right'Click to open the contextual menu'Select the menu item SIDE / 'Manage Configuration'to start the panel in which we will declare the steps of generation of your application. The application generation configuration is divided in 4 main parts.

Configuration List

The List of configurations allows defining several generation configurations. The first time there is no configuration and you must click on the green circle (with the little white arrow inside) to create the first configuration labeled by default 'New Configuration'. Click on the item representing a white page (with a little pen), to change the name of the configuration: Enter 'Main' in the name of the configuration input view. You may create several configurations all along your project: for instance, after finalizing a functional layer of your application, it is no more necessary to generate and deploy it all the times with the models you are working on. When you ever have configure your model .application, reuse start the configuration from the following 'Models' tab.

Configuration 'Models' tab

The 'Models' tab allows to declare the models you want to generate on the targeted frameworks.Click on 'Add Models' and select 'Digitization.dt' under 'myProject(GTYaMma)/src/models/workflow'. You can add as many models as you need for your application.

Figure 1.7.  Models Tab

Configuration Generation tab

The 'Generation' tab allows selecting the generators you want to use on top of the models you declare in the 'Models' tab : the selected generators produce the artifacts on specific frameworks they are associated to.This pane proposes, in the upper part, common options to set up:

• 'Log path' must be set up to indicate where to store the log of the generations; enter /GTYaMa/build/logs.
• Generation path' must be set up to indicate where to store the result of the generations; enter /GTYaMa/build/generated.
• Click on 'Skip validation' if you do not want to perform model validation before generation. Model validation is by default automatically performed to avoid generating on incorrect or inconsistent models. But, if you are sure that your models are valid (use 'Validate' to perform a direct validation), select this option.
• Click on 'Documentation generation' if you want to generate the documentation associated to your models. This feature will generate an .odt file that you can find under

GTYaMma / build / logs / Main(name of your configuration) / doc / Digitization-dt.odt

• The first level indicates the type of metamodel.Note that if you select a meta-model but you do not have declared under the models tab at least a model conform to this metamodel, obviously no generation will be performed.
• The second level indicates the targeted technology: this is the kind of framework on which a part or all the application must be deployed. For instance, 'Alfresco' is a technology.
• The third level indicates the version of the targeted technology.
• The fourth level indicates the generator to use: it may exist several generators for a metamodel, a framework and a release.
• The fifth level gives the generation options.
• The first level indicates the type of metamodel.Note that if you select a meta-model but you do not have declared under the models tab at least a model conform to this metamodel, obviously no generation will be performed.
• The second level indicates the targeted technology: this is the kind of framework on which a part or all the application must be deployed. For instance, 'Alfresco' is a technology.
• The third level indicates the version of the targeted technology.
• The fourth level indicates the generator to use: it may exist several generators for a metamodel, a framework and a release.
• The fifth level gives the generation options.
• Click on 'Documentation generation' if you want to generate the documentation associated to your models. This feature will generate an .odt file that you can find under

GTYaMma / build / logs / Main(name of your configuration) / doc / Digitization-dt.odt

• The first level indicates the type of metamodel.Note that if you select a meta-model but you do not have declared under the models tab at least a model conform to this metamodel, obviously no generation will be performed.
• The second level indicates the targeted technology: this is the kind of framework on which a part or all the application must be deployed. For instance, 'Alfresco' is a technology.
• The third level indicates the version of the targeted technology.
• The fourth level indicates the generator to use: it may exist several generators for a metamodel, a framework and a release.
• The fifth level gives the generation options.
• The first level indicates the type of metamodel.Note that if you select a meta-model but you do not have declared under the models tab at least a model conform to this metamodel, obviously no generation will be performed.
• The second level indicates the targeted technology: this is the kind of framework on which a part or all the application must be deployed. For instance, 'Alfresco' is a technology.
• The third level indicates the version of the targeted technology.
• The fourth level indicates the generator to use: it may exist several generators for a metamodel, a framework and a release.
• The fifth level gives the generation options.

Click on the label of each level to have description in the upper right part of the window.

Figure 1.8.  Generation Tab

To select a particular generator to apply on your models, first click on the circle checkbox of the metamodel first level, then on the technology second level, then on the version third level and then on the generator. Click on: KSR600 Workflow / Alfresco-jBPM / Alfresco 3.x Labs and Enterprise / SIDE Workflow Generator for AlfrescoSome parameters of the generator must be set up on the right lower table of the window. For instance, for the SIDE Workflow Generator for Alfresco it is necessary to set up the Module Version if you want to keep an historic of the generated artifacts. Click on: Save [Enregistrer]to save the generation configuration.

Configuration Deployer tab

The Deployer tab contains a single tree similar to the generation one but without the first metamodel level. The purpose of the deployer tree is to select installed framework instance to install generated artifacts on them. Let's suppose that you follow the SIDE Installation guide and that you installed Alfresco 3.2 Enterprise. In the deployment tree, you can select: Alfresco / Alfresco 3.x Labs and Enterprise/ SIDE Content Model Generator for Alfrescoto indicate that you want to deploy the generated artifacts on this special instance of Alfresco: in this case, all the models which have been generated using generators on the technology 'Alfresco' and the release '3.x' will be deployed on this Alfresco instance through the SIDE Alfresco deployer. SIDE is now compatible with Alfresco 3.2 r2.

Figure 1.9.  Deployer Tab

Click on: Save [Enregistrer]to save the deployer configuration. It is important to note that deployers are independent of meta-model; for instance, the SIDE Alfresco Deployer will deploy on the same Alfresco instance artifacts generated with a Data model and a Workflow model. Deployers are based on the deployment technique of the targeted framework. The SIDE Alfresco Deployer uses AMP Alfresco Module Package and WAR files to deploy the generated artifacts on Alfresco instance. On selection of a deployer, you usually have to set up some parameters which indicate where is installed the framework instance: for instance, for the 'SIDE Alfresco deployer'. If you previously install Alfresco on your machine, you can set up the Tomcat Installation directory to point on the 'tomcat' directory of Alfresco. You need to stop Alfresco before running the generation & deployment to avoid conflicts during deployment.

 %%% Data structure generation & deployment

At this point we can launch the generation of our 'Digitization.workflow' model. Click on' Launch [Lancer]Note: you can also launch the generation of one specific application configuration directly by right clicking the application model file and selecting 'Launch Generation': SIDE / Launch generation / 'NameOfYourConfiguration'

Figure 1.10.  Quick launch of generation

A generation window is opened and displayed the generation steps. Click on 'Background' if you want the generation to be done as a background job in order to let you continue with other tasks. At the end of the generation, it indicates if the generation is complete with or without errors. In case, there is error, errors are listed in the window and in the log files (one per generator) under the log paths. In case of no errors, the generation path will contain all the generated artifacts.

Figure 1.11.  Generation and Deployment Window

Moreover, the 'side_report.xml' page has been generated in the logs path and gives information on the generation process. You can load this page directly in a browser:

• 'Stats' gives a consolidated view of the generation for all the generators and deployers and per generator and deployer.
• 'Generators' gives a detailed view of the generated artifacts per generator: you have access through this view to all the generated artifacts.
• 'Deployers' gives a detailed view of the deployed package per deployer: you have access through this view to the package the deployer has deployed on the targeted frameworks. These packages may be deployed on other instances of the framework on other machines.
• 'Documentation' gives access to the generated documentation for all the models declared in the application configuration.
• 'Services' gives entry points to load per generator all the services which have been generated and deployed on the targeted framework instances.
• 'Console' is an exact copy of the logs displayed in the generation console.

Figure 1.12.  SIDE : MDA report procedure

The SIDE Alfresco deployer deployed the generated artifacts on the Alfresco instance. In order to check that the new content type has been created, connect to the Alfresco Explorer and create a new content: in the content type list, you will see Document, InboxMail, OutboxMail; create one of each of them to access metadata form. 'Next select the arrow corresponding to More Actions, and click on 'StartAdvancedWorkflow'. Then, Select 'Choose Workflow''Click on 'Next''Select your 'Workflow Options''Click on next.You can start the workflow now !

Figure 1.13.  Start a specialized advanced Workflow Digitization

Category:GettingStarted