About Me
Facebook
Facebook
Linked In
Linked In
Twitter
Twitter
YouTube
YouTube
Google +
Google +

November 29, 2015

Programming IBM BPM - Developing using the JavaScript API



Introduction
You can find programming guides and examples for programming various aspects of the IBM® Business Process Manager system, in this article.
In Process Designer all variables are JavaScript variables so you can use JavaScript code snippets inside your components to improve the behavior of your model.
Variable availability
You can only use certain JavaScript objects inside a specific context. In some contexts, certain objects are automatically instantiated.
Table 1. Object availability
Object
Context Allowed
Context Instantiated
Context Denied
TWLogger
All
None
None
TW
Process
Process
ScoreBoard
TWScoreboard
ScoreBoard
ScoreBoard
Process, Service
Chart
ScoreBoard
Filter Layout, Datasource
None
TWDate
All
None
None
TWMap
All
None
None
String
All
None
None
XMLDocument
All
None
None
XMLElement
All
None
None
XMLNodelist
All
None
None
listOf
All
None
None
ic
All
None
None
Alert
All
None
None
Event
All
None
None
External JavaScript libraries
Process Designer provides a number of JavaScript libraries. You can also import or create your own libraries.
Using JSON
 JSON is a string representation of a JavaScript object that can be transmitted over the network. You can use it to pass parameters inside IBM® BPM.
An Open Source JavaScript implementation is available to both parse and construct JSON strings. Part of this package is a JavaScript source file called json2.js.
Add this file to your toolkit or process application as a server managed file to provide new global methods and objects.
Example
This example illustrates how to taking a List of Complex data structure and building a JSON representation:
var newArray = new Array();
for (var j=0; j<tw.local.myPurchase.listLength; j++)
{
  var newObj = new Object();
  for (var property in tw.local.myPurchase[j].propertyNames)
  {
    var name = tw.local.myPurchase[j].propertyNames[property];
    newObj[name] = tw.local.myPurchase[j][name];
  }
  newArray.push(newObj);
}
var jsonText = JSON.stringify(newArray);
log.error("jsonText = " + jsonText);
Within a browser or the coach, you can use the Dojo classes to work with JSON:
  • dojo.fromJson(string) parses a JSON string to return a JavaScript object.
  • dojo.toJson(Object) returns a JSON string given a JavaScript object.
Using the Dojo Toolkit
Dojo is an open source set of JavaScript libraries that enhance the capabilities of native JavaScript. The Dojo Toolkit is supplied and loaded by Coach Pages.
Commonly, Dojo is thought as a visual language for building rich web pages. Although this is an important component of the Dojo Toolkit, it is not its only function.
If you are developing complex Coach Views using Dojo or another JavaScript library and need advanced features for JavaScript development, debugging, and testing, consider using an IDE tool, such as Rational® Application Developer, to initially create the JavaScript. You can then use the JavaScript that you develop as part of your Coach views in Process Designer.
Procedure
  1. Open a Coach component.
  2. Use Dojo calls. For example, use var x = dojo.byId("name of control"); to return the DOM node of the control by name.
JavaScript reference examples
This section provides JavaScript examples.
Starting a new process
A new instance of a process can be started by using the tw.system.startProcessByName() function.
The method tw.system.startProcessByName() returns a TWProcessInstance object and takes 2 parameters:
name (String)
Name of the process.
inputValues (Map)
Map containing the input parameters for the process.
var inputs = new tw.object.Map();
inputs.put("parm1", "parm1 value");
inputs.put("parm2", "parm2 value");
tw.system.startProcessByName("StartProcess2", inputs);
Thread hung exceptions
Under certain circumstances, an attempt to start a process instance using the tw.system.startProcessByName() function might be blocked, and in the system out log you might see a thread hung exception for a thread holding a database connection. This might happen in the following circumstance:
  • You have defined an undercover agent (UCA) message event with an attached service.
  • In the attached service you are starting a new process instance using the tw.system.startProcessByName() function.
  • The process you are starting has variables defined that are exposed to Business Data Search, and the process creation hangs.
The recommended solution is to use the BPMN (Business Process Model and Notation) best practice, and model the process with a start message event.
Getting the current process instance
The current process instance can be retrieved through the TWProcessInstance variable called tw.system.currentProcessInstance.
Getting the current userid
The current user ID can be retrieved through the TWUser variable in tw.system.user.
Starting an external application
You can start an external application such as a batch file or a shell script by performing that task using the JavaScript LiveScript mechanism.
This sample illustrates how to run a batch file on a Windows system.
var runtime = java.lang.Runtime.getRuntime();
runtime.exec("C:\\RunMe.bat");
Returning the owner of a task
You can know the identity of a user who has completed a given task.
You can do this by defining an output parameter for the human service to store the name of the user that completed the task.
Within the human service, before its termination, use the following code to declare the output parameter:var user = tw.system.currentTask.assignedTo;
It returns a TWUser object.
The name property can be used to determine the userid of the user that claimed the task.
Returning a list of reference links
You can return a list of all reference links of the current process application or toolkit on a server by running the tw.system.model.processApp.getLinks() method.
This tw.system.model.processApp.getLinks() method allows for returning reference links in the toolkits referenced by the process application, and results can be filtered. The tw.system.model.processApp.getLinks() link property returns only the reference links for the current process application (not its children), and the results are not filtered.
Parameters
The method tw.system.model.processApp.getLinks() returns an array of TWLink and takes two parameters:includeReferencedToolkitsThis is a boolean flag that indicates if the links should be collected recursively on all library item elements contained in the process application and dependent toolkits. linkFilterThis is a JavaScript function that takes TWLink as parameter and returns a boolean value that indicates whether the link should be excluded from the result.
The signature of the linkFilter argument function is boolean linkFilterFunction(TWLink twlink), and that the filter function is called for each reference link result. The filter function returns true if the TWLink value in question is filtered out (excluded), or false if it is not filtered out.
You can collect the names and URLs of the links using the assetType Change Request from your process application and its children, and then assign them to local variables in your process.
This example assumes that the following two private variables have been defined: requestLinksName of type String List, and requestLinksURL of type String List. Make sure to select Has Default for both. The requestLinksName variable is an array that contain the names of all the links, and the requestLinksURL variable is an array that contain the URLs of all the links obtained by getLinks() that were not filtered out by the linkFilter function.
The following example is an specific example of how to narrow down the list of returned links to be only those of the Change Request asset type for that process application (and child projects). However, getLinks() can be used to return all reference links.
var linkFilter = function (twlink) {
            if (twlink != null && TWLink.AssetTypes.CHANGE_REQUEST == twlink.assetTypeNamespace){
                        return false;
            }else{
                        return true;
            }
}
var requestLinks = tw.system.model.processApp.getLinks(true, linkFilter);
if(requestLinks != null){
    for(var i=0; i<requestLinks.length; i++){
        tw.local.requestLinksName[i] = requestLinks[i].name;
        tw.local.requestLinksURL[i] = requestLinks[i].url;
    }
}
Attention: If the call is done from the context of another process application, only the links of the process application can be obtained. The filtered list will not include any children.
Extracting a managed file
If a process application or a toolkit contains a managed file, you can extract it from the runtime to evaluate its content.
This example illustrates how to extract a managed file by writing its content to a local file.
var managedFile = tw.system.model.findManagedFileByPath("lsw-services.jar",
TWManagedFile.Types.Server);
log.error("Got the managed file!: " + managedFile);
managedFile.writeDataToFile("C:\\lsw-services.jar");
Note: The first parameter of the tw.system.model.findManagedFileByPath API is managedFilePath, which does not support '!' notation to reference the contents of an archive.
Searching processes and tasks
You can search a specific task in a current process.
The JavaScript object of type TWSearch can be used to perform a search. It has three primary methods:
Ø  execute()
Ø  executeForProcessInstances()
Ø  executeForTasks()
The TWSearch object has a number of properties that are used to govern the data queried for and returned.TWSearch.columnsThe columns of data to be returned.TWSearch.conditionsThe queries to be executed (of type TWSearchCondition).A call to TWSearch using the execute() method can return a TWSearchResults object.
log.error("Starting to find other tasks ....");
log.error("This process: " + tw.system.currentProcessInstance.id);
var col1 = new TWSearchColumn();
col1.name = TWSearchColumn.ProcessInstanceColumns.ID;
col1.type = TWSearchColumn.Types.ProcessInstance;
var search = new TWSearch();
search.columns = new Array(col1);
var condition = new TWSearchCondition();
condition.column = new TWSearchColumn();
condition.column.name = TWSearchColumn.ProcessInstanceColumns.ID;
condition.column.type = TWSearchColumn.Types.ProcessInstance;
condition.operator = TWSearchCondition.Operations.Equals;
condition.value = "270";
search.conditions = new Array(condition);
var order1 = new TWSearchOrdering();
order1.column = col1;
order1.order = TWSearchOrdering.Orders.Descending;
search.orderBy = new Array(order1);
search.organizedBy = TWSearch.OrganizeByTypes.ProcessInstance;
var results = search.execute();
log.error("Result.rows.length = " + results.rows.length);
for (var i=0; i<results.rows.length; i++)
{
  ...
}
Calling Java through JavaScript
JavaScript inside IBM® BPM can invoke Java through the Live Connect technology.
LiveConnect is the name of an application programming interface that provides JavaScript with the ability to call methods of Java classes and vice-versa using the existing Java infrastructure.
Working with document attachments
 Document attachments can be associated with process instances. These can be added through coach controls or through programmatic additions.
The relevant JavaScript components are:
TWDocument
The description of a document.
tw.system.findDocumentByID()
Finds a document from its ID.
TWProcessInstance.documents
An array of TWDocument objects associated with an instance of a process.
TWProcessInstance.addDocument()
Adds a document to a process instance.
TWProcessInstance.findDocuments()
Locates documents associated with the current instance.
Note: The addDocument() function will not work when called from JavaScript locally coded in a BPD activity but works fine when coded in a general service.
Using the addDocuments() method
The addDocuments() method has the following parameters:type (String)Either TWDocument.Types.URL or TWDocument.Types.File.name (String)Name of the document.fileLocation (String)The path to the file on the server or URI.hideInPortal (Boolean)A flag which describes whether or not the document is to be visible in the process portal.createdBy (TWUser)properties (Map)
The following code sample illustrates how to use the addDocuments() method.
var myMap = new tw.object.Map();
var hide = false;
var user = tw.system.user;
tw.system.currentProcessInstance.addDocument(
  TWDocument.Types.File,
  "name",
  "C:\\Projects\\WLE\\Images\\ibm.jpg",
  hide,
  user,
  myMap);
Retrieving data from XML
The following examples show you how to pull data out from an XMLDocument (or any XML type) using the following XML.
Generally speaking, walking the XML as shown below is more efficient that using XPath because it does not call the parser.
The XML example here is the resultSet from an Integration Component. For the purposes of the example, assume that the XML below is stored in a variable called myXML.
<resultSet recordCount="2" columnCount="2">
  <record>
    <column name="FIRST_NAME">Daniel</column>
    <column name="ZIP">78703</column>
  </record>
  <record>
    <column name="FIRST_NAME">Helen</column>
    <column name="ZIP">15228</column>
  </record>
</resultSet>
The following examples illustrate how to retrieve specific values from the XML variable.
tw.local.myXML.resultSet
Returns a node list of records.
tw.local.myXML.resultSet.record[1]
Returns a node list of columns. In the previous example, the values "Helen" and "15228".
tw.local.myXML.resultSet.record[1].column[0].getAttribute( "name")
Returns "FIRST_NAME".
tw.local.myXML.resultSet.record[1].column[1].getAttribute("name")
Returns "ZIP".
tw.local.myXML.resultSet.record[1].column[1].getText()
Returns 15228.

continue reading

November 26, 2015

IBM BPM - Versioning Process Applications



Introduction
Versioning provides the ability for the runtime environment to identify snapshots in the lifecycle of a process application, and to be able to concurrently run multiple snapshots on a process server.
Overview
To understand how process applications are versioned, it is important to remember that a process application is a container that holds various artifacts used in or by the process application (for example, process models or BPDs, toolkit references, services, tracks, or monitor models). Any versioning is done at this container level, not at the level of the individual artifacts. For process applications, that means that versioning happens when you take a snapshot.
You can compare snapshots to determine differences between the versions. For example, if a developer fixed a problem with a service and took a snapshot of its containing process application or toolkit at that point, and then a different developer made several additional changes to the same service and took a new snapshot, the project manager can compare the two snapshots to determine which changes were made when and by whom. If the project manager decided that the additional changes to the service were not worthwhile, the project manager can revert to the snapshot of the original fix.
You can run different versions (snapshots) of a process application concurrently on a server; when you install a new snapshot, either remove the original or leave it running.
Version context
Each snapshot has unique metadata to identify the version (referred to as version context). You assign that identifier, but IBM recommends using a three-digit numeric version system in the format <major>.<minor>.<service>. See the topics about naming conventions for a more detailed description of this versioning scheme.
IBM® Business Process Manager assigns a global namespace for each process application. The global namespace is specifically either the process application's tip or a particular process application snapshot. The version name used by the server cannot be longer than seven characters, so the assigned name is an acronym that uses characters from the snapshot name that you assigned. Snapshot acronyms are identical to their snapshot names if the snapshot names conform to the recommended IBM VRM style and are not more than seven characters. For example, a snapshot name of 1.0.0 will have an acronym of 1.0.0, and a snapshot name of 10.3.0 will have the acronym of 10.3.0. The snapshot acronym will be guaranteed to be unique within the context of the process application within the scope of the Process Center server. For that reason, you cannot edit the snapshot acronym.
Versioning considerations for process applications in multiple clusters
You can install the same version of a process application to multiple clusters within the same cell. To differentiate among these multiple installations of the same version of the process application, create a snapshot for each installation and include a cell-unique ID in the snapshot name (for example, v1.0_cell1_1 and v1.0_cell1_2). Each snapshot is a new version of the process application (from a pure lifecycle management perspective), but the content and function are the same.
When you install a process application in a cluster, an automatic synchronization of the nodes is performed.
Versioning considerations for Process Designer toolkits
Remember that process application snapshots are typically taken when you are ready to test or install. Toolkit snapshots, however, are typically taken when you are ready for that toolkit to be used by process applications. Afterward, if you want to update the toolkit, you must take another snapshot of "tip" when you are ready, and then the owners of process applications and toolkits can decide whether they want to move up to the new snapshot.
Naming conventions
A naming convention is used to differentiate the various versions of a process application as it moves through the lifecycle of updating, deploying, co-deploying, un-deploying, and archiving.
This section provides you with the conventions that are used to uniquely identify versions of a process application.
A version context is a combination of acronyms that uniquely describes a process application or toolkit. Each type of acronym has a naming convention. The acronym is limited to a maximum length of seven characters from the [A-Z0-9_] character set, except for the snapshot acronym, which can also include a period.
Ø  The process application acronym is created when the process application is created. It can be a maximum of seven characters in length.
Ø  The snapshot acronym is created automatically when the snapshot is created. It can be a maximum of seven characters in length.
If the snapshot name meets the criteria for a valid snapshot acronym, the snapshot name and acronym will be the same.

Note: When using the mediation flow component version-aware routing function, name your snapshot so that it conforms to the <version>.<release>.<modification> scheme (for example, 1.0.0). Because the snapshot acronym is limited to seven characters, the digit values are limited to a maximum of five total digits (five digits plus two periods). Therefore, care should be taken when the digit fields are incremented, because anything beyond the first seven characters is truncated.
For example, a snapshot name 11.22.33 results in a 11.22.3 snapshot acronym.
Ø  The track acronym is automatically generated from the first character of each word of the track name. For example, a new track created with the name My New Track would result in an acronym value of MNT.
The default track name and acronym are Main. Deployment to a IBM® Process Center server includes the track acronym in the versioning context if the track acronym is not Main.
A business process definition in a process application is typically identified by the process application name acronym, the snapshot acronym, and the name of the business process definition. Choose unique names for your business process definitions whenever possible. When duplicate names exist, you might encounter the following problems:
Ø  You might be unable to expose the business process definitions as web services without some form of mediation.
Ø  You might be unable to invoke a business process definition created in IBM Process Designer from a BPEL process created in IBM Integration Designer.
Naming conventions for Process Center server deployments
On the IBM® Process Center server, you can deploy a snapshot of a process application as well as a snapshot of a toolkit. In addition, you can deploy the tip of a process application or the tip of a toolkit. (A tip is the current working version of your process application or toolkit.) The version context varies, depending on the type of deployment.
For process applications, the process application tip or the specific process application snapshot is used to uniquely identify the version.
Toolkits can be deployed with one or more process applications, but the lifecycle of each toolkit is bound to the lifecycle of the process application. Each process application has its own copy of the dependent toolkit or toolkits deployed to the server. A deployed toolkit is not shared between process applications.

If the track associated with the process application is named something other than the default of Main, the track acronym is also part of the version context.
Process application snapshots
For process application snapshot deployments, the version context is a combination of the following items:
ü  Process application name acronym
ü  Process application track acronym (if a track other than Main is used)
ü  Process application snapshot acronym
Stand-alone toolkits
For toolkit snapshot deployments, the version context is a combination of the following items:
ü  Toolkit name acronym
ü  Toolkit track acronym (if a track other than Main is used)
ü  Toolkit snapshot acronym
Tips
Process application tips are used during iterative testing in Process Designer. They can be deployed to Process Center servers only.
For process application tip deployments, the version context is a combination of the following items:
ü  Process application name acronym
ü  Process application track acronym (if a track other than Main is used)
ü  "Tip"
Toolkit tips are also used during iterative testing in Process Designer. They are not deployed to a production server.
For toolkit tip deployments, the version context is a combination of the following items:
ü  Toolkit name acronym
ü  Toolkit track acronym (if a track other than Main is used)
ü  "Tip"
Examples
Resources should be uniquely named and identified externally using the version context.
ü  The following table shows an example of names that are uniquely identified. In this example, a process application tip uses the default track name (Main):
Table 1. Process application tip with default track name
Type of name
Example
Process application name
Process Application 1
Process application name acronym
PA1
Process application track
Main
Process application track acronym
"" (when the track is Main)
Process application snapshot

Process application snapshot acronym
Tip
Any SCA modules associated with this process application tip include the version context, as shown in the following table:
Table 2. SCA modules and version-aware EAR files
SCA module name
Version-aware name
Version-aware EAR/application name
M1
PA1-Tip-M1
PA1-Tip-M1.ear
M2
PA1-Tip-M2
PA1-Tip-M2.ear
ü  The following table shows an example of a process application tip that uses a non-default track name:
Table 3. Process application tip with non-default track name
Type of name
Example
Process application name
Process Application 1
Process application name acronym
PA1
Process application track
Track1
Process application track acronym
T1
Process application snapshot

Process application snapshot acronym
Tip
Any SCA modules associated with this process application tip include the version context, as shown in the following table:
Table 4. SCA modules and version-aware EAR files
SCA module name
Version-aware name
Version-aware EAR/application name
M1
PA1-T1-Tip-M1
PA1-T1-Tip-M1.ear
M2
PA1-T1-Tip-M2
PA1-T1-Tip-M2.ear
Similar naming conventions apply to advanced Toolkit tip and snapshot deployments. They also apply to advanced snapshots installed to Process Server.
ü  The following table shows an example of names that are uniquely identified. In this example, a process application snapshot uses the default track name (Main):
Table 5. Process application snapshot with default track name
Type of name
Example
Process application name
Process Application 1
Process application name acronym
PA1
Process application track
Main
Process application track acronym
"" (when the track is Main)
Process application snapshot
Process Shapshot V1
Process application snapshot acronym
PSV1
Any SCA modules associated with this process application snapshot include the version context, as shown in the following table:
Table 6. SCA modules and version-aware EAR files
SCA module name
Version-aware name
Version-aware EAR/application name
M1
PA1-PSV1-M1
PA1-PSV1-M1.ear
M2
PA1-PSV1-M2
PA1-PSV1-M2.ear
ü  The following table shows an example of a process application snapshot that uses a non-default track name:
Table 7. Process application snapshot with non-default track name
Type of name
Example
Process application name
Process Application 1
Process application name acronym
PA1
Process application track
Track1
Process application track acronym
T1
Process application snapshot
Process Snapshot V1
Process application snapshot acronym
PSV1
Any SCA modules associated with this process application snapshot include the version context, as shown in the following table:
Table 8. SCA modules and version-aware EAR files
SCA module name
Version-aware name
Version-aware EAR/application name
M1
PA1-T1-PSV1-M1
PA1-T1-PSV1-M1.ear
M2
PA1-T1-PSV1-M2
PA1-T1-PSV1-M2.ear
Naming conventions for Process Server deployments
On the Process Server, you can deploy the snapshot of a process application. The process application snapshot acronym is used to uniquely identify the version.
For process application snapshot deployments, the version context is a combination of the following items:
ü  Process application name acronym
ü  Process application snapshot acronym
Resources should be uniquely named and identified externally using the version context. The following table shows an example of names that are uniquely identified:
Table 1. Example of names and acronyms
Type of name
Example
Process application name
Process Application 1
Process application name acronym
PA1
Process application snapshot
1.0.0
Process application snapshot acronym
1.0.0
A resource, such as a module or library, has the version context as part of its identify.
The following table shows an example of two modules and how the associated EAR files include the version context:
Table 2. SCA modules and version-aware EAR files
SCA module name
Version-aware name
Version-aware EAR/application name
M1
PA1-1.0.0-M1
PA1-1.0.0-M1.ear
M2
PA1-1.0.0-M2
PA1-1.0.0-M2.ear
The following table shows an example of two process-application-scoped libraries and how the associated JAR files include the version context:
Table 3. Process-application-scoped libraries and version-aware JAR files
SCA process-application-scoped library name
Version-aware name
Version-aware JAR name
Lib1
PA1-1.0.0-Lib1
PA1-1.0.0-Lib1.jar
Lib2
PA1-1.0.0-Lib2
PA1-1.0.0-Lib2.jar
Conclusion
In this article we covered IBM Business Process Manager Versioning process applications and naming conversions which are fit for IBM Process Server and IBM Process center. I hope it will be very useful who is going to start their project where IBM BPM used.

continue reading

Designed By AMEER BASHA G