Potential Solutions Co Existence

Roman Agaev, M.Sc, PMPSupra Information Technology ltd.

Siebel co-existence

Date: 17/01/2010


Table of Contents

1Abstract..........................................................................................................32Potential solutions..........................................................................................3

2.1UAN – Universal Application Network..................................................3Integration Description.......................................................................4

2.2WBI – Websphere business integration...............................................4Integration Description.......................................................................5

2.3Siebel Integration Layer.......................................................................5Integration Description.......................................................................6

2.4Siebel Master Data Applications...........................................................6Integration Description.......................................................................7

2.5Third party custom application..............................................................7Integration Description.......................................................................7

3Criterions........................................................................................................83.1Solution complexity..............................................................................8

3.1.1Computation complexity.............................................................83.1.2Time complexity.........................................................................8

3.2Closely coupling...................................................................................83.3Reliability..............................................................................................83.4Scalability.............................................................................................83.5Time to market.....................................................................................83.6Simplicity..............................................................................................83.7Failover ability......................................................................................9

4Solution Matrix................................................................................................95Conclusion....................................................................................................116Appendixes...................................................................................................12

6.1Process/Module diagram – schematic level.......................................126.1.1Description...............................................................................126.1.2Discussion................................................................................12

6.2Module diagram – Siebel side schematic level...................................136.2.1Description...............................................................................136.2.2Discussion................................................................................13

6.3Inbound diagrams...............................................................................156.3.1Description...............................................................................166.3.2Discussion................................................................................16

6.4Outbound diagrams............................................................................176.4.1Description...............................................................................186.4.2Discussion................................................................................18


1 Abstract

The main aim of the document is discussing possible ways of co-existence of

two quite different versions of the same product.

There are several assumptions:

• First data migration will be performed by EIM (Enterprise Integration

Manager) process execution.

• Data must be integrated in real time

• The solution must achieve the aim within minimum efforts.

2 Potential solutions

2.1 UAN – Universal Application Network1

Universal Application Network (UAN) is an integration solution that provides a

library of prepackaged, industry-specific business processes that span

multiple applications within and across the enterprise. These processes are

primarily focused on customer interactions and reflect industry best practices.

UAN is built based on open industry standards such as Extensible Markup

Language (XML) and Web Services-enabling enterprises.

The solution uses abilities that are delivered by Siebel. Those abilities in fact

are bounded by previously done configuration. The main idea in UAN is

making different systems to talk the same language using common business

object and application independent cross-system business.

1 The solution requires integration middleware like BizTalk, TIBCO, WBI


Table 2-1: UAN logical structure

2.1.1 Integration Description

The Siebel Master Data Applications deployment uses the Universal

Application Network (UAN) framework and architecture to synchronize

account, contact, prospect, and household data across disparate systems.

Each application on the UAN can act as a source of new and updated

customer information and can also receive new and updated information from

other applications. The UAN Customer Lifecycle Management suite provides

integration business processes that route customer profile changes through

the Siebel Universal Customer Master Application to provide cleansing,

matching, and data enhancement. The Universal Application Network can

also synchronize customer information between Siebel Master Data

Applications and Siebel Business Applications (including previous versions).

The current UAN Customer Lifecycle Management integration business

processes are used primarily for scenarios in which multiple applications-

including Siebel Business Applications, back-office systems, and legacy

applications-store a copy of the customer profile and require Siebel Master

Data Applications to act as the primary registrar to determine the validity of

new and updated customer information. The UAN provides a reusable

integration solution with Siebel Master Data Applications.


2.2 WBI – Websphere business integration2

The solution uses abilities that are delivered by WBI. Those abilities in fact are

bounded by previously done configuration and dedicated server components

of Websphere. The main idea in WBI is making interface to the Siebel easy

and fast for an implementation without heavy interruption in the internal

processes of it.

Table 2-2: WBI logical structure


Monitored actions in monitored business components will store an event row

in previously defined and created table in Siebel's database using previously

defined and created support business layer.

WBI Connector Agent monitors the table mentioned above by using JDB and

if needed retrieves a row from Siebel's database according key stored there,

the retrieved message propagated to an MQSeries queue and peeked from

there by another Webshpere module (connector controller running in

Websphere ICS) that propagates it to the WBI Connector Agent that

processes given data by appropriate action.

2.3 Siebel Integration Layer

The solution uses internal abilities of the Siebel.

2 The solution requires several Websphere components installed and previously configuration added to the Siebel


Table 2-3: Siebel Integration Layer logical structure


Simple propagation of information through an integration middle-ware to the

endpoint, for easiness the transformation may be applied on every side. The

main point is usage of general and conventional tools provided by Siebel

environment.

2.4 Siebel Master Data Applications3

The solution uses applicative behavior of an applications like UCM (Universal

Customer Master) and abilities delivered by those applications including

markup language CRMML.

3 The solution uses CRMML (Customer Relationship Management Markup Language)


Table 2-4: UCM logical structure


As illustrated in Table 2-4: UCM logical structure, an inbound business

process flow starts with a Receiver Server Component, such as the MQSeries

or HTTP Receiver. The Receiver runs in the background, continuously waiting

for messages to arrive from external applications. After receiving a CRMML

message, the receiver then invokes the workflow process configured to

handle and process the data.

2.5 Third party custom application

The solution uses predefined interfaces like COM, JDB, and ActiveX.


There are several ways of integration, for example usage of JDB or COM

objects inside of source application that updates destination one by direct

updates, or usage of integration layer from outside, for example business

service or workflow execution through the URL request.


3 Criterions

3.1 Solution complexity

3.1.1 Computation complexity

The criterion is about an ability of making computation easy, encapsulated,

type oriented. In fact the main aid is making the computation of O (0)4.

3.1.2 Time complexity

The criterion is about an ability of making computation fast5.

3.2 Closely coupling

The criterion is about ability of different modules to exist independently each

from other.

3.3 Reliability

The criterion is about ability of relying on work that is about to be done by

some module without monitoring or some other action of that type.

3.4 Scalability

The criterion is about ability of growing. In fact the main aid is making system

that able to grow infinitely without any impact on functionality or some other

properties of a system.

3.5 Time to market

The criterion is about of time from the beginning of work on a solution till the

end.

3.6 Simplicity

The criterion is about difficulty level of chosen solution implementation, when

the aid is to make it easy as much as possible.

4 As a branch of the theory of computation in computer science, computational complexity theory describes the scalability of algorithms, and the inherent difficulty in providing scalable algorithms for specific computational problems.5 The time complexity of a problem is the number of steps that it takes to solve an instance of the problem as a function of the size of the input (usually measured in bits), using the most efficient algorithm.


3.7 Fail-over ability

The criterion is about ability to keep on working in case of partial fail and fast

recovery in case of entire system failure.

4 Solution Matrix

The following section deals with an issue of comparison between possible

solution regarding provided criterions.

• Computational Complexity6 – UAN just like WBI talks about using of

common object and provides a set of tools that underlies the concept,

UCM has a little bit different approach when in fact here in place of

common object we are using common application, all of those

approaches kindly difficult for an implementation, even whether

vendors are talking about time to market advantage in real life the

advantage is coming instead of flexibility, simplicity and decoupling the

solution become to be in many cases the real source of administrative

and development problems as well, in other words another potential

undesired point of errors. In opposite to approaches mentioned above

Siebel Integration Layer provides flexible, simple and very powerful

infrastructure that can be used for creation various types of

interoperable interfaces. The custom application in any cases will

provide much complicated solution than previously described ones.

• Time complexity – UAN, WBI, and UCM take us far away of straight

forward solution and became the way from getting input to providing

output a multistep one. Solution based on Siebel Integration Layer may

be much efficient exactly in places where those concepts may take

much more time.7 Custom application completely depends on efficiency

of conceptual approach, but in any case can't be much efficient than

solution based on Siebel Integration Layer.

• Closely Coupling –WBI makes applications be closely coupled in an

extremely way by using JDB fro integration purposes, UAN just like

6 Complexity theory deals with the relative computational difficulty of computable functions. This differs from computability theory, which deals with whether a problem can be solved at all, regardless of the resources required7 All of those approaches must use integration middleware like BizTalk, Websphere, TIBCO


UCM and Siebel Integration Layer solution much efficient and provide a

high level of decoupling. The custom application can't avoid the

coupling due to potential usage of COM or JDB interfaces for an

integration purposes.

• Reliability –WBI solution provides a good level of reliability when in fact

saves as events every action over integrated business components,

but this is just an approach and that's why may be implemented also in

UAN and Siebel Integration Layer solution without time or complexity

impact. UCM provides another, but still reliable approach (main

database). The custom application potentially has a least reliable

approach.

• Scalability – UAN and WBI solutions provide a good level of scalability

due to modularity usage concept, the main difference of those

approaches is an implementation platform, then UAN "sees" Siebel

system as a primary system in a given environment and WBI in

opposite way "supposes" that Siebel is only one of numerous systems.

UCM provides an extreme extension of UAN vision. In fact UCM

assumes that Siebel system is a dominant system in an environment.

Solution based on Siebel Integration Layer enough flexible to provide a

good level of scalability due to a fact, that the solution almost entirely

suppose to be implemented on Siebel platform which is scalable by

itself. Custom application probably will least effective and will suffer of

various administrative, development and deployment problems.

• Time To Market – WBI asserts short time to market parameter, just like

UAN and UCM the solution comes as product that underlies by well

argued concept, but consumes time for an understanding, deployment,

and integration and in many case changes that lead to an inappropriate

usage of a product. Solution based on Siebel Integration Layer

provides an effective, flexible and fast way of implementation, in

opposite way custom application probably will consume much more

time and at the end will provide a worse time to market.


• Simplicity – WBI, UAN and UCM very sophisticated and complicated

solutions that contain several undesired potential points of error.

Solution based on Siebel Integration Layer in opposite way much easy

and potentially may contain less such points. Custom application will

be also sophisticated and complicated.

• Fail-over ability –WBI provides a good level of recovering and fail-over

ability due to its modularity and "event driven" concept, UCM also

provides a good level of recovering and fail-over due to main "data

storage" concept. UAN, solution based on Siebel Integration Layer and

custom application have the same ability based on Siebel system's

abilities.

Table 4-5: Solution/Criterions matrix

Solution\

Criterion

Computational

Complexity

Time

Complexity

Closely

Coupling

Reliability Scalability Time

to

market

Simplicity Fail-

over

ability

Total

UAN 8 5 10 9 10 8 8 8 66WBI 8 5 7 9 10 10 8 9 66SIL8 9 8 10 9 9 9 10 8 72UCM9 8 5 10 9 9 8 8 9 66Custom 7 5 5 8 8 5 5 8 51

5 Conclusion

According the information provided above:

• UAN – is an overkill solution that conceptually provides solution for a

different need much wider than ours case, moreover the solution takes

a step forward and instead of integration middle-ware declares on

common object model. In fact the declaration assumes Siebel system

as primary system in an environment.

• UCM – is an overkill solution that conceptually needs to be based on

infrastructure provided by UAN and powers it by providing CRMML

language definition as a language for interoperability needs.

8 Siebel's integration layer9 Universal master data application


• Custom application – heaviest way to a solution, probably in some

cases seems to be easiest and most flexible one, but without any doubt

to adventurous.

• WBI – is a second best solution due to its conceptual contiguity that

entirely applies to ours needs, but the solution still much sophisticated

and potentially has much more points of error

• Siebel Integration Layer solution – the best among discussed solutions,

provides complex of characteristics that support it due to its simplicity,

flexibility, time to market and reliability.

6 Appendixes

6.1 Process/Module diagram – schematic level

Picture 6-1: Process/Module diagram

6.1.1 Description

The main approach assembles in a term of using physical field that holds

integration id from foreign system. The integration id field will get by default

value of primary key field and in case of integration error the value will persist

to be the default one. The errors handling mechanism will gather all of the


rows with same values in primary key and integration id fields and perform an

appropriate action.10

In above figure described schematic structure of proposed solution, when the

main details of the scheme are integration middle-ware, transport layer of

Siebel environment, application layer of Siebel environment and database.

6.1.2 Discussion

Within an assumption that integration middle-ware should not by closely

coupled with any application that's exposed its API through the middle-ware

the environment becomes to be strongly layered and fulfills OCI model.

Application layer of Siebel application encapsulates application, presentation

and session layers of OCI model and allows powerful user experience within

an application. Transport layer of Siebel application encapsulates transport

layer of OCI model and exposes user-friendly application programming

interface for sockets usage.

Integration middle-ware contacts peripheral systems like Siebel by its own

application layer that's been designed and exposed by other agents, when the

main aim of the middle-ware is information transportation from one to another

agent (system) with possible data transformation.

10 The value in integration id field will always be a primary key of the last updated row in an entire environment.


6.2 Module diagram – Siebel side schematic level

Picture 6-2: Component diagram

6.2.1 Description

The above figure represents modules that are interconnected and

interdependent by proposed solution boundaries.

6.2.2 Discussion

Proposed solution includes several modules:

• Application Object Manager (AOM) – foreground multi-threaded

component that allows simultaneous invocation of several application

instances.

• Workflow Process Manager – background multi-threaded component

that allows simultaneous invocation of several workflow instances.

• Workflow Policy Monitor – background singleton component that allows

monitoring and appropriate invocation of jobs tracked by workflow

policy definitions.

• Enterprise Application Integration Object Manager (EAI) – background

multi-threaded component that allows simultaneous invocation of

several application instances.


• Siebel Web {Server} Extension (SW{S}E) – two complement modules

that allows interconnection between web server and application server.

The connection handled by session layer and uses SISNAPI network

protocol.

• HTTP Module – exposed application programming interface that allows

usage of operation system abilities within context of TCP/IP

communication.

• Authentication Manager

• Database (DB2)

6.3 Inbound diagrams

Picture 6-3: Inbound state diagram


Picture 6-4: Inbound interconnection diagram

6.3.1 Description

The figures above represent inbound request handling, when the first figure

describes the process from state-to-state transition and the second one from

interdependency perspective.

6.3.2 Discussion

The inbound request handling must be implemented with very high level of

abstraction in purpose to allow easy expansion of current implementation by

newly defined entities without heavy administrative or design impact. Such

approach means that information regarding currently arrived message

reflected by its structure and encapsulated inside of it.

The usage of several multi-threaded components makes the solution highly

available and extensible thanks to resilient processing within an enterprise

server.

The arrived message goes through the strongly typed transformation

(integration object) and accommodation by EAI Siebel Adapter business

service11, in any case http response sent back in purpose to close an

integration circle.

11 Strongly typed transformation available thanks to common object model applied by integration middleware.


6.4 Outbound diagrams

Picture 6-5: Outbound state diagram

Picture 6-6: Outbound interconnection diagram


6.4.1 Description

The figures above represent an outbound request handling, when the first

figure describes the process from state-to-state transition and the second one

from interdependency perspective. Attention need to be paid for a second

figure, when two different (black, blue) colors represent different routes of

outbound request handling and common parts of it have its own independent

color (green).

6.4.2 Discussion

The outbound request has two different routes, when the first one uses

workflow policies (triggers) and the second one uses repeated component job.

The first route is the regular one when database change tracked by triggers

and handled by Workflow Policy Monitor12.

The second route is dealing with an errors occurred during an integration

attempt that's been done by the first route.

The message generated by EAI Siebel Adapter business service as a

sequenced step will be propagated to a destination using EAI HTTP Transport

business service13, according HTTP response from a destination system an

origin row will or won't be updated with integration id field value.

Attention need to be paid thanks to potential distributed transaction

invocation14.

12 The definition of Workflow Policy includes an action that needs to be performed in case of desired conditions satisfaction.13 Attention need to be paid due to potential Unicode or not trivial code-page data transportation.14 The issue must be handled by complex approach that will include data restriction and error handling.

Potential Solutions Co Existence

Technology

Transcript of Potential Solutions Co Existence