Potential Solutions   Co Existence
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Potential Solutions Co Existence

  • 2,335 views
Uploaded on

The implementation within the Siebel platform boundaries (version 6,7)

The implementation within the Siebel platform boundaries (version 6,7)

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,335
On Slideshare
2,329
From Embeds
6
Number of Embeds
2

Actions

Shares
Downloads
66
Comments
0
Likes
0

Embeds 6

http://www.supratech.co.il 4
http://supratech.co.il 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. Siebel co-existence Date: 17/01/2010
  • 2. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. Table of Contents 1Abstract............................................................................................................3 2Potential solutions............................................................................................3 2.1UAN – Universal Application Network...................................................3 Integration Description........................................................................4 2.2WBI – Websphere business integration................................................4 Integration Description........................................................................5 2.3Siebel Integration Layer.........................................................................5 Integration Description........................................................................6 2.4Siebel Master Data Applications...........................................................6 Integration Description........................................................................7 2.5Third party custom application..............................................................7 Integration Description........................................................................7 3Criterions..........................................................................................................8 3.1Solution complexity................................................................................8 3.1.1Computation complexity..............................................................8 3.1.2Time complexity..........................................................................8 3.2Closely coupling....................................................................................8 3.3Reliability...............................................................................................8 3.4Scalability...............................................................................................8 3.5Time to market.......................................................................................8 3.6Simplicity................................................................................................8 3.7Failover ability........................................................................................9 4Solution Matrix.................................................................................................9 5Conclusion.....................................................................................................11 6Appendixes....................................................................................................12 6.1Process/Module diagram – schematic level........................................12 6.1.1Description................................................................................12 6.1.2Discussion.................................................................................12 6.2Module diagram – Siebel side schematic level...................................13 6.2.1Description................................................................................13 6.2.2Discussion.................................................................................13 6.3Inbound diagrams................................................................................15 6.3.1Description................................................................................16 6.3.2Discussion.................................................................................16 6.4Outbound diagrams.............................................................................17 6.4.1Description................................................................................18 6.4.2Discussion.................................................................................18
  • 3. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 1Abstract 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. 2Potential solutions 2.1UAN – 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
  • 4. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. Table 2-1: UAN logical structure 2.1.1Integration 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.
  • 5. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 2.2WBI – 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 2.2.1Integration Description 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.3Siebel 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
  • 6. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. Table 2-3: Siebel Integration Layer logical structure 2.3.1Integration Description 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.4Siebel 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)
  • 7. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. Table 2-4: UCM logical structure 2.4.1Integration Description 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.5Third party custom application The solution uses predefined interfaces like COM, JDB, and ActiveX. 2.5.1Integration Description 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.
  • 8. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 3Criterions 3.1Solution complexity 3.1.1Computation 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.2Time complexity The criterion is about an ability of making computation fast5. 3.2Closely coupling The criterion is about ability of different modules to exist independently each from other. 3.3Reliability 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.4Scalability 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.5Time to market The criterion is about of time from the beginning of work on a solution till the end. 3.6Simplicity 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.
  • 9. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 3.7Fail-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. 4Solution 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 UCM and Siebel Integration Layer solution much efficient and provide a high level of 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 required 7 All of those approaches must use integration middleware like BizTalk, Websphere, TIBCO
  • 10. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 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.
  • 11. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. •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 Computational Time Closely Reliability Scalability Time Simplicity Fail- Total Criterion Complexity Complexity Coupling to over market ability UAN 8 5 10 9 10 8 8 8 66 WBI 8 5 7 9 10 10 8 9 66 SIL8 9 8 10 9 9 9 10 8 72 UCM9 8 5 10 9 9 8 8 9 66 Custom 7 5 5 8 8 5 5 8 51 5Conclusion 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. •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 8 Siebel's integration layer 9 Universal master data application
  • 12. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. •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. 6Appendixes 6.1Process/Module diagram – schematic level Picture 6-1: Process/Module diagram 6.1.1Description 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. 10 The value in integration id field will always be a primary key of the last updated row in an entire environment.
  • 13. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.1.2Discussion 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. 6.2Module diagram – Siebel side schematic level Picture 6-2: Component diagram 6.2.1Description The above figure represents modules that are interconnected and interdependent by proposed solution boundaries.
  • 14. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.2.2Discussion 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)
  • 15. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.3Inbound diagrams Picture 6-3: Inbound state diagram Picture 6-4: Inbound interconnection diagram
  • 16. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.3.1Description 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.2Discussion 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.
  • 17. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.4Outbound diagrams Picture 6-5: Outbound state diagram Picture 6-6: Outbound interconnection diagram
  • 18. Roman Agaev, M.Sc, PMP Supra Information Technology ltd. 6.4.1Description 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.2Discussion 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.