impact 2014 1147 - bridging business process management and integration use cases

59
© 2014 IBM Corporation IEC-1147 Bridging Business Process Management and Integration Use Cases Rob Phippen ([email protected]), IBM UK Brian Petrini ([email protected]), IBM US

Upload: brian-petrini

Post on 19-Aug-2015

11 views

Category:

Software


2 download

TRANSCRIPT

© 2014 IBM Corporation

IEC-1147 Bridging Business Process Management and Integration Use Cases Rob Phippen ([email protected]), IBM UK Brian Petrini ([email protected]), 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

BPM and IIB Use-cases

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

IIB Wizards

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

•  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

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

•  Request not possible (e.g. queue not found) •  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

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

45

Non-Blocking Put-Callback: Diagram and Sequence

46

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!

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

!  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 BPD

!  Error 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

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

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!

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.

!  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

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

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

56

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.