Introduction to TIBCO Active Matrix BusinessWorks SOA Suite Gokul Seshadri Architect-TIBCO CTS GWIM BPM Team.

Introduction to TIBCO Active Matrix BusinessWorks SOA Suite

Gokul SeshadriArchitect-TIBCO CTS

GWIM BPM Team

Agenda

• Speaker Introduction

• First Hour (8 am – 9 am) : AMX BW Ecosystem– Introduction to GWIM BPM Platform : Layers & Components– AMX BW Eco-system : TRA, BW, Plug-Ins, Adapters, Administrator etc.– Active Matrix BusinessWorks (AMX BW) & Usage Scenarios

• Second Hour (9 am – 10 am) : AMX BW Concepts– Service Development with AMX BW– Anatomy of a BW Process / Service– Anatomy of a BW Service

• Third Hour (10 am – 11 am) : AMX BW GWIM Case Study– Business and Workflow Services built for GRE Client Deepening Project

• Fourth Hour (11 am – 12 pm) : AMX BW Infrastructure– GWIM BPM Infrastructure– AMX BW HA/FT in GWIM BPM Infrastructure

2 Bank of America - Merrill Lynch: Confidential

Speaker – Gokul Seshadri

• Senior Architect with Client Technology Services (FSI) at TIBCO Software Inc.

• 12 Years in Financial Services Industry and 7 Years in TIBCO

• Author of several articles and a Text book – Check www.linkedin.com/pub/dir/Gokul/Seshadri

• Major projects with customers like Credit Suisse, DBS Bank, Citibank, Deutsche Bank, UBS Wealth Management and Bank of America-Merrill Lynch (2010 Jan - current)

• Recognition award from GBSWM-T&O for contributions to Global Referrals Engine (GRE) project in 2010

• Currently working under Tal Sadan in GWIM BPM Team (Distribution Group: DG GWIM BPM Services)


http://www.linkedin.com/pub/dir/Gokul/Seshadri

Why we are here?

• In the last 10 years, there has been a paradigm shift in building applications

• Business demands complete visibility and control over the eventual business process that is getting executed Resulting in BPM (what you draw is what we run)

• There is a growing desire to centralize and reuse common application / business logic required across multiple applications Resulting in SOA

• There is a dire need to access a variety of services built using different technologies and hosted in different environments in a unified manner Resulting in ESB

• All of the above assets need to be designed, hosted and managed independently Resulting in the growth of distributed / Component based development!


GWIM BPM Platform – Logical view

• A distributed / shared runtime infrastructure that provides hosting environment for all BPM - SOA based business applications


Server : HP BL 460 ClassOS : RH 5.5 LinuxCluster : RHCDatabase : Oracle 11G RAC

GWM BPM Platform Components and Services

Oracle iPE

BPFBPF

QSFQSF

Oracle QSF

GFSSAN

CLIENTSYSTEMS

CLIENTSYSTEMS

BACKENDSERVICES

BACKENDSERVICES

Calls from / to External systems

Calls to Oracle Database

TIBCO JMS Messaging Calls

TIBCO iProcess BW Plug-inTIBCO iProcess BW Plug-in

TIBCO iProcess Engine(Business Process Management)


TIBCO EMS Messaging Infrastructure

Administration Bus

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

BW iProcess Plug-inBW iProcess Plug-in

TIBCO Administrator

TIBCO Administrator

Application Services Layer

Messaging Layer

Business Process Mgmt LayerCommon Services Layer

Application Services (SOA)

Layer

GWIM Specific: Common Services

Messaging Layer

Business Process Management Layer

GWIM BPM Platform Components

• Application Services Layer (SOA)– Products : TIBCO Active Matrix BusinessWorks (AMX BW) Runtime, TIBCO

BW-iProcess Plug-in, TIBCO Cobol Copybook Plug-in and other TIBCO 3rd Party Adapters / Plug-ins

– Assets: Application specific services and processes – Real-time and batch (time based)

– Runtime: Typically, two or more engines per application/project - running on multiple hosts

– Usage: External (Client application facing) and Internal (usage within the platform) Services

– Visibility: SOA One View (GWIM App)

• Messaging Layer– Products : TIBCO Enterprise Messaging Service– Assets : EMS Brokers (Instances of TIBCO EMS) with application specific

queues and topics – Real-time and batch (time based)– Runtime: Typically, one EMS Broker per project running on two hosts– Usage: Request-Response (synchronous and asynchronous), Publish-

Subscribe (asynchronous) and other complex types (Topic to Queue, Server to server etc.)

– Visibility: EMS Explorer (GWIM App)


GWIM BPM Platform Components

• Business Process Management Layer (BPM)– Products : TIBCO iProcess Suite, TIBCO iProcess-BW Server Plug-in– Assets : Application specific Business Process Models (aka Procedures)– Runtime: Typically, one iProcess node per application– Usage: Business process models that represent the actual business process– Visibility: BPM Admin / BAM Spotfire GUI (under development)

• Common Services Layer (GWIM Specific)– QSF / One View : Logging and Auditing Services– BPF / PMWS : BPM Services


Well… why so many layers / containers??

• Independent development and management of various assets implies independent runtimes for deploying them

• There are components that get reused across applications their scaling and availability requirements will be governed by multiple applications

• The technical requirements of these engines are very different!– Example: A BPM Engine is an absolute state machine whereas a SOA Service

will be typically stateless


BW Host

Active Matrix BusinessWorks Eco-System

• AMX BW Ecosystem consists of a number of components which interact with one another during design time / runtime


Java Runtime Environment

TIBCO Runtime Agent TPCL Designer

HawkRendezvous

TIBCO TRA Suite

TIBCO Active Matrix BusinessWorks

TIBCO BW-iProcess Plug-in

BW Designer PalettesBW Runtime Environment

TIBCO BW-CCB Plug-in

BW-iProcess Palettes*

BW-CCB Palettes

TIBCO Messaging Bus (EMS / RV)

Administrator Host

TIBCO TRA Suite

TIBCO Administrator

GWIM specific design time libraries

Admin Runtime

Design-time Usage

• During design time, a developer develops his assets on his desktop and deploys on to a remote Administrator


Developer Desktop (BW Host)


TIBCO Runtime Agent TPCL TIBCO Designer

HawkRendezvous

TIBCO TRA Suite






BW-CCB Palettes


Administrator Server

TIBCO TRA Suite

TIBCO Administrator

GWIM specific design time libraries – QSF, Templates etc.

JRE

TIBCO Runtime Agent

Hawk

Admin Runtime

Runtime Usage

• AMX BW Ecosystem consists of a number of components which interact with one another during design time / runtime


GWIM Server (BW Host)


TIBCO Runtime Agent TPCL Designer

HawkRendezvous

TIBCO TRA Suite






BW-CCB Palettes


Administrator Server

TIBCO TRA Suite

TIBCO Administrator

GWIM specific design time libraries

JRE

TIBCO Runtime Agent

Hawk

Admin Runtime

TIBCO Designer IDE for developing Services


Typically, you do not write a single line of Code! The

engine does not generate any code either!

TIBCO Administrator


TIBCO AMX BW Usage Scenarios

• AMX BW as an Integration Engine– Core purpose: Integrate with external systems / applications / components via

an established transport protocol and messaging format agreed upon– Supported transports: TCP, HTTP, HTTP(S), FTP, JMS, MQ, Web Services etc.– Supported message formats: XML, SOAP, Delimited / Fixed length– Example 1: Call an IF protected Web service using NTLM Authentication

(GWIM)– Example 2: Receive a Copybook formatted message from a Mainframe system

using IBM MQ (GWIM)– Example 3: Invoke a Business Operation in SAP

• AMX BW as a Service Hosting Engine (SOA Platform)– Core purpose: Host Business / Technical services within BW Container– Supported flavors: SOAP/HTTP (S), SOAP/JMS*– Example 1: Host a BW Service which provides all the GWIM account

relationships of the Customer (GWIM)– Example 2: Host a BW Service which returns all the transactions of a given

Account ID for a given period (GWIM)


TIBCO AMX BW Service Client & Service Host

• AMX BW can be a service provider or a service host; sometimes a single service may include both flavors...




Oracle iPE

BPFBPF

QSFQSF

Oracle QSF

GFSSAN

CLIENTSYSTEMS

CLIENTSYSTEMS

BACKENDSERVICES

BACKENDSERVICES








Administration Bus

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine


TIBCO Administrator

TIBCO Administrator


Messaging Layer


BW as a Service Provider (Host)

BW as a Service Client

TIBCO AMX BW Usage Scenarios

• AMX BW as a Workflow Engine (Service layer below BPM)– Core purpose: To execute all system related tasks in a business process

hosted in TIBCO iProcess Engine– Supported flavors : BW-iProcess Service Agent– Example 1: Make a call to Siebel to create an appointment for a new Prospect

as a part of Enterprise Referral Creation Business Process– Example 2: Update the status of a SMARTS request to Siebel as a part of

SMARTS business process

• AMX BW as a Mapping / Transformation / Routing Engine (aka Mediation Components)

– Core purpose: Provide a set of Data / Protocol transformation and routing service which will be used by multiple business services

– Example 1: A process that receives a given Copybook Message from IBM MQ Q, transforms the message into another Copybook format and put it into another Queue (GBR Project)


TIBCO AMX BW Service Client & Service Host

• AMX BW can be a Workflow Service provider whose services can be invoked by a business process hosted in a BPM Engine (iProcess)




Oracle iPE

BPFBPF

QSFQSF

Oracle QSF

GFSSAN

CLIENTSYSTEMS

CLIENTSYSTEMS

BACKENDSERVICES

BACKENDSERVICES








Administration Bus

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TRA/HawkTRA/Hawk

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine

TIBCO Business

WorksSOA Engine


TIBCO Administrator

TIBCO Administrator


Messaging Layer


BW as a Workflow Service

End of Section One

TIBCO AMX BW Service Development

• Step 1: Create a BusinessWorks Project– A project is a design time container for all assets that will be developed– Typically it is a hierarchical tree structure with various folders and sub-folders– A Project includes

• All Process Definitions• Global Variables• Shared Schemas (XML)• Shared Connections (JDBC / HTTP etc.)

– A project does not impose any restrictions on the runtime deployment choices One project may eventually result in multiple deployment assets

– It is better to have all development activities under one project umbrella and use some kind of version control system to enable various developers to work on different components / services

• Step 2: Identify all the Business / Workflow Services– What are all the Business Services that need to be built for this Project ? Do

any of them already exist?– What are all the Workflow Services that need to be built for the underlying

Business Process? Do any of them already exist?




Project Name

Global Variables

Shared Connections


• Step 3: Design the Interfaces Abstract WSDL / Schemas / Protocols

– What are the business Operations involved?– What is the Input and Output of each Operation?– What is the Error Message that needs to be provided back to the Client (in

case of failure) ?– How do I make use of Common Data Models (CDM)?– What are the transport protocols that need to be supported by this service?

• Step 4: Implement the Business Operations– Use the BW Service Building wizard or any other pre-existing Service

Grammar to implement the Operations– Copy and paste existing processes and start modifying them!– There should be no need for writing any code in most cases!




Business Service

Operation

Implementation

Service Container

Abstract WSDL

Calling various sub processes as a part of the operation


• Step 5: Package the Service / Processes– In how many containers are the Services are going to run? – What is the HA/FT/LB requirements for the services?– Do the services / request handling have any special behavior? (Sequential

processing etc.)– How many instances of the Service need to be deployed?

• Step 6: Deploy and Run!– The packaged services need to be deployed on relevant BW Servers using

Administrator– Remote deployment of services is possible via Administrator (Access

restricted to DEV only/ From IDE onwards, a request needs to be submitted to SOA Ops)




Deployment Archive

Processes packaged inside the archive

Assets within the deployment archive

Anatomy of a AMX BW Processes

• A BW Process consists of:– Process Starters (any trigger that can invoke the process)– Activities constituting the process, linked by conditions– Process End– Exception handling if any


Process

Process

Starter

Activities &

Conditions

Process

End

Catch

exceptions

Handle

exceptions

Call

Sub-processes

Protocol based receiver: Optional

Specific Input payload: Optional

Activities typically represent various chunks of work constituting the core business logic

A complex process can be sub divided into a number of Sub-Processes

If called from another process, the end activity may respond with a specific output

Capture exceptions that may occur as a part of process execution

Handle select or all exceptions

Examples

• Try to identify the Process starters and activities!


BW Activities

• AMX BW natively supports an extensive array of activities commonly required for all kinds of Service development

– If you do not have something that you need,

just write a piece of code and plug-in!


Data Transformation and Mapping

• Activities provide room for transforming data– Each activity has visibility into all the Data elements of previous activities– Extensive set of Xpath functions support various kinds of Data Transformation– Custom functions can be integrated if necessary


BW Process makes use of…

• Global Variables– A set of variables that can be defined at the project level– Simple data types supported – Integer, String, Boolean, Password etc.– Available for all Processes within the Project; Scope is limited to the engine

runtime– During deployment, the Global variables can be changed across environments

via XML files and Metafiles (Name – Value Pairs)

• XSD Schemas– Defines the grammar for Data structures and Objects used in the Project– Example: A Prospect Schema that captures all the required attributes for a

prospective Customer

• Shared Resources & Connections– HTTP Connections, Database Connections, TCP Connections etc.– Certificates and Passwords– WSDL of external services– XSD Schemas are also shared resources !


Examples

• Bullets


Business Service

Operation

Anatomy of a AMX BW Service

• A BW Service makes use of all the facilities and assets in the Suite


Processes

Sub-Process

Sub-Process

Sub-Process

Operation

Processes

Sub-Process

Sub-Process

Sub-Process

Operation

Processes

Sub-Process

Sub-Process

Sub-Process

HTTP Binding JMS Binding Other Bindings

Global

Variables

Shared

Resources

Concrete WSDL

Abstract WSDL

Anatomy of a AMX BW Service


Business Service

Operation

Operation Starters

Service Container

Abstract WSDL

End point bindings

Sub processes within an Operation Resulting concrete WSDL

End of Section Two

GWIM Case Study : Client Deepening

• Business Vision– A centralized process to manage the lifecycle of a lead / referral (Customer /

Prospect) across different LOBs (from Pitcher to Catcher)

• Business Justification– Bank of America saw lot of opportunities to sell brokerage products to its

large retail customer base– Lack of a centralized / well managed process made it difficult to track the

referral lifecycle– The Global Customer Coverage team (GCC) would monitor/guide all medium /

large scale referrals

• Business Requirements– BRD for a GUI for associates to refer prospects (Referral Smart form)– BRD for a GUI for GCC to monitor & manage referrals (GCC Dashboard)– BRD for a centralized repository for all referral information (Global Referral

Engine or GRE)– An excel spreadsheet detailing the lifecycle of a referral from start to end


Understanding the “real” requirements

• What business really meant by “managing referral lifecycle”?– The Excel Spreadsheet told us that there was an underlying business process

that was driving the whole flow– It is this business process that touched upon Referral Smart Form, GCC

Dashboard and GRE– This business process would need access and connectivity to a whole slew of

systems, applications and enterprise services…– This business process will be subjected to frequent changes and

modifications, as business expands the scope of this project to touch upon more and more LOBs / systems down the line…

– While BRDs are focused on behavior and experience derived from the system, we need to look for the underlying processes that are driving that behavior!

• Integration needs– Ability to invoke a variety of GWM Enterprise Web service operations

(Enterprise CTA, Accounts Summary, Balances, Account traits etc.)– Ability to integrate with Siebel, SFDC, ACCL etc– Ability to be invoked by a variety of LOB systems and applications to be used

by the Primary Referring Associates (PRA)


Referral Business Process (BPM)

Workflow Services (SOA)

Client Deepening: High level Architecture


External Systems External Systems External Systems

Pitcher

Other

Systems

Smart Form

GUI

GRE Repository

Business

Services

(SOA)

GRE Core ServicesGCC

Dashboard

Catcher

Various

Systems

Integration with various systems

and services handled at a services level

One unified service interface being exposed

to a variety of Java and .Net clients

GRE truly remains as a global repository

The complete life cycle of a referral managed in one place – from start

to finish

As the project grows, changes to the business process will be

absorbed here

As the logic to external connectivity changes / gets modified, corresponding Integration

service alone are affected

AMX BW Services built for Client Deepening

• Referral (Business) Service : HTTPS Binding– Create Referral()– Update Referral()– GetReferralsBySendingLOB()– GetReferralsByReceivingLOB()– GetReferralsBySendingAssociate()– GetReferralsByReceivingAssociate()

• Referral Workflow Service: EMS Binding– CreateReferralID()– AddReferral()– SendReferral()– GetPrimaryCoverageOfficer()– InsertReferralData()– PushToSFDC()– SendNotification()– AccountEnrichment()– AccountHouseholdView()– GetAssignedClientCoverageList()


Anatomy of Referral Service


Create Referral Data Structure (Schema)


Anatomy of Referral Workflow Service


Example of a Complex Operation


GWIM SOA Applications in Production

• Several GWIM applications are already using AMX BW in Production…

– EAO : New Enterprise Account Opening– OAO : Online Account Opening– e-Form : Legacy Account Opening using PDF– Master Profile : Creation of Master Profile in the Client Hub– FAC Messaging– Referral / Client Deepening– SMARTS : Case management that supports fulfillment of banking requests

from WM clients– Affiliate Sharing– CCP Compliance Messaging– COMPUS Order Management

• Out of all the projects in Production today, there is not even a single project without AMX BW Assets. There are projects without the BPM Layer (like COMPUS)


End of Section Three

Upcoming GWIM BPM-SOA Platform…

• Joint Effort across the organization to establish a new platform to support growing BPM-SOA type applications

– HP BL460 Class Servers– Linux RH 5.5 OS– Four PODs across two Data centers

• Separate tiers for each major component, with scale out capability for each tier (SOA, BPM, Messaging etc.)

• Eight dedicated environments and Four Production PODs spread across two Data Centers

– Platform Engg., Dev, Systems Engg., IDE, QA & QA2 (2 PODs), PROD A, B, C & D, Performance Engg., Staging


GWIM BPM SOA Platform Environments

42

Platform Engineering Dev Systems

Engineering IDE

QA

QA2

PROD

A

PROD

B

PROD

C

Performance

Testing

Staging

Dual Pod Used for

Platform Cert including HA/C&R

CHP Based Platorm for App Dev testing

CHP Based Platorm for Application Integration

Dedicated Full POD for Perf Testing

Dedicated Full POD for

Dev/FTG Cert

PROD

D

Dedicated Scaled Down

POD for Emergency

Release Cert

2 Dedicated Full PODs for QA Cert

(2 Releases)

4 Dedicated Full PODs to Support full Dark Pod and Swing

with no C&R risk

The four Production PODs

• Four Production PODs distributed across two Data Centers would provide support for a true Dark POD swing capability


POD A (Prod) - ACTIVE

Physical Host

1P

Physical Host

1P

POD B (Dark Pod)

Physical Host

2P

Physical Host

2P

Physical Host

3P

Physical Host

3P

Physical Host 1DP

Physical Host 1DP Physical

Host 2DP


Host 3DP

Physical Host 3DP

POD C (C & R)

Physical Host 1R

Physical Host 1R

POD D (C & R - Dark Pod)

Physical Host 2R

Physical Host 2R

Physical Host 3R

Physical Host 3R

Physical Host

1-DC&R

Physical Host

1-DC&R

Physical Host

2-DC&R

Physical Host

2-DC&R

Physical Host

3-DC&R

Physical Host

3-DC&R

Physical Host

4P

Physical Host

4P

Physical Host

5P

Physical Host

5P

Physical Host

6P

Physical Host

6P

Physical Host 4DP


Host 5DP


Host 6DP

Physical Host 6DP

Physical Host 4 R

Physical Host 4 R

Physical Host 5R

Physical Host 5R

Physical Host 6R

Physical Host 6R

Physical Host

4-DC&R

Physical Host

4-DC&R

Physical Host

5-DC&R

Physical Host

5-DC&R

Physical Host

6-DC&R

Physical Host

6-DC&R

Data Center 1 - Prod

Data Center 2 – C&R

Disaster Failover

New codeRelease

Cluster Groups and Cluster Failover

• Multiple cluster groups will be configured on each SOA Server in the GWIM BPM Platform – each with its own VIP


POD A (Prod) - ACTIVE

Host 1PHost 1P

POD B (Dark Pod)

PassivePassive

Host 1DPHost 1DP

PassivePassive

POD C (C & R)

Host 1RHost 1R

POD D (Dark Pod)

PassivePassive

Host 1-DC&R

Host 1-DC&R Passive

Passive

Data Center 1 - Prod

Data Center 2 – C&R

Svc Group App1-1A-p

Svc Group App1-1A-r

Svc Group App2-1A-p

Svc Group App1-1A-p

Svc Group App2-1A-r

Svc Group App1-2A-p

During cluster failover, service group and VIP could fail over to passive host

Each service group has a corresponding pair in C&R, with a different VIP.

Each service group has a corresponding pair in Dark POD, with a different VIP.

VIP11Ap

VIP21Ap

VIP11Ar

VIP21Ar

VIP11Ap

ClusterFailover

VIP12Ap

AMX BW Engine Configuration


BW Host 1-PActive

BW Host 2-PActive

BW Host 3-PPassive

BW Group App1-1A-p BW Group App1-1B-p

App BW Engine App1-1-1a

App BW Engine App1-1-1b

SAN SAN

BW Server SpecificationsHardware: HP BL 460c G6OS: RedHat 5.5, 64 BitCluster: RedHat Cluster Suite

Data Center 1

POD A - Prod

App BW Engine App1-2-1a

App BW Engine App1-2-1b

BW App2-1A-p

App BW Engine App2-1-1aSAN

BW App2-1B-p

App BW Engine App2-1-1bSAN

App1 has 2 Services: App1-1 and App1-2. These two are deployed on to two service groups as two instances: App1-1-1a and App1-1-1b

Note:BW Engines and Service groups highlighted in Yellow will be considered as examples for the rest of this document.

It is not mandatory to evolve independent Svc groups for each app. Sometimes, a given Svc group can host services from multiple apps

App 2 currently has only one service. So, two instances of this service are run in two hosts.

VIP11Ap

VIP21Ap

VIP11Bp

VIP21Bp

AMX BW HTTP Service LB Configuration


BW Host 1-PActive

BW Host 2-PActive

BW Host 3-PPassive

BW Group APP1-1A-p BW Group APP1-1B-p

BW Engine App1-1-1a

Active

BW Engine App1-1-1b

ActiveSAN SAN

Net scalarVirtual IP NS1A

EIB URL

Non GWIM Client

Requests alternatively routed to 2 servers

Responses

WIP 11A

Data Center 1

POD A - Prod

VIP11Ap VIP11Bp

GWIM Client

Responses

Net scalar type solutions are mainly used when Clients use HTTP protocol to connect to BW Services

BW Engine Cluster Failover


BW Host 1-PActive

BW Host 2-PDown

BW Host 3-PActive

BW Group APP1-1A-p BW Group APP1-1B-p

BW Engine App1-1-1a

Active

BW Engine App1-1-1b

ActiveSAN SAN

Data Center 1

POD A - Prod

BW Group APP1-1B-p

BW Engine App1-1-1b

DownSAN

VIP11Ap VIP11Bp

Net Scalar will re-point to the same Virtual IP – but in the new Host

VIP11Bp

Red Hat Cluster Failover

Net scalarVirtual IP NS1A

Client Requests

Responses

WIP 11A

Client Requests

Responses

Requests alternatively routed to 2 servers

Useful Info…

• Our Email / Distribution list: DG GWIM BPM Services

• GWIM BPM Share point URL: http://sharepoint2.bankofamerica.com/sites/gwimbpm/default.aspx

• BPM Resource Documentshttp://sharepoint2.bankofamerica.com/sites/gwimbpm/BPM%20Services%20Resources%20Documents/Forms/AllItems.aspx

• This Training Deck: http://sharepoint2.bankofamerica.com/sites/gwimbpm/BPM Services Resources Documents/TIBCO Products Overview/Tibco Product Training

• TIBCO Community: www.tibcommunity.com


THANK YOU VERY MUCH!

http://www.tibcommunity.com/

Introduction to TIBCO Active Matrix BusinessWorks SOA Suite Gokul Seshadri Architect-TIBCO CTS GWIM BPM Team.

Documents

tibco bwiprocess

gwim bpm services

bpm soa

tibco iprocessbw server

tibco software

tibco author

tibco iprocess suite

business applications