Friday, December 23, 2016
Designing IBM BPM User Interfaces using Coach Views
December 23, 2016
Introduction
Business
Process Management (BPM) solutions can help your business operations run more
smoothly by automating your business processes, and providing increased
visibility and analysis into the performance of your processes. In addition to getting the right tasks to the
right people at the right time, efficient business operations require tasks
that provide a modern user experience that enable business users to complete
their work effectively. User Interface (UI) plays a fundamental part of a BPM
solution and can have a major influence the overall architecture. This post
outlines 5 things to consider when developing UI for IBM BPM, so you can make
the right choices for your BPM solution.
Implementation
1.
Creating
user interfaces with Coaches
IBM BPM
includes the necessary tools required to rapidly design and build custom user
interfaces for your business processes. The IBM Coach Framework is integral to
IBM BPM and enables process authors to rapidly construct web-based user
interfaces for business user tasks. Coaches are responsive UI forms that
seamlessly integrate with your business processes that can be accessed from a variety
of devices including smart phones, tablets and desktop computers. New grid and
theme editors introduced in IBM BPM 8.5.7 enable process authors to easily
layout and style Coaches to create a modern business user experience.
2.
Building
Controls using Coach Views
Process
authors assemble user interfaces by dragging pre-built controls from a palette
onto a canvas using the IBM Process Designer. These are sufficient for
developing UI for simple mock-ups, playback scenarios, and full production BPM
solutions. The IBM Coach Framework is extensible to allow process authors to
add additional controls and leverage alternative UI technologies. Coach Views
are the building blocks that are used to create controls that appear on the
palette. Coach Views can also be used to aggregate content that can be used on
multiple coaches.
3.
Salient
Process SPARK UI toolkit
The SPARK
UI Toolkit is an IBM BPM UI toolkit created by Salient Process, a Premier IBM
Business Partner specializing in IBM Smarter Process consulting services and
innovation. IBM and Salient Process have partnered together to make the SPARK
UI Toolkit the UI toolkit of choice for IBM BPM customers. There are already
efforts underway to incorporate the SPARK UI Toolkit into the IBM BPM product.
The SPARK UI Toolkit:
v Can
increase UI developer productivity up to four times faster than using
traditional methods and decreases maintenance costs by avoiding UI complexity.
v Achieves
the productivity increase through an efficient and intuitive development
experience in combination with reduced skills expectations.
v Provides
90+ responsive and configurable controls, which can adapt to the form factor of
the device running the Coach and are suitable for both production and
fast-build "proof-of-concept" scenarios.
v Includes with
every control a simple and powerful event-based framework that creates a
consistent approach for validation, formula-based computations, and
cross-control interaction.
v Optimizes
UI performance by using controls that support lazy loading and server side
pagination that can support complex UIs and large tabular data sets.
4.
The
IBM Process Portal
The IBM
Process Portal provides the primary user interface used by business users to
perform their work when using IBM BPM solutions. The Process Portal was redesigned
from the ground up in IBM BPM 8.5.7 and built using the Coach Framework. The
Process Portal is now responsive, which liberates field workers by enabling
them to access and execute their tasks when outside the office using a mobile
device. The Process Portal can be modified to accommodate your specific user
experience requirements. It can be easily styled using themes, extended to
include custom dashboards, configured to enable or disable specific
capabilities, and customized or add your own modifications.
5.
Mixing
the Coach Framework with other approaches
Coaches are
not the only approach available to create user interfaces to interact with IBM
BPM processes. There can be numerous reasons for an enterprise to use
alternative approaches to design and deliver BPM UIs, and each of those
approaches comes with consequences on the application’s design, as well as its
security and performance. You can choose from a number of design patterns
depending on your specific requirements.
Monday, December 12, 2016
Integrate Google Maps with BPM Coach View
December 12, 2016
Introduction
Google
makes available a technology for showing maps of various types inside a web
page. This service from Google provides a wealth of features beyond just the
simple display of the map. These features include placing markers, calculating
directions, geolocation and much more. This Coach View provides a wrapper
around the Google Maps technology such that it can be included within a Coach
without the consumer having to learn the Google Maps technologies directly.
Using Coach
View presents a Google Map with abilities to interact with that map. I am going
to show how we can build Google map in Coach View.
Implementation
Before starting
implementation of Google Map with Coach View, we should have below tools.
Ø IBM BPM.
Ø Google Account.
Before implementing IBM BPM code, we should have
Google account, than we should get a Google API key for using Google map in our
coach view.
Get the Google Map API key from
Create
Process Application and upload images:
Open Process Designer
and click on Create New Process App à Enter following details.
Process Application
Name
Acronym
Enter description
under documentation (Optional) as shown below.
Create
a Coach View
Click on + symbol
beside User Interface select Coach View. Enter the Name as ‘Google Map CV’ then
click on Finish.
Now it will open
Coach View editor view. Select Layout Tab, drag the Custom HTML into pallet and
enter below code under Properties à HTML à Text
Select Inline CSS
under Behaviour tab and enter the below code as shown below.
Select Load under Behaviour tab and enter the
below code as shown below.
Select Overview tab
and select Pallet Icon and layout Image which we have uploaded in first step.
Create
a Human Service
Click on + symbol
beside User Interface select Client Side Human Service. Enter the Name as
‘Google Map CHS’ then click on Finish.
Select Diagram Tab,
drag a Coach into pallet and rename as Google Map than connect from Start to
Coach and Coach to End node.
Select Coach Tab or
double click on Google Map Coach. Drag Google
Map CV from views to pallet as shown below.
Now we have
implemented Google map using Coach View. We are ready to test our application
now.
Test
Application
Open Google Map CHS
human service and click on Run button at top right corner as shown below.
Now we should able to
see the google map location which was given default in our code.
Now we can enter
location which we need to see in google map and click on geocode. I entered as ‘London’,
now google map is updated location as London as shown below.
Tuesday, November 22, 2016
New in IBM BPM V8.5.7 Cumulative Fix 2016.09
November 22, 2016
Introduction
IBM
Business Process Manager (BPM) updates are now released every quarter to enable
customers to stay current, apply the latest fixes, and take advantage of new
product enhancements sooner. Cumulative Fixes are applied to the latest BPM
release as a simple in-place upgrade. IBM BPM 8.5.7 Cumulative Fix 2016.09 is
now available for you to download and upgrade today.
Highlights
The
following new feature and fixes are included in IBM Business Process Manager
(BPM) V8.5.7 cumulative fix 2016.09. With this update you will be able to…
New features:
v Invoke REST
services directly from your business processes
v Create
custom integrations using new low code web-based service editors to discover
Java and REST based services
v Deploy BPM
Advanced assets and manage the health of your processes using new self service
facilities for BPM on Cloud
v Deactivate
users who are no longer in the user registry and clean up their group
memberships
New supported environments include:
v Microsoft
Edge (for IBM Process Portal & Responsive Coaches)
v Oracle 12c
multi-tenant feature
v Microsoft
SQL Server 2016
v IBM DB2
11.1
Overview
New function in web Process Designer to create
services
Ø Discover
REST services, for example Watson, and Java applications and call them by using
service flows.
Ø Model
services for business processes in the web Process Designer by using service
flows.
Ø Bring
heritage services (that were created in desktop Process Designer) into the web
Process Designer by converting them into service flows.
Deactivate users from your system who are no longer in
the user registry
In typical
organizations, people come and go and take on new roles. However, when users
are known to IBM BPM (meaning they are in the IBM BPM database), they were
available for task assignments and social interactions even after they were
deleted from the user registry. Before this cumulative fix, there was no way to
deactivate users in the database that were no longer available in the user
registry. For more information about user lifecycle, see Runtime user
availability and lifecycle.
Note:
Deactivate users only if you use clients that rely on REST or JavaScript API
calls. If the client uses the web service API, do not deactivate users because
the API does not support user deactivation.
The
following improvements were made for user deactivation:
Ø A new
parameter added to syncExistingUsers admin script helps you sync user availability
between the user registry and the IBM BPM database.
Ø APIs were
adapted so that you can now look up users based on their availability by using
an availability flag.
Ø APIs were
adapted to prevent task assignments and social interaction requests to
deactivated users.
Ø A new
configuration property for the BPMServerSecurityUsers configuration object
helps you define a default task owner to use when all the assigned task owners
are deactivated.
Prevent group membership updates that might cause
inconsistent data
Ø Now IBM BPM
APIs validate group types before applying group membership updates, ensuring
group membership updates that might cause inconsistent data are refused.
Update IBM BPM files at run time
Ø Use the new
BPMUpdateFile command to update the contents of an existing file in your
process application or toolkit. When the command is run, it creates a new
version of the file at the tip of the branch.
Wednesday, September 28, 2016
IBM Blueworks Live Overview
September 28, 2016
Introduction
IBM
Blueworks Live is a cloud-based business process modelling tool that lets you discover,
design, automate, and manage business processes for your organization. It’s
easy to use and accessible anywhere through a browser. Using a web browser, you
can collaborate with local and distributed teams and access the tool from
anywhere.
With
a Blueworks Live, your organization can:
Ø Discover and document business
processes and decisions using an easy-to-use interface.
Ø Use industry standards such as BPMN 2.0
(Business Process Modelling and Notation 2.0) for business processes and DMN
(Decision Modelling and Notation) for decisions.
Ø Add custom attributes to the standard
set of properties to document details that are specific to your organization.
Ø Create accessed-controlled spaces to
collaborate within teams before publishing artifacts to the wider organization.
Ø Automate workflow and checklist style
processes that are currently performed through email.
Ø Define and refer to a set of glossary
item that represent the approved terms and definitions used in your
organization.
Ø Analyze processes to discover areas for
improvement.
Ø Use playbacks to step stakeholders
through process flows, generating discussion and feedback on the process.
Overview
Key
features
Simplified
Process Modeling
Get started quickly with no training required.
Enter in each step of your process, drag and drop the boxes to reorder the
flow, and then automatically generate a process diagram with one click.
Simultaneous
collaboration
See changes in real-time as your team updates
process information. Social media-style collaboration lets you follow items of
interest and receive notifications when items you're following change.
Template
Library
Over 200 process model templates are available for
download in a wide range of industries and functions. Just import the model
that most closely resembles your own process and start editing and adapting it
immediately.
Friday, September 2, 2016
Testing the REST APIs in IBM BPM V8.5
September 02, 2016
Introduction:
IBM® Business Process Manager provides a set of APIs that are
implemented based on Representational State Transfer (REST) services. A set of
REST resources is available for accessing IBM BPM artifacts, including business
processes, and tasks. A test tool is provided with the IBM® BPM REST APIs. You
can use this tool to help you learn about the REST APIs, and to test those APIs
that you are planning to use in your application.
Overview:
The REST API test tool is a web application that you can use to
prototype the following IBM BPM REST resources and their associated parameters:
Ø BPD-related resources
Ø Federated BPM resources
Ø BPEL-related process resources (IBM BPM Advanced only)
Ø BPEL-related task resources (IBM BPM Advanced only)
The tool is installed on each Process Center and Process Server node as
part of the IBM BPM installation.
How to Use REST API test tool:
Start the REST API test tool. Direct your web browser to the URL for the
REST API test tool. The value of the URL depends on how the virtual host and
context root were configured for your installation. The URL takes the following
form:
http://host_name:port_number/bpmrest-ui
Where:
host_name is the network name for the host of the process server or Process Center.
port_number is the port number used by the REST API test tool. The port number
depends on your system configuration. The default port number is 9080.
For example, if you wanted to test the REST APIs available on port 9080
on myserver1, you would open the http://myserver1:9080/bpmrest-ui
URL in your browser.
In the REST API test tool, select an API.
Optional: Enter any associated parameters that you want to include in
your test.
Click Execute Call to start the test. The response data is shown in the
results pane.
Wednesday, July 20, 2016
Generating the Service Wrapper in Red Hat JBoss Fuse
July 20, 2016
Introduction:
The Red Hat JBoss Fuse console's wrapper feature
generates a wrapper around the JBoss Fuse runtime that allows you to install a
message broker as a system service. The wrapper feature does not come
preinstalled in the console, so before you can generate the service wrapper you
must install the wrapper feature.
Once the feature is installed the console gains a
wrapper:install
command. Running this command generates a generic
service wrapper in the JBoss Fuse installation.
Overview:
To
generate the service wrapper:
1.
Start JBoss Fuse in
console mode using the fuse command.
2.
Once the console is
started and the command prompt appears, enter
features:install
wrapper
.
The features:install command will locate the required
libraries to provision the wrapper feature and deploy it into the run time.
3.
Generate the wrapper
by entering
wrapper:install -n
serviceName
-d
displayName
-D
description
.
The wrapper:install command has the options described in
below table.
Table: Wrapper Install Options
Option
|
Default
|
Description
|
-s
|
AUTO_START
|
(Windows only) Specifies the mode in
which the service is installed. Valid values are AUTO_START or DEMAND_START.
|
-n
|
karaf
|
Specifies the service name that will be used when
installing the service.
|
-d
|
Specifies the display name of the service.
|
|
-D
|
Specifies the description of the service.
|
Generated files
The following files are generated and
make up the service wrapper:
- bin\ServiceName-wrapper[.exe]—the
executable file for the wrapper.
- bin\ServiceName-service[.bat]—the
script used to install and remove the service.
- etc\ServiceName-wrapper.conf—the
wrapper's configuration file.
- Three library files required by the service
wrapper:
- lib\libwrapper.so
- lib\karaf-wrapper.jar
- lib\karaf-wrapper-main.jar
Tuesday, July 12, 2016
MuleSoft Anypoint Studio Update Sites
July 12, 2016
To access these update
sites in Anypoint Studio:
1.
Go to Help > Install New
Software.
2.
Select one of these updates
sites from the drop-down menu next to the Work with field.
3.
If you don’t see the site
you need, click Add to add it manually.
Note: None of the URLs listed below are accessible from a browser. Only use
them in the Anypoint Studio Work with field.
Sunday, April 17, 2016
Using the REST APIs in IBM Business Process Manager V8.5
April 17, 2016
Introduction
This article describes the
REST resources available for application developers to use in IBM® Business
Process Manager to access business process, human task and business category
data. This article introduces the various components of Business Process
Manager that are exposed in the REST APIs, as well as supported content types,
use of method overrides, response data formats, and how to use the REST API
Tester tool.
Overview
IBM Business Process Manager
V8.5 provides a set of APIs that are implemented using Representational State
Transfer (REST) services. A set of business process definition (BPD) related
REST resources are provided for accessing business process, human task and
business category data. These REST APIs enable developers to build a user
interface or customize an existing portal application. The APIs are simple
enough to be called from mobile devices or from Rich Internet Applications
(RIAs).
This article introduces the
IBM Business Process Manager REST APIs you can use to access business process,
human task and business category data, and describes the various components of
Business Process Manager that are exposed in the REST APIs. You'll learn about
the following:
Ø
The REST URL
format
Ø
The available REST
APIs
Ø
Supported content
types and use of method overrides
Ø
Response data
formats
Ø
The REST API
Tester
BPM components and data models
The Business Process Manager
REST APIs work with various BPM components. Below Figure illustrates all
Business Process Manager components for which a REST APIs are implemented, and
their associated data models.
Several REST methods are
available for application developers to use on each resource; these methods are
listed in the next section. Following is the list of Business Process Manager
components in which various product functions are exposed in REST APIs:
v Business process definitions
v Process instances
v Tasks
v External activities and services
v Users and groups
v Saved searches and custom searches
The IBM Business Process
Manager REST resource URIs have the following format:
http://{host}:{port}/rest/{component}/v1/{anyResource}?{query}
where:
·
"http://{host}:{port}" contains
the host address and port
·
"/rest/{component}" is
the configurable context root, where component (providing a resource set) is
e.g. bpm/htm or bpm/wle.
·
"/v1/{anyResource}?{query}",
together with the host address/port and context root, represents the IBM
Business Process Manager resource
Each resource URI has a
version identification (/v1) for handling changes to the REST API set that
would break compatibility with existing REST clients. The following changes are
considered compatible and must be expected by clients:
·
Adding new REST
resource relationship to the resource model, without affecting existing
navigation
·
Adding additive
information to REST representations that won't affect existing clients
·
Adding a new MIME
type / representation support
·
Adding new
properties to existing JSON objects returned to a client (ignored by backlevel
clients)
·
Adding new
properties to existing JSON objects received from a client (defined as
optional)
The IBM Business Process
Manager REST interface provides the following HTTP methods:
·
POST - create a
new resource
·
GET - retrieve a resource
·
PUT - update an
existing resource
·
DELETE - delete a
resource
Some firewalls do not allow
the use of HTTP PUT and DELETE methods to flow through the firewall because of
security considerations. To accommodate this, a PUT or DELETE request can be
'tunneled' through a POST request using
the "X-Method-Override" or "X-HTTP-Method-Override" HTTP
header. In general, the value of the X-Method-Override and
X-HTTP-Method-Override HTTP headers act as an override to the HTTP method used
in the request.
As an alternative to setting
the X-Method-Override or X-HTTP-Method-Override HTTP headers, you can use
the "x-method-override" or "x-http-method-override" URI
query parameter (example: "POST /rest/bpm/htm/v1/task?...&x-method-override=PUT").
In some cases, the length of a
GET request URI might exceed the URI length supported e.g. by a browser or it
might be otherwise impractical to specify all the request parameters as query
parameters. As a workaround, a GET request can be 'tunneled' through an
equivalent POST.
In this case, the client
replaces the GET method by a POST method, puts the URI query string (the string
to the right of the '?' character) into the POST request message body, and sets
the Content-Type HTTP header
to "application/x-www-form-urlencoded".
The data included in requests
or responses will be of one of the following media types:
application/json
JSON (JavaScript Object Notation) - This is the default response content type. For the
detailed format of each returned object, see the JSON schema specifications for
each operation.
application/xml
XML (eXtensible Markup Language) - The format of XML-based data is specfied by the XML
schemas supplied with the product in the <install-root>/properties/schemas/bpmrest/v1
directory. Excerpts of these schemas are also provided in the documentation for
each operation.
application/x-javascript
JSONP (JSON with Padding) - This format can be used as an alternative to JSON.
In this case, each returned JSON response is wrapped in a JavaScript callback
function invocation. To use this feature, you must also specify
the callback URI query parameter.
Requesting Response Media Types
A client can specify the
requested media type for the response by using
the "Accept" HTTP header (example: "Accept:
application/json").
Alternatively, the client can
use the "accept" URI query parameter
(example: "GET
/rest/bpm/htm/v1/task/...?accept=application/json"). If both the HTTP
header and the URI query parameter are specified, then the query parameter
takes precendence.
If the server is unable to
respond with the requested media type then an HTTP status code 406 Not
Acceptable is returned.
Requesting Parts in the Response Data
Some requests support
the parts URI query parameter, which is an optional parameter that
allows a client to specify a list of one or more parts to be returned in the
response data for a particular request.
Examples:
parts=header|data
parts=all
parts=none
In general, the value of the
parts parameter is a "|"-delimited list of part names. Each request
will support its own particular set of part names that are associated with that
request. For those details, see the reference information for each request. In
addition to specific parts names, you can also specify "all" or
"none". If the parts parameter is not specified, then the default of
"all" will be used.
JSON Lists of Name/Value Pairs
Some JSON data objects contain
a nested object with a list of name/value pairs such as { "a" :
"Athens", "b" : "Belgrade", "c" :
"Cairo" }. In the JSON schema descriptions throughout the
documentation, these objects (in custom properties, client settings, and
properties of users/groups) simply appear as generic {"type":"object"}.
JSONP Response (WebSphere Lombardi Edition only)
To request that response data
is to be returned in the JSONP format, you must specify a response media type
of application/x-javascript with either the Accept HTTP
header or the accept URI query parameter, and you must also specify
the javascript function name with the callback URI query parameter.
In this case, the response consists of the JSON content wrapped in a JavaScript
callback function invocation. Example: "GET
/rest/bpm/wle/v1/task/...?accept=application/x-javascript&callback=mycallback".
By default, the support for
JSONP is disabled because of security considerations. To enable JSONP support,
you must set the following property in the server's 100Custom.xml file:
<jsonp-enabled>true</jsonp-enabled>
Requesting Localized
Response Content
For task descriptions,
documentations, etc., a client should send the list of preferred languages in
the "Accept-Language" HTTP header
(example:"Accept-Language: da, en-gb;q=0.8, en;q=0.7" - "I
prefer Danish, but will accept British English and other types of
English"). The server responds with
a "Content-Language" HTTP header
(example: "Content-Language: en").
Instead of setting the HTTP
header, the client can use the "accept-language" URI
parameter (example: "GET /rest/bpm/htm/v1/task/...?accept-language=en").
HTTP request and response
messages might contain compressed data. This is indicated by
the "Content-Encoding" HTTP header
(example:"Content-Encoding: gzip").
If the request message has a
content encoding that is not recognized by the server then an HTTP status
code 415 Unsupported Media Type is returned.
Requesting Encoded Response Content
A client can specify which
content encodings are acceptable by using
the "Accept-Encoding" HTTP header
(example: "Accept-Encoding: gzip") or
the accept-encoding URI query parameter (example: "GET
/rest/bpm/wle/v1/task/...?accept-encoding=gzip").
If
no "Accept-Encoding" HTTP header
(or accept-encoding URI query parameter) is specified in the request
message, then by default the content encoding of the response message is
"identity" (no encoding), indicated by the absence of
the "Content-Encoding" HTTP header.
If the server is unable to
respond with any of the listed content encodings then an HTTP status
code 406 Not Acceptable is returned.
The following list provides a
summary of supported HTTP headers and general URI query parameters applicable
to any resource URI:
·
HTTP headers:
o "Accept" - used to specify the
acceptable media type(s) for the response
o "Accept-Encoding" - used to specify the
acceptable content encodings for the response
o "Accept-Language" - used to specify the
set of natural languages that are preferred in the response
o "Content-Encoding" - specifies which
content codings have been applied to the request or response
o "Content-Language" - specifies the
natural language(s) used in the request or response
o "Content-Type" - specifies the media
type of the request or response message body
o "X-Method-Override" - indicates the
HTTP operation that is tunneled through this request; in other words, this
specifies a method name which overrides the method specified in the HTTP
request header.
o "X-HTTP-Method-Override" - equivalent
to "X-Method-Override"
·
URI parameters:
o "accept" - equivalent to
the "Accept" HTTP header
o "accept-encoding" - equivalent to
the "Accept-Encoding" HTTP header
o "accept-language" - equivalent to
the "Accept-Language" HTTP header
o "callback" - name of the JavaScript
callback function used in JSONP responses; this URI query parameter is required
if the caller requests the application/x-javascript media type in the response
by setting the Accept HTTP header or the accept URI query
parameter.
o "x-method-override" - equivalent
to "X-Method-Override" HTTP header
o "x-http-method-override" - equivalent
to "X-HTTP-Method-Override" HTTP header
If both an HTTP header and its
corresponding URI query parameter are specified, then the URI query parameter
value takes precedence over the HTTP header value.
For errors recognized during
processing of a REST request, an appropriate HTTP status code is returned to
the calling client (see the individual operations for details). The following
HTTP status codes are returned by IBM Business Process Manager REST methods:
·
Successful completion of the request:
o "200 OK" - successful completion
o "201 Created" - successful completion,
new resource created
o "204 No Content" - successful
completion, no content available
·
Expected error situations - additional error
information is provided depending on the error type:
o "400 Bad Request" - parameters are not
valid or they are missing
o "401 Unauthorized" - caller is not
authorized for this request
o "403 Forbidden" - caller is not allowed
to complete this request
o "404 Not Found" - resource does not
exist
o "406 Not Acceptable" - unsupported
media type or content encoding requested
o "409 Conflict" - conflict exists with
the current state of the resource
o "415 Unsupported Media Type" -
unsupported media type or content encoding of the request
·
Unexpected error:
o "500 Internal Server Error" - severe
problem - programmer's details provided
o "501 Not Implemented" - used for
certain federated requests
o "503 Service Unavailable" - federated
requests could not be delivered to individual federation targets
o "504 Gateway Timeout" - federated
response has partial content because of missing individual responses
Exception details
By default, an error response
will omit the server-side exception details because of security considerations.
To enable the inclusion of server-side exception details, you must set the
following property in the server's 100Custom.xml file:
<server-stacktrace-enabled>true</server-stacktrace-enabled>
Subscribe to:
Posts
(
Atom
)