© 2014 IBM Corporation

IEC-1147 Bridging Business Process Management and Integration Use CasesRob Phippen (phippen@uk.ibm.com), IBM UKBrian Petrini (petrini@us.ibm.com), IBM US

Introduction

The use of IBM BPM (‘BPM’) and WebSphere Message Broker (‘Broker’) is becoming a commonly-deployed combination of productsEven without consideration for the technical needs of the

integration between the two, a large number of design patterns are emerging in the fieldThese 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 broker 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)

2

BPM and IIB Use-cases

4

BPM & IIB Use Cases

BPM is the consumer

BPM Advanced is the consumer

IIB is the consumer

5

BPM & IIB Use Cases

BPM is the consumer

BPM Advanced is the consumer

•Straight Through Processing

IIB is the consumer

Tooling and Technology Enablers:BPM standard and IIB

Overall ApproachBPM developer IIB developerCreate Process Application and

Business Process Design

Create BPM integration serviceDefine 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 aToolkit automatically creates a newSnapshot

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

ServiceDescriptor

XSDs

WSDL

Message Flow

Subflows

Click to create

operation subflow

Explore the IIB Integration Service - 2

ServiceDescriptor

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 hostname and port of the deployedservice 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:BPM Advanced and IIB

WebSphere Integration Developer

WebSphere Integration Developer is the integration tool that you use to author SOA-based services and choreograph them into business processes that you can deploy on 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 msg sent from WPS

WebSphere Process Server

WebSphere Message Broker

1. Receive inbound msg

2. Send reply msg

Sending a synchronous outbound request to WPS

WebSphere Process Server

WebSphere Message Broker

1. Send outbound request msg 2. Receive response msg

Sending an asynchronous outbound request to WPS

WebSphere Process Server

WebSphere Message Broker

1. Send outbound request msg

2. Receive response msg

IIB Wizards

To build this, you can start from IID . . .

1.Develop Business Process Application in WID first.

2.Export Project Interchange (PI) file.

3.Import PI into WMB to create message model and Broker SCA Definition.

4.Create message flow using the Broker SCA Definition.

Or you can start from IIB . . .

1. Generate Broker SCA Definition from Message Set in WMB.

2. Develop Message Flow using Broker SCA Definition.

3. Export SCA components, XSDs and WSDL from Broker SCA Definition.

4. Import SCA Components, XSDs and WSDL into WID.

5. SCA components are automatically created in the Assembly Diagram. Data types and interfaces are automatically added to the module.

Detailed Patterns and Implementation

35

Contents

BPM & IIB Use Cases

Tooling and technology enablers

Detailed patterns and implementation

Advanced patterns and implementation

Detailed patterns and implementationFire 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

36

Patterns in detail – How the patterns are describedOverview

• 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 patternParent Pattern(s)

• Any pattern or combination of patterns that this pattern is derived fromImplementation

• Notes as to how to implement this pattern in BPM and BrokerError Modes

• What can go wrong? Where can it go wrong?Notes

• Any other considerationsDiagrams and Sequences

• Displays the patterns visuallyPattern 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”

37

Fire and ForgetOverview

• 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?

38

Fire and Forget: Diagram and Sequence

39

Request Queue

Message

Request Ack Response

Fire and Forget: VariantsFire, 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 BPMFire 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 CallbackFire 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

40

Single Blocking Put-GetOverview

• 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

• Request not possible (e.g. queue not found)• Modelled Error Response: Invalid Request• Modelled Error Response: Logical Error• Response Timeout: No Response• Response Timeout: Response arrives after timeout period

41

Single Blocking Put–Get: Diagram and Sequence

42

Request Queue Reply Queue

Request Reply

Use Correlation ID for correct reply

Single Blocking Put–Get: VariantsSingle 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

43

Single Blocking Put-Get with Delayed Response Callback Option: Diagram

44

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

HappyPath

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

• Request not possible (e.g. queue not found)• Modelled Error Response• Response Timeout

45

Blocking Put then Get: Diagram and Sequence

46

Request Queue Reply Queue

Request Reply

Use Correlation ID for correct reply

Blocking Put then Get: Variants

Similar variants to Single Blocking Put–Get

47

Non-Blocking Put-CallbackOverview

• 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

• Request not possible (e.g. queue not found)• Modelled Error Response in callback object• No Callback received• Callback received after BPD has moved on from IME (e.g. after timeout)

48

Non-Blocking Put-Callback: Diagram and Sequence

49

Callback through BPM 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!

50

Single Blocking Put–Get then Non-Blocking CallbackOverview

• 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

Parent Pattern(s)• 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 BPDError Modes

• Request not possible (e.g. queue not found)• Modelled Error Response or timeout from quick response.• Modelled Error Response or timeout from callback• No callback received

51

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

52

Single Blocking Put–Get then Non-Blocking Callback : Diagram

53

Request Queue

Reply Queue

Request

Quick Reply

Callback through BPM 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• This is where one request gets multiple long-lived responses, after the first short-lived one, 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.Single Blocking Put–Get then Unknown-Multiple Callbacks

• This is where one request gets multiple long-lived responses, after the first short-lived one, where the 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!

54

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 eventsAKAs

• Event listener, Broker Initiated Process, One-Way Broker->BPM, Start Message Event, Async Initiated process.

Parent Pattern(s)• 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

55

Pub-Sub : Diagram and Sequence

56

Pub-Sub : Variants

Single SubscriberMultiple SubscribersDurable Pub-SubGet last published item1st subscriber of multiple only gets the message (process once)

57

Headline Goes Here

Level 1 bulletLevel 1 bullet

• Level 2 bullet• Level 2 bullet

– Level 3 bullet

58

Sample Pie Chart

59

Sample Bar Chart

60

Color Palette

61

Divider slide

Divider slide

Questions?

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

65

Thank You

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.