XPDL WORKFLOW FOR INTEGRATION OF CMDBUILD AND OCS INVENTORY SYSTEMS
Valentin Penca, Siniša Nikolić, Miroslav Zarić {valentin_penca, sinisa_nikolic, misroslavzaric}@uns.ac.rs
Fakultet tehničkih nauka u Novom Sadu Abstract – This paper describes basics of the CMDBuild
and OCS Inventory systems and proposes a method for their integration. Integration is based on workflow management of the CMDBuild system which uses XPDL for collaboration and Enhydra Shark engine for interpretation. The XPDL process which provides integration of OCS Inventory and CMDBuild is presented.
1. INTRODUCTION
Technology of business processes flow (Workflow technology) [1] is about set of standards which describe how to incorporate flows in IT structures. The business processes flow (workflow) is composed of a sequence of related steps. These steps describe a series of operations that are performed by process participants (whether they are individuals or groups). Workflow represents the real- world activity or its part by defining a specific virtual representation. System for managing the business processes flow (Workflow Management System-WMS) [1] allows the definition and organization of various activities related to business processes. WMS system achieves full potential if it is integrated with some other systems like database, document and configuration management system and geo-information systems.
WfMC (Workflow Management Coalition) [2] has defined a generic reference model (Workflow Reference Model), which describes the standard for the development of IT solutions with support for business processes flow.
Core of the model is Workflow Engine (WE), which is key software component for management of modelled processes.
The WE model contains five independent Interfaces (Figure 1). Process Definition Tools is a formal tool for specifying the definition of the process. The second (Client Apps) and the fifth (Administration and Monitoring Tool) interface are realized with different type of clients (applications), which role is managing, monitoring and participating in the process flow. Tool Agent is a link between WE and various client applications that are actively participating in execution of business processes.
OCS inventory [3] is a specialized open-source software system designed to manage the computer configuration.
The basic purpose of the system is establishing and monitoring the hardware entities in a network (workstations, laptops, servers ...). Common functionality of OCS is creating and maintaining "up to date” records from all network infrastructure components.
Figure 1 - Workflow reference model
CMDBuild [4] is an open-source system aimed at modeling and maintaining a database that contains assets and a description of workflows. CMDBuild stores objects, objects interconnections and their history. This system has a special communication structure that can collaborate with other information systems. Collaboration is done by a workflow which is defined by XPDL (XML Procces Definition Language) [2] language and with exchange of SOAP messages among systems. For interpretation of process in CMDBuild, Enhydra Shark Workflow Server [5] (processes management server) is used.
1.1. XPDL
XPDL is the XML schema for the business processes flow. Basic concepts in XPDL are realized with the meta- model and vocabulary that represent a framework for specification of real-world business process. Meta-model identifies used entities, their relationships and attributes from the definition of the process.
XPDL contains information about the graphic elements of the process as well as its possible activities. The main advantage and innovation introduced by the XPDL, in comparison to other standards, is merging the information from graphical representation elements with the activities that the process should perform.
2. ENHYDRA SHARK ENGINE
Enhydra Shark (ES) is a Java based system for managing the business process flow. Enhydra Shark engine is implemented as a library which must be integrated into some WMS.
ESE architecture is represented by a series of software API [5]. Three major API groups are: shark client API, shark kernel and shark plug-in API .
Shark has a modular architecture which allows easy replacement of standard components with new ones. In
the following, the most significant components of ESE will be briefly discussed.
OMG and WfMC APIs are client core API and their role is initialization, deleting and stopping of process and/or theirs activities. XPDL Package Administration API manages the XPDL files. This API displays a list of uploaded files and their versions and performs uploading, updating, deleting and retrieval of XPDL files.
Shark kernel is the "connective tissue” that connects the implementation of client API's and implementation of internal components (plug-ins).
2.1. ESE PROCESS LIFE CYCLE
The first phase of process life-cycle within the ESE uses client core APIs. These components use XPDL process definition as a template for creating multiple instances of the process. During the execution of the processes all of process activities are created. For the purposes of activity execution, variables are created for the context of the process or activity.
The ESE workflow can be automatic (there is no influence from outside on the workflow), manual (changing the workflow during the execution) or combined.
During the workflow execution, ESE interacts with users which can update processes, activities and variables.
Based on user input and values of variables ESE decides which activity will be executed next.
Process activities are automated using the Tool Agents (Figure 1) [6].
3. TOGETHER WORKFLOW EDITOR
Together Workflow Editor (TWE) [7] is the tool that provides modeling of XPDL process based on meta- model. Meta-model represents a minimum set of objects which must be supported by TWE.
Figure 2 presents an organizational model of XPDL entities in TWE. Defined hierarchy represents the base entities and the structure of a XPDL file.
Figure 2 - Organizational model of XPDL entities in TWE
At the top of the hierarchy is the Workflow Package. The package acts as a container for grouping: multiple individual processes (Workflow Process), participants in the process (Workflow Patricipiant), applications (Workflow Application) and their associated data (Workflow Relevant Data). TWE provides the method of
External References among their packages. This method involves reusing of defined components (participants, applications, processes, external application) in the packages. Method External References uses Resource Repository entity.
Resource Repository allows the mapping of external definition on the elements in the process.
Workflow participants in TWE are part of the minimum organizational model that is defined by WfMC meta- model. Participants are described with type and the corresponding type attributes. There are six basic types of participants: resource set, resource, organizational unit, role, human, system. Role and resource participants are abstract participants.
Workflow Application element is used to specify the applications/tools invoked by the workflow processes defined in a package. Two types of invocation parameters are used in applications: formal parameters and external references. Formal parameters are values of data types defined within the package, while external references are paths to the outside entities.
Workflow Relevant Data (in TWE Data Fields) defines all data objects, which can be used during the process execution. Each Value can be simple (predefined in TWE) or complex (user defined by combination of the simple types).
Workflow Process Activity is the basic functional unit of the process which is executed by the user. Flow of process is defined in TWE by combining a series of consecutive activities.
In TWE there are four types of activities: Generic, ROUTE, BLOCK, SUBFLOW. Every type of activity has a different graphical representation. Activities in TWE have Activity Body and the input and / or outgoing transitions to other activities. Activity Body is a reserved space for activity implementation. Tool activity is a Generic activity with Activity Body.
Transitions are the connection between the two activities.
They also describe the condition, which must be satisfied in order to get from the source to the target activity (this condition is evaluated during the workflow execution).
There are two types of transitions: incoming (join) and outgoing (split). For both types of transition there are two possible interpretations (AND and XOR). AND indicates that all incoming / outgoing activities must be present in order to execute the next activity, while XOR indicates opposite.
TWE provides a graphical representation for process definitions, which is compliant with the WfMC specification. Graphical representation of the workflow is defined by participants that are represented with particular swimming lanes and with the activities that have special graphical symbols. Activities must be located in the swimming lane of the participant. Process flow in the TWE is achieved by using the transition. Transitions are the links between activities in process. Figure 3. depicts graphical symbols for types of activities.
Figure 3 – Type of activities in TWE
In addition to the described structures/symbols that are consistent with the XPDL standard, there exist in TWE some structures not being part of the XPDL specification mainly used for a comprehensive and intuitive graphical representation of the process (for example: structure that represents the beginning and the end of the process).
4. IMPLEMENTATION OF THE PROCESS FLOW The motivation for integration of CMDBuild and OCSInventory systems was to provide a comprehensive solution to manage information about hardware resources and personnel that works with these resources. Integration of these two systems is done by defining the pattern (template) for communication between the two systems.
Designed template is described using XPDL standard; the phases of communication and the data formats are defined.
The result of integration is periodical transfer of data in accordance with defined data mapping from OCS Inventory to CMDBuild. Here, CMDBuild is using ESE for interpretation of process and received data.
CMDBuild administrator mode is used for importing the XPDL process definition (XPDL file). It is necessary to specify the path to the imported file and to set the process name. Defined process name must match with process name set in XPDL file.
OCS Inventory system does not support direct communication with CMDBuild or ESE. The problem of direct communication of these two systems is resolved by using JAVA library External-connectors that comes with full distribution of CMDBuild. This application is an intermediary in the transfer of data between mentioned systems. Prior to initiation of data transfer, it is necessary
to provide a configuration structures in CMDBuild to which data from the OCSInventory will be mapped. Based on these structures and data structures from OCSInventory, the rules for mapping of IT resources are defined [8]. External-connectors is starting the process of collecting data with direct access to IT resources of OCS Inventory database, which is based on the elements of mentioned mapping. Also, External connectors initiates the creation of process instance in the ESE, which is based on imported process definition in CMDBuild. After the process is initiated, External-connectors sends request to the ESE in order to obtain information about relevant data currently stored in the CMDBuild database. The response to the received request is formed through a series of activities that are using Tool Agents. Main Role of the Tool Agent is to obtain the information from the CMDBuild database. Instantiated process in the ESE integrates a collected data from Tool Agents and waits for the External-connectors to collect data. Afterwards, External-connectors compares data from both systems and forms a set of add, update and delete request for CMDBuild database. The set of requests is passed to the process in ESE, which interprets the requests and invokes the appropriate Tool Agent for storing data in CMDBuild database. If all activities are successfully completed, the process is being terminated, otherwise an error message will be displayed in CMDBuild.
5. KEY SEGMENTS OF THE PROCESS
For design of process the graphics editor TWE version 3.3.1 has been chosen. Created process (Figure ) contains
participants System and Inventory.
Figure 3 – Workflow of integration Participant Inventory is the External-connectors
application, which initiates the workflow and defines the initial variables values of process for the other participants. Participant System (ESE) is conducting a series of activities in which the structures and the methods for representation and modification of CMDBuild database are defined. These new structures in the ESE are used for temporary mapping of CMDBuild data and data received from the OCSInventory. The structures are implemented as JAVA auxiliary classes in ESE. In the process this structures are represented with suitable types (Listing 1) of parameters and/or attributes.
<xpdl:TypeDeclaration Id="References"
Name="References">
<xpdl:ExternalReference
location="org.cmdbuild.workflow.type.Reference Type<>"/>
</xpdl:TypeDeclaration>
<xpdl:TypeDeclaration Id="CardUnits"
Name="CardUnits">
<xpdl:ExternalReference
location="org.cmdbuild.workflow.type.CardUnit&
lt;>"/>
</xpdl:TypeDeclaration>
Listing 1 - Types of parameters
Class CardUnit (Listing 2,3) processes received request and thereby collects name of hardware/ software entity, attribute names and identifiers (code) of OCS Inventory entities from the External-connectors class. Mentioned class is using class ReferenceType as a storage
container for identifiers (keys) of CMDBuild database.
The keys are obtained by mapping the class name of required hardware/software entities and the identifiers of the entities from OCS Inventory on correspondent CMDBuild elements. ReferenceType is a generic structure that contains basic information about the entity from CMDBuild. Also, CardUnit stores attribute values for each code from OCS Inventory in the structure atributeValues (multidimensional array).
public class CardUnit {
public String className = ""; //name for class e.g. Computer/Memory
public String [] codes;//list of ID for a single type configuration in OCS
public ReferenceType [] references;
//contains id's for single combination of className and code from CMDbuild
public String [] attributeNames;
//attributes to be retrieved
public String [][] attributeValues;
//attribute values for every code
… }
Listing 2 - Class CardUnit
<xpdl:DataField Id="Cards" IsArray="TRUE"
Name="Cards">
<xpdl:DataType>
<xpdl:DeclaredType Id="CardUnits"/>
</xpdl:DataType>
Listing 3Using of type CardUsints
Activities in the Figure , are exchanging data among each other by placing the results of application (ToolAgent) in global variables of the process (Data Fields).
Start represents the starting activity of the workflow that is initiated by the participant Inventory. It is a generic activity that does not contain any implementation.
In this activity, External-connectors sets the request parameters for CMDBuild data using a special Extended Attribute VariableToProcess_UPDATE (Listing 4).
This attribute allows to the participants to access and change the variables values in the process.
<xpdl:ExtendedAttribute
Name="VariableToProcess_UPDATE"
Value="classRequested"/>
Listing 4 - Extended Attribute VariableToProcess_UPDATE
createCardDataFilter is the first in a series of activities that is performed by System (CMDBuild). The generic activity CmdBuildSelectedData contains applications call in its body. Application obtains a request from the External-connectors through Formal Parameter classRequestedIn. Needed structures are defined (array of classes CardUnit is created) in the processing of the request. Application CmdBuildSelectedData executes defined JAVA code and it is necessary to provide interpretation of JAVA code. ESE interprets JAVA code by usage of the ESE BshToolAgent. JAVA code contains the parsing procedure for the request of the External- connectors. Parts of parsed request will serve as the basis for creating objects of class CardUnit, where the number of objects is defined by the number of tokens. This is shown on Listing 5.
<xpdl:FormalParameter Id="classRequestedIn"
Index="classRequestedIn" Mode="IN">
...
<xpdl:ExtendedAttribute Name="Script"
Value="StringTokenizer tokens = new
StringTokenizer(classRequestedIn,"\n"); Cards
= new org.cmdbuild.workflow.type.CardUnit [tokens.countTokens()];
int i = 0;
while(tokens.hasMoreTokens()){
String token = tokens.nextToken();
org.cmdbuild.workflow.type.CardUnitcardUnit = new
org.cmdbuild.workflow.type.CardUnit(tokens);
Cards[i]=cardUnit;i+=1;}"/>
<xpdl:ExtendedAttribute Name="ToolAgentClass"
Value="org.enhydra.shark.toolagent.BshToolAgen t"/>
Listing 5 - The basis for creating objects of class CardUnit
Activities retrieveInformationCardUnit, retrie- ve, CardInstanceByCode, retrieveCard- InstanceByCode, route, retriveAttribute- ForCode are emulating cycles and sub-cycles during the execution of the process. Activity retrieve- InformationCardUnit (Listing 6) is used to extract CardUnit elements from the array (main cycle). Each extracted CardUnit element is used to set currentCard (element of array - the objects of class CardUnit) and cardClassName (name of required class of hardware/software entities) variables of process. For iteration of the main cycle the currentIndexCard variable is used. At the end of the activity iterator of sub- cycle is annulled.
<xpdl:Activity Id="retriveInformationCardUnit"
Name="retriveInformationCardUnit">
...
<xpdl:Tool Id="nextCardUnit"
Type="APPLICATION">
<xpdl:ActualParameters>
<xpdl:ActualParameter>Cards</xpdl:ActualParame ter>
<xpdl:ActualParameter>currentIndexCard</xpdl:A ctualParameter>
<xpdl:ActualParameter>currentCard</xpdl:Actual Parameter>
<xpdl:ActualParameter>cardClassName</xpdl:Actu alParameter>
</xpdl:ActualParameters>
</xpdl:Tool>
...
<xpdl:Tool Id="resetCouter"
Type="APPLICATION">
<xpdl:ActualParameters>
<xpdl:ActualParameter>currentIndexCode</xpdl:A ctualParameter>
</xpdl:ActualParameters>
...
Listing 6 - Activity retrieve-InformationCardUnit RetriveCardInstanceByCode (Listing 7) represents the first sub-cycle for currentCard element, which role is to pass through a series of OCSInventory identifiers.
Result of calling of selectReferenceByCode with parameters classname and code is an object of the type Reference (OutRef) . Iterator for this cycle is currentIndexCard. At the end of this activity the iterator of next sub-cycle is annulled.
<xpdl:Application Id="selectReferenceByCode"
Name="selectReferenceByCode">
...
<xpdl:FormalParameter Id="ClassName"
Index="ClassName" Mode="IN">
<xpdl:DataType>
<xpdl:BasicType Type="STRING"/>
</xpdl:DataType>
</xpdl:FormalParameter>
<xpdl:FormalParameter Id="Code" Index="Code"
Mode="IN">
<xpdl:DataType>
<xpdl:BasicType Type="STRING"/>
</xpdl:DataType>
</xpdl:FormalParameter>
<xpdl:FormalParameter Id="OutRef"
Index="OutRef" Mode="OUT">
<xpdl:DataType>
<xpdl:DeclaredType Id="Reference"/>
</xpdl:DataType>
</xpdl:FormalParameter>
...
Listing 7 - Appliaction RetriveCardInstanceByCode Route (Listing 8) serves as a decision node and defines the directions (transition) to the other activities during the process. This activity has 3 exclusive (XOR) courses.
If the process variable OutRef is null and if the passing through the list of codes of current currentCard is not finished, the process will be directed to the re-execution of the retriveCardInstanceByCode.
CreateXMLStructureForCard will be executed if the passing through the entire list of codes of current currentCard is finished. The third possible process flow is unconditional and leads to retriveAttributeForCode activity.
<xpdl:Transition From="route"
Id="Process_importocs_tra14"
To="retriveCardInstanceByCode">
<xpdl:ConditionType="CONDITION">(codeRef==null )&&(currentIndexCode<=currentCard.g etCodesLength())</xpdl:Condition>
...
Listing 8 - Activity Route
RetrieveAttributeForCode demonstrates a last subcycle in which the list of attribute values for currentCode will be obtained. For this purpose selectAttributeFromReference ToolAgent is used.
Input parameters of this ToolAgent are ObjReference (object specific code) and attributName. The result of the ToolAgent call is attribute value retrieved from CMDBuild database. After that the retrieved values are inserted in CardUnit (currentCard) by calling of setValueForAttribute application (Listing 9).
Outputs from RetrieveAttributeForCode activity are two transitions. One represents the exit from all cycles of the currentCard and another leads back to the retriveCard-InstanceByCode (higher level cycle).
<xpdl:Application Id="setValueForAttribute"
Name="setValueForAttribute">
...
<xpdl:ExtendedAttributes>
<xpdl:ExtendedAttribute Name="Script" Value=
"currentCard.setAttributeValue
(currentCode,attributeName,attributeValue);"/>
<xpdl:ExtendedAttribute Name="ToolAgentClass"
Value="org.enhydra.shark.toolagent.BshToolAgen t"/>
</xpdl:ExtendedAttributes>
...
Listing 9 – Application setValueForAttribute createXMLStructureForCard (Listing 10) is responsible for creating the output data structure as a string that is stored in a process variable classDataRetrieved. If there are more instances of unprocessed CardUnit, the transition from this activity will lead to the retriveInformationCardUnit (basic cycle). Otherwise the transition will lead to loop activity.
Complete “image” of the CMDBuild is obtained by passing through all cycles and sub-cycles of the process.
<xpdl:Application
Id="createXMLStructureforCard" ...
<xpdl:FormalParameter Id="currentCard"
Index="currentCard" Mode="IN">
...
<xpdl:FormalParameter Id="classDataRetrieved"
Mode="INOUT">
...
<xpdl:ExtendedAttributes>
<xpdl:ExtendedAttribute Name="Script"
Value="classDataRetrieved=classDataRetrieved+c urrentCard.getXMLStructure();"/>
...
</xpdl:Application>
Listing 10 - Application createXMLStructureForCard
Activities loop and waitForUser are used to simulate the wait state of CMDBuild in which the External- connectors will take the requested information (classDataRetrieved). Because of the possible scenario where External-connectors can not take data for some reason (failure caused by someone or something) the whole process will not terminate. Therefore, it was necessary to define the maximum duration of the process as in listing 11.
<xpdl:ProcessHeader DurationUnit="m">
<xpdl:Created>2009-06-19 16:30:25
</xpdl:Created>
<xpdl:Limit>20</xpdl:Limit>
</xpdl:ProcessHeader>
Listing 11 - Maximum duration of the process CallSyncWS (Listing 12) receives new request from External-connectors. Request is a hierarchy of CMDBuild elements, each representing actions that are changing the state of CMDBuild database. Final request processing is performed by ExternalSyncToolAgent.
<xpdl:Activity
Id="callSyncWS"Name="callSyncWS">
<xpdl:Implementation>
<xpdl:Tool Id="externalSync">
...
<xpdl:Application Id="externalSync"
...
<xpdl:ExtendedAttributeName="ToolAgentClass"
Value="org.cmdbuild.shark.toolagent.ExternalSy ncToolAgent"/>
...
Listing 12 - Activity CallSyncWS.
5. CONCLUSION
In this paper ESE was used for the purpose of integration of CMDBuild and OCS Inventory. Integration is based on XPDL process that is modeled using tool TWE. The example illustrates potential of the workflow management based on XPDL and how WMS (ESE) interprets a real workflow process. Integration results are interrelated data from the both systems stored in the CMDBuld database.
The improvement of CMDBuild achieved by this integration is configurable set of data that can be automatically collected from OCS Inventory, while regarding the OSC Inventory improvement is the indirect possibility to organize and link data about computer resources with physical locations (buildings) and users.
The further development of the system, due to the increasing need for information interoperability among multiple systems and workflow features related to reporting and controlling activities, will be directed towards extension of the set of systems supported and full utilization of wokrflow capabilities for IT infrastructure management.
6. REFERENCES
[1] Cichocki A., Ansari H. A., Rusinkiewicz M., Woelk D.,
“Workflow and Process Automation: Concepts and Technology”, Springer, December 1997, ISBN-10:
0792380991, ISBN-13: 978-0792380993 [2] WfMC - http://www.wfmc.org/
[3] OCS Inventory - http://www.ocsinventory-ng.org/
[4] Zarić M., Kovačević A., Konjović Z., “Open source cmdb systems”, Zbornik radova YU INFO 2009 (CD), 6 p.
[5] SHARK - http://www.enhydra.org/
[6] Tool Agent - http://shark.ow2.org/
[7] TWE - http://www.together.at/
[8] Nikolić. S, Penca. V, Zarić M., “Open source based solution to it resources management”, Zbornik radova YU INFO 2010 (CD), 6 p
[9] Mathias Weske, “Business Process Management:
Concepts, Languages, Architectures”, Springer Berlin Heidelberg, December 2009, ISBN-10: 3642092640, ISBN-13: 978-3642092640
[10]Bojanić S., Puškaš V., Milaković Z., “Programming in XPDL”, Extracted from 2006 Workflow Handbook 195-204, Future Strategies Inc, May 2006, ISBN-10:
0977752704 , ISBN-13: 978-0977752706
[11]Wil van der Aalst, Kees van Hee, "Workflow Management: Models, Methods, and Systems (Cooperative Information Systems)",The MIT Press, March 2004, ISBN-10: 0262720469, ISBN-13: 978- 0262720465
ACKNOWLEDGMENTS
Results presented in this paper are part of the research conducted within the Grant No. III-44010, Ministry of Science and Technological Development of the Republic of Serbia.
