Co-existence of Siebel versions 6 and 7

Client/Server paradigm and itsImplementation within Siebel

Author: Roman AgaevDate: Tuesday, March 27, 2007Contents1 Abstract41.1 Messaging ability on browser side41.2 Messaging ability on server side41.3 Messaging ability without client context42 Analysis42.1 Siebel's part42.2 Client/Server (peer to peer)52.2.1 Client solution52.2.2 Server solution52.2.3 Loader solution53 Design/Implementation63.1 Siebel's part design63.2 Siebel's part proposed implementation63.2.1 Browser Side73.2.2 Server Side113.3 Client/Server implementation143.3.1 Client implementation153.3.2 Server implementation183.3.3 Loader implementation203.4 Usage examples214 ShowBrowserSideMessage215 ShowServerSideMessage216 Conclusion216.1 Discussion217 Appendixes22

FiguresFigure 31: Common Messaging Engine browser script - PreInvokeMethod event7Figure 32: Common Messaging Engine browser script - PreCanInvokeMethod event8Figure 33: Common Messaging Engine browser side - ShowBrowserSideMessage9Figure 34: Common Messaging Engine browser side - MessageException10Figure 35: Common Messaging Engine server side - PreInvokeMethod event11Figure 36: Common Messaging Engine server side - PreCanInvokeMethod event12Figure 37: Common Messaging Engine server side - ShowBrowserSideMessage13Figure 38: Common Messaging Engine server side - ShowServerSideMessage14Figure 39: Common Messaging Engine ClientServer - Client side15Figure 310: Common Messaging Engine ClientServer - Server side18Figure 311: Messaging Engine browser side - loader20Figure 412: Common Messaging Engine - Client side message invokation21Figure 513: Common Messaging Engine - Server side message invokation21

Abstract Messaging ability on browser sideThere is a need for messages of different type creation whether the process has been started from browser side. Those types are:Alert1 Siebel eScript language presents SWEAlert function as substitute function for regular JavaScript's Alert. In some circumstances the ShowDailogBox also may be used. For additional information please refer to Siebel Object Interface Reference Guide.

the regular message box, just like MessageBox from windows.h

Confirm the message box with possible multiple answers, just like MessageBox from windows.h

Prompt the message that allows interaction with users, just like InputBox of Visual Basic

The standard Siebel environment provides the ability as its integral elementMessaging ability on server sideThere is a need of message pop up for a system user through the business process which is running on server side and has been instantiated on that side also, or within the process with several divergences that cause to disability of doing so as result of potential multiple bidirectional jumps between server and browser side.The standard Siebel environment provides the ability just by RaiseErrorText function exposition, when the main disadvantage of the option is that in fact this function instantiates the internal error and no following script or related process are not further executed.Messaging ability without client contextThere is a need of system user's messages accumulation without a need of his/her current state as logged in and propagation of those messages to their recipient when the system user will log in to the system.The standard Siebel environment doesn't allow this kind of functionalityAnalysisSiebel's partAs part of final solution the new Business Service will be created. The Business Service will be exposed as cacheable one in order to simplify its methods approach and permit data structure managing along the user's session, when the session's life cycle will be Business Service's also. The Business Service will encapsulate the complexity of that kind of management and provide an application programming interface (API) for developer's needs.This architecture will allow system user's messages queue management.Client/Server (peer to peer)As part of final solution two win32/linux applications can be designed, when the interconnection can be based on xmlrpc (http://www.xmlrpc.org).The usage of win32/linux applications and native C++ language gives an ability of different frameworks boundaries breakage working strictly on processor itself.Client solutionClient's side application must act as residential process (daemon) that will listen to predefined port for inbound call and according the call recognition will perform bounded set of actions. (simple .exe file)2 Implementation within C++ environment

Server solutionServer's side application must act as client's side daemon invoker. For that purposes the implementation must assume that the call process will start and end synchronously. (simple .dll file)3 Implementation within C++ environment

Loader solutionThe Client's side application must be loaded by some external application or by Siebel's web client, when the second option preferable.The main aim of the loader is prevention of simultaneous work of several daemons that listen to the same port in case when user has its own machine, and in case of Citrix or similar environment the loader must regulate the ports among different similar processes.4 Implementation within Siebel eScript environment using JavaScript native syntax

Design/ImplementationSiebel's part designThe design messaging engine's Siebel's part will be handled creating cacheable Business Service Common Messaging Engine BS. The Business Service will consist of several methods and populated events as following:Method/EventDescription

GetMessagesStackRetrieves messages regarding current engine session.

PopMessagePops message from messages data structure.

PushMessagePushes message in messages data structure.

ShowAsynchServerSideMessageShows message out of interactive session.

ShowBrowserSideMessageShows message with regular JavaScript abilities.

ShowServerSideErrorMessageShows Siebel's error message.

ShowServerSideMessageShows message with regular Siebel's server side abilities.

Siebel's part proposed implementationThe following code examples are coming to demonstrate rather than determine.Browser SideFigure 31: Common Messaging Engine browser script - PreInvokeMethod event

Figure 32: Common Messaging Engine browser script - PreCanInvokeMethod event

Figure 33: Common Messaging Engine browser side - ShowBrowserSideMessage

Figure 34: Common Messaging Engine browser side - MessageException5 The Common Error Handling engine can be used here. Please refer to "General error handling mechanism within Siebel boundaries " from Appendixes section of the document

Server SideFigure 35: Common Messaging Engine server side - PreInvokeMethod event

Figure 36: Common Messaging Engine server side - PreCanInvokeMethod event

Figure 37: Common Messaging Engine server side - ShowBrowserSideMessage6 This method allows propagation and evaluation of custom script from browser side to the server side including parameters. For additional information please refer to "Common service design within Siebel boundaries" from Appendixes section of the document

Figure 38: Common Messaging Engine server side - ShowServerSideMessage

Client/Server implementation

Client implementationFigure 39: Common Messaging Engine ClientServer - Client side

Server implementationFigure 310: Common Messaging Engine ClientServer - Server side

Loader implementationFigure 311: Messaging Engine browser side - loader

Usage examplesShowBrowserSideMessageFigure 412: Common Messaging Engine - Client side message invokation

ShowServerSideMessageFigure 513: Common Messaging Engine - Server side message invokation

ConclusionThe engine consists of four parts: server side dynamic linking library, client side daemon/resident process, client side daemon/resident process loader, and server side daemon/resident process terminator.The way of implementation allows effective extensible functionality within the boundaries of engine like: server/client system health check, aggressive marketing using Siebel's plug-ins for smooth connectivity.DiscussionThe following advantages say by themselves:Supports multi porting7 The preferable listener port is not from HTTP protocol native ports.

Supports Citrix environment

Highly flexible and extensible

Highly reliable

Works within another client side process

Implemented using native compilation

Open source

Fully integrated with Siebel

Loosely coupled with GUI context

Appendixes"General error handling mechanism within Siebel boundaries" (Roman Agaev)

"Common service design within Siebel boundaries" (Roman Agaev"

Roman Agaev, M.Sc, PMPOwner, Supra Information Technology ltd.

- -