Impact 2014 1147 - Bridging Business Process Management and Integration use cases

© 2014 IBM Corporation
IEC-1147 Bridging Business Process
Management and Integration Use
Cases
Rob Phippen (phippen@uk.ibm.com), IBM UK
Brian Petrini (petrini@us.ibm.com), IBM US

Introduction
!  The use of IBM BPM (‘BPM’) and IBM Integration Bus (‘IIB’) is
becoming a commonly-deployed combination of products
!  Even without consideration for the technical needs of the
integration between the two, a large number of design patterns are
emerging in the field
!  These patterns in this deck are based on the usual integration and
interaction patterns, but the deck attempts to put them altogether in
one place for reference, with BPM and IIB specific notes.
!  **These names for patterns have not been ‘approved’ or
‘validated’, although the patterns themselves have. Suggestions for
alternate names are welcomed!
!  (note on naming and terminology – often the word ‘then’ as in ‘a’
then ‘b’ means ‘do a transactionally’ then separately do ‘b’, often
with something in between)
1

3
Agenda
!  BPM and IIB tooling enabled
use cases
!  BPM and IIB advanced use
cases

Tooling and Technology
Enablers:
IBM BPM Standard and IBM
Integration Bus

Overall Approach
BPM developer IIB developer
Create Process Application and
Business Process Design
Create BPM integration service
Define inputs and outputs
Move BPM integration service to
Toolkit (creates snapshot)
Export snapshot
as .twx file
Generate IIB Integration service from .twx
Implement IIB Integration service
Deploy and test IIB Integration
service
Export Service information to .twx
creating new snapshot
Play back
Business Process Design
Update Toolkit dependency
Import snapshot

Create Business Process Design
•  Define the human tasks and system tasks in the process flow
•  Define Business Objects to be used by the flow
•  For each task define and map the variables
•  Choose to implement the system task as a new integration service
Implemented as Integration service
GetBalance

Create new BPM Integration Service
•  The BPM developer does not attempt to implement the Integration Service

Define BPM Integration Service Interface
•  Assign Input and Output variables for the Integration Service

Move the Integration Service to a BPM Toolkit
Moving an Integration Service to a
Toolkit automatically creates a new
Snapshot

Export the BPM Toolkit Snapshot as TWX file
•  The BPM developer now gives the TWX file to the IIB developer so that they can
start to implement an IIB Integration Service ...

Generate the IIB Integration Service from TWX
•  There are several ways to initiate Integration Service generation in the IIB
Toolkit if you have a TWX file
1.  From the Quick Start screen
2.  From File → New → Service
3.  From the Patterns Explorer

Explore the IIB Integration Service - 2
Service
Descriptor
XSDs
WSDL
Message
Flow
Subflows
Click to
create
operation
subflow

Explore the IIB Integration Service - 2
Service
Descriptor
XSDs
WSDL
Message
Flow
Subflows

Implement the IIB Integration Service
•  Click on the operation in the service
editor to open the sub-flow
and allow implementation
•  This is where IIB can transform the request message, connect to the
corporate back end (WS, CICS, SAP, MQ, DB, .NET ...) and transform
the returned data into a response message
‒  For example, could call a .NET assembly for a Windows-based service
IIB developer implements the service by
adding node(s) to process the request and
produce a response message

Deploy and Test the IIB Integration Service
•  Deploy the Integration Service to a IIB broker runtime and test
•  The deployed Integration Service will have an endpoint URL and a query
WSDL (?wsdl) URI
‒  These will be used by the BPM Integration Service
•  Once the IIB Integration Service is working as required, information
about how to access it must be passed back to BPM

Export the IIB Integration Service to a TWX file - 1
•  Export the service information by
right clicking the Service Description
•  The export wizard first allows the host
name and port of the deployed
service be specified

Export the IIB Integration Service to a TWX file - 2
•  Specify the snapshot name, which defines the version of the BPM Toolkit
•  Specify where the TWX file will be written
•  The resultant TWX file can now be handed back to the BPM developer

Import the New TWX file
•  Import the new snapshot of the Toolkit from the TWX file via BPC

Update the BPM Toolkit Dependency
•  In Process Designer return to the Process Application that references
the Toolkit
•  An icon will show that the Toolkit has a new snapshot and can be
upgraded
•  Select to update the dependency

Explore the BPM Integration Service - 1
•  A Web Service Integration has been added to the Integration Service,
thereby implementing it
•  Data mappings have been done between Integration Service variables
and operation variables

Explore the BPM Integration Service - 2
•  The WSDL URI, operation and Endpoint Address URL have been set
•  Environment variables have been used in the Endpoint Address URL so
that they can easily be changed if the IIB Integration Service is moved

Test the BPM Process Design
•  The BPM Integration Service can be tested by executing the BPD using
the Playback Server
•  Start the Playback
•  Execute each task to complete the flow

Tooling and Technology
Enablers:
IBM BPM Advanced and IBM
Integration Bus

IBM Integration Designer (formerly WID)
!   IBM Integration Designer is the integration tool that you use to author SOA-based services and
choreograph them into business processes that you can deploy on IBM Business Process
Manager Advanced (formerly WebSphere Process Server).
WSDL Interface for
Export Service component
containing the
business
process
SCA Import
SCA Export
WSDL Interface
for Import
WSDL Reference
for Import

SCA Nodes in IIB
SCA Request node
-  Send outbound synchronous request messages to WPS.
-  The node blocks for a specified period until a response is
received.
-  Used for sending one-way outbound messages.
SCA Input and SCA Reply nodes
–  Receive inbound messages from WPS.
–  A WPS SCA Import component can use Message
Broker as an SCA endpoint.
SCA Async Request & SCA Async Response
nodes
-  Send outbound asynchronous request messages to
WPS.
-  WMB can carry on processing after request has been
sent.
-  Async Response Node listens on a different thread.
The SCA nodes support Web Services and MQ bindings.

Processing an inbound message sent from IBM BPM Advanced
IBM BPM Advanced
IBM Integration Bus
1. Receive inbound msg
2. Send reply msg

Sending a synchronous outbound request to IBM BPM Advanced
IBM BPM Advanced
IBM Integration Bus
1. Send outbound request
msg
2. Receive response msg

Sending an asynchronous outbound request to IBM BPM Advanced
IBM BPM Advanced
IBM Integration Bus
1. Send outbound request
msg
2. Receive response msg

To build this, you can start from IID . . .
1. Develop Business
Process Application in
IID (BPM Adv) first.
2. Export Project
Interchange (PI) file.
3. Import PI into IIB to
create message
model and IIB SCA
Definition.
4. Create message flow
using the IIB SCA
Definition.

Or you can start from IIB . . .
1.  Generate Broker SCA Definition
from Message Set in IIB.
2.  Develop Message Flow using
Broker SCA Definition.
3.  Export SCA components, XSDs
and WSDL from IIB SCA
Definition.
4.  Import SCA Components,
XSDs and WSDL into IID.
5.  SCA components are
automatically created in the
Assembly Diagram. Data
types and interfaces are
automatically added to the
module.

Detailed Patterns and
Implementation

Detailed patterns and implementation
!  Fire and Forget
•  Fire, Validate then Forget
•  Fire and Forget with Error Callback
•  Fire, Validate then Forget with Error Callback
•  Fire and Forget with Error Pub-Sub
•  Fire, Validate then Forget with Error Pub-Sub
!  Single Blocking Put–Get
•  Single Blocking Put-Get with Delayed Response Callback Option
•  Single Blocking Put-Get with Delayed Response Pub-Sub Option
!  Blocking Put then Get
•  Variants are similar to those for Single Blocking Put–Get
!  Non-Blocking Put-Callback
•  Non-Blocking Put then Callback
•  Non-Blocking Put Known-at-Design-Time-Multiple Callbacks
•  Non-Blocking Put Known-at-Run-Time-Multiple Callbacks
•  Non-Blocking Put Unknown-Multiple Callbacks
!  Single Blocking Put–Get then Non-Blocking Callback
•  Single Blocking Put–Get then Known-at-Design-Time-Multiple Non-Blocking Callbacks
•  Single Blocking Put–Get then Known-at-Run-Time-Multiple Non-Blocking Callbacks
•  Single Blocking Put–Get then Unknown-Multiple Non-Blocking Callbacks
!  Pub-Sub
33

Patterns in detail – How the patterns are described
!  Overview
•  This is the general overview of the pattern. It describes what it does and may also
describe an example business problem it solves.
•  Sometimes has a ‘not to be confused with’ section mentioning other patterns.
!  AKAs:
•  “Also Known As” – other names used for the pattern
!  Parent Pattern(s)
•  Any pattern or combination of patterns that this pattern is derived from
!  Implementation
•  Notes as to how to implement this pattern in BPM and Broker
!  Error Modes
•  What can go wrong? Where can it go wrong?
!  Notes
•  Any other considerations
!  Diagrams and Sequences
•  Displays the patterns visually
!  Pattern Variants
•  These are variations of the ‘base’ pattern that are often used. They are normally “the
same as the ‘base’ but with one thing changed”
34

Fire and Forget
!  Overview
•  This is a “one-way” interaction. BPM makes a request to have something happen, but does not ‘care’
when it actually happens, only that it does
•  This delegates the responsibility for achieving the outcome to either broker itself, or another service
that broker calls.
!  AKAs:
•  One-way, send message
!  Parent Pattern
•  One-way request with Acknowledgement: Asynchronous Transport
!  Implementation
•  BPM Integration service serialises a BPM Data Object into a message which is placed on a queue
using MQPUT.
•  Broker implements a ???? take request and process pattern.
!  Error Modes
•  Request not possible (e.g. queue not found)
•  Modelled Error Response: Invalid Request
!  Notes
•  What about if the target is another BPM process?
•  Combine with pub-sub?
35

Fire and Forget: Diagram and Sequence
36
Request Queue
Message
Request
Ack Response

Fire and Forget: Variants
!  Fire, Validate then Forget
•  This varies as the caller only receives a successful acknowledgement when some initial
validation has been performed on the message e.g. correct XML format
•  Implemented from BPM the same way as Single Blocking Put-Get
•  Broker then carries on processing after returning the validation acknowledgement to
BPM
!  Fire and Forget with Error Callback
•  This acknowledges that there is hardly ever a genuine ‘one way’ interaction. If there is an
error in processing, does BPM wish to know at some point?
•  Implemented the same way as with the Non-Blocking Put then Callback pattern, but the
callback is only sent if there is an error.
!  Fire, Validate then Forget with Error Callback
!  Fire and Forget with Error Pub-Sub
•  Similar to Fire and Forget with Error Callback, but the error condition is not handled by
the original calling process.
•  BPM sends a one-way call to broker, but provides a registered error pub-sub location to
which any errors should be sent.
•  If an error occurs, BPM will handle the error by receiving the message at the inbound
event queue, but any action will be taken by a new process instance, not the one that
made the original request.
!  Fire, Validate then Forget with Error Pub-Sub
37

Single Blocking Put-Get
!  Overview
•  The simplest pattern from an understanding point of view. This is where the process needs to make a
request/response interaction with a service via Broker in ‘real time’ i.e. a response is needed as fast
as possible
!  AKAs
•  Request Response, Synchronous Call, Two-Way Sync
!  Parent Pattern
•  Request/Response: Blocking Caller with Asynchronous Transport
!  Implementation
•  BPM Integration service serialises a BPM Data Object into a message which is placed on a queue
using MQPUT. The same Integration service then immediately does an MQGET with correlation to
wait for the response. The response is then de-serialised into a BPM Data Object.
•  Broker implements a ???? take request and provide response pattern.
!  BPM Error Modes
•  Modelled Error Response: Invalid Request
•  Modelled Error Response: Logical Error
•  Response Timeout: No Response
•  Response Timeout: Response arrives after timeout period
38

Single Blocking Put–Get: Diagram and Sequence
39
Request Queue Reply Queue
Request Reply
Use Correlation ID for correct reply

Single Blocking Put–Get: Variants
!  Single Blocking Put-Get with Delayed Response Callback Option
•  This is a combination of Single Blocking Put-Get and Non-Blocking Put-then-Callback
•  Used in interactive scenarios where an immediate request is desired, but a callback response is
acceptable.
•  For example “Normally, we’d confirm you order right away, but our back-end system is down. Thank
you for your order - we will email you when it is completed’
•  Implementation
–  BPM makes a Single Blocking Put-Get
–  IF BPM gets the desired response in the desired time, THEN proceed as normal
–  ELSE BPM either gets a timeout, or a ‘your response will be delayed’ response from broker
–  BPM takes any relevant action e.g. notify the user
–  BPM then waits for a callback message which is the ‘actual’ response required
!  Single Blocking Put-Get with Delayed Response Pub-Sub Option
40

Single Blocking Put-Get with Delayed Response Callback Option: Diagram
41
Request Queue
Reply Queue
Request
Reply
Callback through BPM
Event Queue
Reply
Note: Reply is placed on
BOTH queues (reply and
callback)– is ignored/expired
on event queue if no process
available to correlate with it
i.e. happy path was taken.
Exception
Path
Exception
Path
Happy Path
Happy Path
Happy Path
Happy Path
Happy
Path

Blocking Put then Get:
!  Overview
•  This is an interactive pattern that differs from Single Blocking Put–Get in one important manner: It
allows BPM to make a very short lived action between the Put and the Get
•  Do not confuse this with the Non-Blocking Put-then-Callback pattern: that pattern allows for a larger
time-gap between the request and response.
•  Typical usage is to grey-out the request button from an interactive screen to avoid the ‘do not press
this button twice’ issue
!  AKAs
•  Disable Request, “Grey Out” the button.
!  Parent Pattern
•  Single Blocking Put–Get
!  Implementation
•  BPM Integration service serialises a BPM Data Object into a message which is placed on a queue.
The service then performs a very short lived action e.g. greying out a button. The Integration service
then does an MQGET with correlation to wait for the response. The response is then de-serialised
into BPM Data Object.
•  Broker implements a ???? take request and provide response pattern.
!  Error Modes
•  Modelled Error Response
•  Response Timeout
42

Blocking Put then Get: Diagram and Sequence
43
Request Queue Reply Queue
Request Reply
Use Correlation ID for correct reply

Blocking Put then Get: Variants
!  Similar variants to Single Blocking Put–Get
44

Non-Blocking Put-Callback
!  Overview
•  This is a longer-lived follow-on in the put-get series. It allows BPM to make a call to broker then drop
the thread. At a later point, broker sends a message back to BPM which starts the process again at
the next step.
!  AKAs
•  Async request/reply, External Activity, Intermediate Message
!  Parent Pattern
•  Request/Response: Non-Blocking Caller with Asynchronous Transport
!  Implementation
•  BPM Integration service serialises a BPM Data Object into a message which is placed on a queue.
The message contains a callback identifier that allows broker to send a correct callback message
back into the same process. The integration service finishes and the next BPD step is an intermediate
event.
•  Broker implements a ???? Take request then send callback message pattern
•  BPM receives the callback on the event queue. It then correlates back to the original process
instance and starts the BPD at the intermediate event activity.
!  Error Modes
•  Modelled Error Response in callback object
•  No Callback received
•  Callback received after BPD has moved on from IME (e.g. after timeout)
45

Non-Blocking Put-Callback: Diagram and Sequence
46
Event Queue
Reply
Request Queue
Request

Non-Blocking Put-Callback: Variants
!  Non-Blocking Put then Callback
•  This is where the BPD has multiple activities performing other processing after the request but before
the callback Intermediate Event is received
§  Non-Blocking Put Known-at-Design-Time-Multiple Callbacks
•  This is where one request gets multiple responses, where the number of responses is known at
design time
•  e.g. ‘Book Travel’ where responses are ‘Hotel’, ‘Flight’, ‘Car’
•  Multiple IME instances must be available to process the responses
§  Non-Blocking Put Known-at-Design-Time-Multiple Callbacks
•  This is where one request gets multiple responses, where the number of responses is known only at
run-time
•  e.g. ‘Get insurance quotes from these multiple companies’
•  Multiple IME instances must be available to process the responses – this must be capable of
changing at run-time.
!  Non-Blocking Put Unknown-Multiple Callbacks
•  This is where one request gets multiple responses, where the number of responses is unknown until
they actually arrive. The caller, even at runtime, does not know how many responses there are
•  Typically the process may wait for a maximum number of responses before a timeout is called and
the process moves on. This maximum may only be one!
•  Beware of ‘this is the last response’ approach – messages may not be in sequence!
47

Single Blocking Put–Get then Non-Blocking Callback
!  Overview
•  This is used where a BPM first wants a quick response to a call with some short lived logic, then waits for some long-
lived logic to run
•  For example ‘Thanks for your order, we’ve processed it and your order is 1234. We will let you know a delivery date
when we hear back from our shipping company’
•  Not to be confused with Single Blocking Put-Get with Delayed Response Callback Option or Fire, Validate then Forget
with Error Callback
!  AKAs
•  Short-Lived sync process calls long-lived async initiated process
•  Single Blocking Put-Get
•  Single Blocking Put then Non-Blocking Callback
!  Implementation
•  BPM does a Single Blocking Put-Get, but sends a callback location as part of the Put message.
•  Broker implements a ???? take request and provide response pattern. It sends the first response via correlation. It
then kicks off the long-running request.
•  BPM gets the short-running response and processes it. It then waits for the callback using an IME.
•  Broker sends the long-lived reply back to BPM through the event queue. The BPD picks up the message, fires the IME
and carries on along the BPD
!  Error Modes
•  Modelled Error Response or timeout from quick response.
•  Modelled Error Response or timeout from callback
•  No callback received
48

Single Blocking Put–Get then Non-Blocking
Callback: Sequence
49

Single Blocking Put–Get then Non-Blocking Callback : Diagram
50
Request Queue
Reply Queue
Request
Quick Reply
Event Queue
Long
Reply

Single Blocking Put–Get then Non-Blocking Callback:
Variants
!  Single Blocking Put–Get then Callback
•  This is where the BPD has multiple activities performing other processing after the initial request/
response but before the long-lived callback Intermediate Event is received
§  Single Blocking Put–Get then Known-at-Design-Time-Multiple Callbacks
•  This is where one request gets multiple long-lived responses, after the first short-lived one, where the
number of responses is known at design time
•  e.g. ‘Book Travel’ where responses are ‘Hotel’, ‘Flight’, ‘Car’
•  Multiple IME instances must be available to process the responses
§  Single Blocking Put–Get then Known-at-Design-Time-Multiple Callbacks
number of responses is known only at run time
•  e.g. ‘Get insurance quotes from these multiple companies’
•  Multiple IME instances must be available to process the responses – this must be capable of
changing at run-time.
!  Single Blocking Put–Get then Unknown-Multiple Callbacks
number of long-lived responses is unknown until they actually arrive. The caller, even at runtime,
does not know how many responses there are
•  Typically the process may wait for a maximum number of responses before a timeout is called and
the process moves on
•  Beware of ‘this is the last response’ approach – messages may not be in sequence!
51

Pub-Sub:
!  Overview
•  This pattern is where the broker initiates functionality on BPM. This is typically starting a process, but
can be any action that is driven by the event manager, typically via a UCA
•  BPM needs to send a ‘subscribe’ message to broker to register its interest in events
!  AKAs
•  Event listener, Broker Initiated Process, One-Way Broker->BPM, Start Message Event, Async
Initiated process.
•  Single Blocking Put–Get (Subscription)
•  Fire and Forget (Event from Broker)
!  Implementation
•  BPM Sends a subscription message to broker using the Fire and Forget pattern. The subscription
must contain a description of what events BPM is interested in, together with details as to where
broker must send the events
•  Broker receives the subscription request and updates its subscription store.
•  When an event is generated, broker sends the event to those BPM subscribers via the event
manager.
!  Error Modes
•  Subscription Request not possible (e.g. queue not found)
•  Subscription not supported (i.e. request to events that don’t exist)
•  Publish message sent to incorrect location
•  Published message not understood by BPM
52

Pub-Sub : Diagram and Sequence
53

Pub-Sub : Variants
!  Single Subscriber
!  Multiple Subscribers
!  Durable Pub-Sub
!  Get last published item
!  1st subscriber of multiple only gets the message (process once)
54

We Value Your Feedback
!   Don’t forget to submit your Impact session and speaker
feedback! Your feedback is very important to us – we use it to
continually improve the conference.
!   Use the Conference Mobile App or the online Agenda Builder to
quickly submit your survey
•  Navigate to “Surveys” to see a view of surveys for sessions
you’ve attended
56

Legal Disclaimer
•  © IBM Corporation 2014. All Rights Reserved.
•  The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in
this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject
to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing
contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and
conditions of the applicable license agreement governing the use of IBM software.
•  References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or
capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to
future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you
will result in any specific sales, revenue growth or other results.
•  If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete:
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will
experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
•  If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete:
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs
and performance characteristics may vary by customer.
•  Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus®
Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer
to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All
product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation.
IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines
Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both.
•  If you reference Adobe® in the text, please mark the first use and include the following; otherwise delete:
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
•  If you reference Java™ in the text, please mark the first use and include the following; otherwise delete:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
•  If you reference Microsoft® and/or Windows® in the text, please mark the first use and include the following, as applicable; otherwise delete:
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.
•  If you reference Intel® and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete:
Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and
other countries.
•  If you reference UNIX® in the text, please mark the first use and include the following; otherwise delete:
UNIX is a registered trademark of The Open Group in the United States and other countries.
•  If you reference Linux® in your presentation, please mark the first use and include the following; otherwise delete:
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
•  If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta
Bank, Acme) please update and insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration
purposes only.

Impact 2014 1147 - Bridging Business Process Management and Integration use cases

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Impact 2014 1147 - Bridging Business Process Management and Integration use cases

Similar to Impact 2014 1147 - Bridging Business Process Management and Integration use cases (20)

Recently uploaded

Recently uploaded (20)

Impact 2014 1147 - Bridging Business Process Management and Integration use cases