siebel web services rad development futures -...

Microsoft Technical Champs Program for Siebel www.siebelonmicrosoft.com

Siebel Web Services RAD Development Futures Table of Contents Siebel Web Services RAD Development Overview......................................................2

Enabling the Smart Client.........................................................................................2 Customer Benefits ................................................................................................2 Smart Client and Whidbey....................................................................................3

Strongly-Typed DataSet Factory ...............................................................................3 The RAD Experience..............................................................................................4 Analyzing the Siebel Web Services WSDL ........................................................ 10 The Data Access API .......................................................................................... 11 Code Generation Editor ..................................................................................... 12 Visual Studio Integration ................................................................................... 16

Siebel Web Services RAD Development Summary.................................................. 21 Conclusion .................................................................................................................. 21 Appendix ..................................................................................................................... 22

A. Supporting API Classes.................................................................................. 22 B. Query Parameter Classes .............................................................................. 24 C. LOV Service Factory Class ............................................................................. 24 D. Siebel Object Factory Class ........................................................................... 25 E. Smart Client Check List ................................................................................. 28

http://www.siebelonmicrosoft.com/

http://www.siebelonmicrosoft.com/

Siebel Web Services RAD Development Futures of 29

Siebel Web Services RAD Development Overview Siebel 7.8 provides a rich and powerful Web Services’ platform for accessing and maintaining integration objects. These services allow one to query, initialize and insert, update, and delete the underlying integration object data. The underlying data is hierarchical in nature and is represented well via XML and .Net Framework strongly-typed hierarchical DataSets.

Using these web services, it is possible to perform a tight integration between Siebel data and ones own enterprise information. The challenge becomes consuming the web services in a RAD environment; wizard generated applications supporting data bound objects, less code for greater functionality, and strongly typed interfaces.

The Siebel 7.8 web services although rich in functionality do not lend themselves to be easily consumed with a RAD environment. The “Siebel Web Services RAD Development Futures” will address the RAD development environment challenge making consuming the Siebel web services a simple programming challenge.

Utilizing a well known programming paradigm, the Siebel web service RAD environment will allow Seibel data to be tightly integrated into enterprise Smart Client applications; strongly-typed DataSets. Not only can one treat Siebel data as a seamless enterprise data source, accessible via a rich programming model, but one gets all the advantages of a smart client application; utilization of local resources, highly connected, offline capable, and intelligent install and update capabilities.

More importantly, with the smart client approach, the Siebel customer will have the benefits of faster adoption of Siebel technologies, richer user experience, increased productivity, and increased interoperability.

Enabling the Smart Client The purpose of a Siebel Smart Client is to support a Siebel eBusiness Application using current and future versions of Microsoft’s .NET Smart Client Framework, Handheld Technologies and Microsoft Office. The Smart Client initiative addresses the architectural framework and client-side technologies that will be required to build a tightly integrated suite of Microsoft and Siebel applications.

This Microsoft smart client framework will allow Siebel and its customers to develop integrated applications that are extremely stable, easy to install, and simple to personalize. These applications will couple Microsoft’s unparalleled expertise in usability with Siebel’s expertise in delivering powerful, scalable applications for the enterprise.

Customer Benefits There are key benefits to Siebel’s customers when having the ability to integrate their eBusiness information, in a strongly-typed manner, into their applications.

• Faster adoption: Microsoft Office has become the desktop productivity standard. By integrating Siebel eBusiness Applications functionality into Microsoft Office and by adopting Microsoft constructs within Siebel applications, Siebel Systems will provide users with a familiar end user


paradigm that can be adopted immediately. Companies will spend less money on end user training, and employee adoption/usage will increase.

• Richer user experience: Siebel eBusiness Applications will become considerably more user friendly as they adopt elements of the Microsoft UI and as end users can access Siebel data from within Microsoft applications. Ultimately, users will have many choices as to where and how they want to interact with Siebel data.

• Increased productivity: Integrating Microsoft and Siebel applications will make enterprise users more efficient and more effective. Users will spend less time trying to access data between the two systems, and many tasks that require the use of both applications can be streamlined. Also, the quality of deliverables will increase through the use of templates and the enforcement of processes that involve both Siebel Systems and Microsoft applications.

• Increased Interoperability: With Siebel adopting SOAP and the Ws-* specifications, integrating Siebel applications into other enterprise applications is easily achieved through the use of Web Services. This includes the ability to use Microsoft Office as a key front-end into the Siebel system. In addition Web Services has enabled a true Service Oriented Architecture where services can be replaced; customer developed by a customer.

Smart Client and Whidbey There are a set of key technologies within the Whidbey timeframe enabling the new smart client approach:

• Application Deployment; Click Once API, Permission Elevation, and Application Policy Deployment: One of the key driving factors in the adoption of a ,Net Framework Smart Client are the improvements being made to allow for a single click, secure, and updatable deployment of the Siebel Application.

• Managed Controls: Managed Html Dom and Web Browser, WinBar controls, Table Control, and Layout Control: With the advent of many new controls and layout engines developers are able to better utilize the WinForms environment and not have to expend development activities on control development.

• Web Service Enhancements: Adoption of Ws-* specifications such as Ws-Security, Ws-Policy, Ws-Addressing, Ws-ReliableMessaging, Ws-Attachments, etc, allow developers to deliver a true Services Orientated Architecture; and a secure disconnected client that is not constrained by firewalls.

• Compact Framework: The .NET Framework on small devices such as mobile phones and digital televisions. The .NET Compact Framework is programming language, hardware, and operating system independent.

Strongly-Typed DataSet Factory Visual Studio is a powerful tool for creating enterprise applications; being a rich development environment with strong data binding capabilities. The data binding, and to a lesser extent smart client, capabilities are most evident when working with strongly-typed DataSet. With the advent of Visual Studio 2005 this capability


has been extending to support data bound web services. However due to the nature of the Siebel web services they do not lend themselves easily to being consumed within a data bound environment.

Binding the Siebel web service to a strongly-typed DataSet creates a rich RAD environment for the development of enterprise applications consuming Siebel web services. This not only allows for a highly productive RAD development environment where little code has to be written, but allows for data change management and offline capabilities.

The RAD Experience There is a defined experience that is to be achieved to create the highly productive RAD environment for accessing Siebel web services. This will assume some domain knowledge in developing data bound applications.

The RAD experience for developing the Siebel eBusiness Applications can be broken down into two categories. Rapidly developing the data bound controls and developing the minimalist code to support the required operations. This experience outlines what one can expect when consuming the Siebel Web Services RAD Development framework for exposing Siebel object and LOV data as strongly-typed DataSets.

Figure 1: Sample Account Listing using AccountDataSet and a data bound DataGridView

Using Siebel Account and Contacts the RAD experience that one can expect from using the strongly-typed DataSet factory classes will be outlined. However; any hierarchical data could be used.

Defining the Project Binding Source The data binding capabilities within Visual Studio should be started initiated with the addition of a binding source and project source.


Figure 2: Select a Web Service Project Data Source within Visual Studio 2005

However when selecting a Web Service and pointing to a Siebel web service one can only bind to the web service returning type. Due to the nature of the Siebel web services and the hierarchical nature of the data this does not present a complete RAD binding solution.

In addition when binding to web services one is responsible for data change management; including the pushing of modified data.


Figure 3: Binding to a Siebel Web Service within Visual Studio 2005

The experience that one should expect is the ability to select a strongly-typed DataSet returning object from which the binding metadata can be derived.


Figure 4: Binding to the factory generated Account DataSet within Visual Studio 2005

At this point a strongly-typed DataSet definition is the source of the data binding and allows the bound controls to derive their structure. This also allows one to define the actual Siebel object, in the form of a DataSet table, on which the data binding will be performed.

Defining the Data Bound Controls Once a binding source has been defined from which the metadata can be derived the Visual Studio wizard will guide one through the process of binding to a DataGrid; including all the column data.

Figure 5: Constructing a DataGridView when bound to the Account DataSet

As one can see, upon dropping a DataGridView on a form and selecting the previously defined data source, the grid is automatically defined with all the Siebel


column data. These columns can then be resized, ordered, removed, etc, to create the desired data layout. In addition the style of the grid can easily be modified to achieve own corporate look and feel.

With the inclusion of a BindingNavigator control, bound to the same data source, one automatically gets the ability to perform table operations and navigations.

Performing the actual data binding will involve execution of the appropriate object method to return the appropriate DataSet; bound to the data source: AccountDataSet dataset =

_accountFactory.GetAccounts(_accountParams, _selectParams); this.bindingSourceAccount.DataSource = dataset; At this point the grid will actually be displaying live Siebel data. More will be said on the input parameters for the method call later in a later section.

Defining Drop-Down List Support Within the DataGrid some columns may require binding to a predefined list of values. These columns should be manually marked as ComboBox entries. For a column within the DataGrid, when defined as a ComboBox, DataSet metadata should be defined that allows one to determine how the possible list of values should be derived. Thus it is possible that a DataGrid defined by an underlying DataSet can derive and populate the required lists: DataGridView[] datagrids = { this.datagridAccount, this.datagridContact }; DataTable[] datatables = {

_accountFactory.CreateAccountDataSet().Account, _accountFactory.CreateAccountContactDataSet().Contact };

ProcessListOfValues(datagrids, datatables); The helper function “ProcessListOfValues” will consume the DataSet metadata defining the LOV type for the column and bind to the DataSet containing the list values.

Coding Parent Data Search When performing a DataSet returning operation, there is the requirement to define the filter and search characteristics. These are defined with the setting of parameters within a structure generated with a specific layout for the Siebel object that is being queried. _accountParams = new AccountQueryParams(); _accountParams.Id = new QueryParameterType(this.textAccountId.Text); _accountParams.Name = new QueryParameterType(this.textAccountName.Text,

GetSiebelSortOrder(this.sortorderName), false); _accountParams.Alias = new QueryParameterType(this.textAccountAlias.Text,

GetSiebelSortOrder(this.sortorderAlias), false); Each property within the query definition will be of a specific type called QueryParameterType. This defines the actual filter value, the optional sort order, and optional exact match indicator.

In this example the sort order is contained within a DomainUpDown control. Helper functions will be available to populate the values contained with these controls along with extracting the required sort order for the web service call.


Figure 6: Sample application for entry of Account Filter and Search criteria

When doing a web service data search there is also the requirement to specify the select parameters. The definition of these, in addition to paging schematics, is contained within a SelectParameters class: _selectParams = new SelectParameters(0, 100, false); The parameters define the first record number, number of records to be returned, and whether a record count is needed. When used in a query the return value will also contain the optional record count, and indicator for last page. These values are used to manage virtual paging.

Coding Parent Data Maintenance Once data has been processed within a DataGrid, or possibly a detail form, changes made to the underlying DataSet need to be pushed back to Siebel. The underlying data Factory will support a single method for processing all the changes to a DataSet. This is in addition to individual method for Insert, Update, and Delete. AccountDataSet dataset =

(AccountDataSet)this.bindingSourceAccount.DataSource; string[] idValues = _accountFactory.MaintainAccounts(dataset); When adding a new entry to the DataGrid it is advantageous to populate any default values. The DataSet factory class will expose a method to return all the default values for an object. _accountDefaults = _accountFactory.InitializeAccounts(dataset); A helper class will allow these values to be placed in a DataGrid row: ProcessDefaultValues(e.Row.Cells, _accountDefaults); This will allow the DataGrid event DefaultValuesNeeded to be easily processed to populate a new line within the DataGrid.


Coding Hierarchical Data Drilldown The treatment of Siebel hierarchical data is identical to that of parent data. Rendering and maintenance of the data is achieved using the corresponding strongly-typed DataSet. For each child element in the hierarchy a corresponding project data source and data bound grid will be defined.

Figure 7: Sample Business Account Listing using AccountBusinessAddressDataSet and a data bound DataGridView

When viewing the child data the “Id” value of the selected parent record is used as input into child drilldown: AccountBusinessAddressDataSet.BusinessAddressDataTable addressTable =

_accountFactory.GetAllAccountBusinessAddresses(_accountId); this.bindingSourceAddress.DataSource = addressTable; When using the “GetAll” operation for a particular parent key all the child records are returned. This allows the data grid to manage all the paging, and possibly sorting, operations locally; using local client resources.

Analyzing the Siebel Web Services WSDL The key in the ability to provide a strongly-typed interface on the web service presented Siebel data is the ability to parse the Siebel WSDL and generate the strongly-typed DataSet definitions and data access factory code.

To construct a Siebel application one will need to consume two types of WSDL:

• List Of Values WSDL that returns data to the list values of fields within the Siebel object hierarchy

• Siebel object WSDL that queries, inserts, updates, and deletes objects within the Siebel hierarchy.

The Analysis of the Siebel WSDL is performed in a Siebel Code Generation Editor. This editor, supporting integration into Visual Studio, allows one to select the Siebel WSDL information from which the code parameters are determined for


code generation. Both these topics, code generation editor and Visual Studio Integration, are outlined in detail.

The Data Access API The key to the application framework components is the code generated data access classes. It is these that are consumed directly by a consuming application, in a RAD manner, to construct the Siebel access application. There are four code components that comprise the solution. Understanding there purpose and API is critical in creating successful application.

Supporting API Classes The supporting classes are utilized by the data access components for query select operations. There are a series of several classes and enumerations. There purpose is to provide support for common operations relating to security, and query definitions. Appendix A outlines a sample API.

Query Parameter Classes The QueryParams class is the internal mechanism that is used to pass the requirements for searching, sort, and filter values. The user control process allows one to define which fields are required for these operations. For each Siebel object a QueryParams class will be defined composed of these selected elements.

The Siebel object web service data access components will consume these classes for passing in the query and filter requirements of the web service call.

LOV Service Factory Class The LOV service component provides the means to define, build, and access the list of values for an object field; providing a drop down list of acceptable values. The factory class works on a shared dataset of all the applications list of values with an operation providing the interface to obtain those values required for a particular field.

Security within the class is handled via several credential defining operations. These allow for the definition of a custom Siebel SOAP header or of authentication headers using the WS-Security specification.

Siebel Object Factory Class The Siebel object service component is the main focus of the code generation. This component will handle all the data access and manipulation for a series of defined Siebel parent and child objects. The API for the Siebel object factory class is an amalgamation of the API required for access to both the Parent and all Child objects; both for enquiry and maintenance.

For children objects’ a GetAll operation can be used to acquire all the child objects for a given key vale as a single dataset. Although useful, should be used with caution as it may involve multiple web services calls to populate.

The Insert, Update, and Delete operations work on the returned dataset to support there corresponding actions; returning the “Id” values of the affected items. The Maintain operation consumes the Insert, Update, and Delete operations, combining the processed “Id” values into a single return array. The Initialize operation is used to acquire a set of default values, and corresponding


element names, for the columns within the child dataset. These values are to be used in presenting default values on a screen during an insert operation.

Security within the class is handled via several credential defining operations. These allow for the definition of a custom Siebel SOAP header or of authentication headers using the WS-Security specification.

Code Generation Editor The Code Generation Editor is the mechanism by which the WSDL’s from Siebel are processed and the factory code is generated. The Editor is enabled to operate as a stand-alone Windows Forms application or as a custom editor for configuration files within Visual Studio 2005.

The Editor is designed to process and generate code for both, or individually, the Siebel LOV web service and the defined integration object service. This will be configured on the main operating page. In addition this main operating section will define the execution parameters around working directories, and the use of WSE (Microsoft Web Service Enhancements).

Two key values from this screen that affect the generated code are the application “Namespace” and “Application Id”. The Namespace defines the actual namespace under which all the code will be generated. The Application Id defines the prefix that will be used, when running as a stand-alone Windows Forms application, for the generated configuration and code files.

Figure 8: Editor initial entry screen defining the working and operating parameters

Processing the LOV Information One of the key advantages in utilizing the code generation processes is that it wraps all the access for the Siebel LOV service. The strongly-typed DataSets have metadata extensions for the Siebel LOV Types. To enable access to this metadata the Editor will generate factory code for access to and storage of the LOV Type information.


To initiate this process one only has to point the Editor to an LOV WSDL and initiate the parsing process. This will analyze the WSDL to derive the appropriate operations names from the Interface definition.

Figure 9: Editor LOV WSDL Entry and Processing Screen; values derived from the WSDL and defined defaults

The LOV Stores are the DataSet definitions that are used for persistence of all the required LOV information and the DataSet for a particular LOV Type that will be used for binding to a drop down list.

Figure 10: Editor LOV Store Data Entry Screen; values derived from the WSDL and defined defaults

The main goal of the code generation process is to wrap the Siebel integration object web service data access in maintainable strongly-typed DataSets. To


enable this, the Editor will generate the factory code for managing these DataSets.

To initiate this process one only has to point the Editor to a Siebel object WSDL and initiate the parsing process. This will analyze the WSDL to derive the appropriate operations names from the Interface definition. Using the Interface definition the appropriate Siebel types within the WSDL will derive and a list of objects for which this WSDL has been created will be created.

Figure 11: Editor Siebel Object WSDL Entry and Processing Screen; values derived from the WSDL and defined defaults. Also allows selection of a child object for configuration.

For each Siebel object, both parent and child within the hierarchy, a series of definitions will be presented to the user. These will be used to define all the operation names within the factory, along with the DataSet definition.


Figure 12: Sample editor displaying entry of Siebel Account data; values derived from the WSDL and defined defaults

From the user perspective the most important step will be the selection of fields which will compromise the DataSet definition. This step is available for the parent and each child object.

The actual selected fields will determine the values that are requested from the Web Service during a query operation and which values one can maintain. This will allow a single Web Service to be used for many possible applications as the optimization for the data that is requested from Siebel is actually configured with the Editor.

Figure 13: Sample editor displaying entry of Siebel Account data; grid data derived from the WSDL and field selection made by the user


It is during the field selection that one also makes the determination on which fields one will perform search or sort operations. Once a field is marked for Search/Sort it will be included in the Query Parameters structure that is used in query operations.

Finally this screen allows for the entry of an LOV Type against a field. This Type determines the possible List-Of-Values (LOV) for a field. This information is persisted in the DataSet metadata.

Visual Studio Integration One of the key points of the Code Generation process is the ability to be integrated into Visual Studio. This integration point allows the addition into a project of a configuration file, extension “seblcfg”, from which the code will be generated. This configuration file is an XML representation of the data entered into the Editor application; which can be edited via the Editor.

Figure 14: Sample Siebel Account project with integration of the code generation configuration file

Once a configuration file is added to the project it will have a custom tool property defined as “SiebelCodeGenerator”. The Editor and supporting code generation library will be registered with Visual Studio as a customer code generator; thus allowing this relationship.


Figure 15: Sample property for the Siebel configuration file defining the custom tool property

In Visual Studio, the context menu for the configuration file will allow one the option to “Run Custom Tool”. In doing so the code generation library will create a corresponding C# file consisting of all the factory code.

To edit the configuration file one will have to select the context menu item “Open With” and select the code generation editor.

Figure 16: “Open With” dialog for the Siebel code generation configuration file

The Editor in Visual Studio will operate in an identical fashion as to when running as a stand-alone Windows Forms application. Once running one will define the parameters for code generation as previously defined.


Figure 17: Initial Editor screen when instantiated from within Visual Studio showing application directories

When operating within Visual Studio the Editor will define the series of directories based on the project directory in which the configuration file resides.

The “Templates” directory is critical for code generation as it contains the code templates from which the code generation will take place. To ensure that these are correctly located a Visual Studio Project Template will be available that will create this directory and the required code templates.

Figure 18: Creating a new project supporting the Siebel code generation process


In addition to creating the Template files the Project Item will create a default configuration file; enabled for managing LOV and Siebel object data. This configuration file will be configured to be opened with the Editor application and enabled for code generation via the custom code generation tool.

Figure 19: Sample new project created to support the Siebel code generation process

In addition to Project Items there will also be the ability to add additional configuration files; with associated generated code.

Figure 20: Creating a new project item to support the addition of a new Siebel code generation configuration file


When adding new code generation configuration file there will be three options. One supporting just a Siebel object, another for just an LOV services, and lastly one supporting both; this being the default for the Project Item.

An important note to make in constructing a Siebel web service application is that an LOV configuration file must always exist. This is necessary because an application will always rely upon an LOV service and the emitted code will also contain utility operations supporting the Siebel object factory classes.


Siebel Web Services RAD Development Summary Strongly-typed DataSet access, supporting querying and data maintenance, to

Siebel integration objects over Web Services.

Full support for hierarchical data for both querying and maintenance.

Full support for Virtual paging and strongly-typed interface for the specification of search and sort parameters.

Full support for the LOV (List-Of-Values) service; including data binding to a strongly-typed DataSet.

Full support for URL parameter based, WS-Security, and Siebel custom SOAP headers’ authentication.

RAD support for the creation of applications; reduction of code to be written and usage of wizards over strongly-typed interfaces.

Availability of helper functions to assist in the creation of Windows Forms based smart client applications.

Simple Windows Forms Editor for the configuration of the code to be generated using only the Siebel WSDL files as input. This includes the fields required for the application.

Web Service optimization only requesting the required fields; based on those selected in the Editor.

Integration of the code generation process into Visual Studio 2005. This includes supporting the inclusion of a configuration file into Visual Studio from which the Editor can be initialized and execution of the code generation from this configuration file.

Visual Studio 2005 Project and Item Templates for the creation of a Siebel Web Service project and inclusion of configuration elements.

Conclusion Siebel 7.8 provides a rich Web Services framework for access into integration objects. However these web services are not ideally suited into the smart client RAD development environment. The RAD development code generation framework provides a rich and powerful mechanism in which a factory class can be defined and generated to provide a strongly-typed interface over these web services; in the form of DataSets. The code generation framework has full support for a List-Of-Values service.

To enhance the usability of the code generation framework there will be full support for integration into Visual Studio and the construction of smart client applications.


Appendix

A. Supporting API Classes The following API outlines those classes that are used to support both the LOV and Siebel object web service operations. /// <summary> /// Delegate for providing processing of the soap context /// Allows security processing using WSE prior to and after the SOAP call /// </summary> public delegate void SoapProcessingDelegate(SoapContext context); /// <summary> /// Definition of the constants required for Siebel SOAP Header processing /// </summary> public class SiebelSecurityFilter { internal const string Namespace = "http://siebel.com/webservices"; internal const string UsernameToken = "UsernameToken"; internal const string PasswordText = "PasswordText"; internal const string SessionType = "SessionType"; internal const string SessionToken = "SessionToken"; } //SiebelSecurityFilter /// <summary> /// Enumeration for the Siebel Authentication types /// </summary> public enum SiebelSecuritySessionType { Default, SiebelNone, SiebelStateless, wsseSecurity } //SiebelSecuritySessionType /// <summary> /// Siebel Security Output processing filter /// Designed to process the Username Password and Session tokens /// </summary> public class SiebelSecurityOutputFilter : SoapOutputFilter { /// <summary> /// Single method to process the soap envelope /// processing the Username Password and Session tokens /// </summary> public override void ProcessMessage(SoapEnvelope envelope); } //SiebelSecurityOutputFilter /// <summary> /// Siebel Security Input processing filter /// Designed to construct the Username Password and Session tokens /// </summary> public class SiebelSecurityInputFilter : SoapInputFilter { /// <summary> /// Single method to process the soap envelope /// processing the Incoming Session tokens /// </summary> public override void ProcessMessage(SoapEnvelope envelope); } //SiebelSecurityInputFilter


/// <summary> /// For each Select operation defines the characteristics around /// page number and record counts /// TotalRowsCount and LastPage are determined after the call /// </summary> public class SelectParameters { // public properties that require definition public int StartRowIndex = 0; public int MaximumRows = 25; public bool RetrieveTotalRowCount = false; // public properties returned public int TotalRowsCount; public bool LastPage; } /// <summary> /// Enumeration to define the sort characteristics of the query values /// </summary> public enum QuerySortOrder { Default, Asc, Desc } /// <summary> /// For each of the Query Parameters classes defines the required values /// Null value indicates no value is expected and should not be used /// </summary> [Serializable] public class QueryParameterType { // public properties public string Value = null; public QuerySortOrder SortOrder = QuerySortOrder.Default; public bool ExactMatch = false; /// <summary> /// Returns the string that represents the query Filter Value /// </summary> public string GetFilterValue(); /// <summary> /// Returns the correct Ascending or Descending value /// </summary> public string GetSortOrder(); /// <summary> /// Determines if the Query Paramater has a value /// </summary> public bool HasValue(); } The SelectParameters class is used when performing any select operation for defining the query characteristics. The QuerySortOrder and QueryParameterType are used when performing a Siebel query operation. These classes are used in conjunction with the query parameter classes, defined below, in specifying the search, sort, and filter characteristics of the select operation.


The Siebel Security classes are designed to support the various security protocols. The framework supports both the usage of WS-Security, through WSE, and the usage of the Siebel custom SOAP headers.

B. Query Parameter Classes The basic structure for a Siebel query parameter class object is as follows: [Serializable] public class ObjectnameQueryParams { // private fields declarations private QueryParameterType _id; private QueryParameterType _field1; private QueryParameterType _field2; // other private field definitions // property definitons are used to enable data binding public QueryParameterType Id { get { return _id; } set { _id = value; } } public QueryParameterType Field1 { get { return _field1; } set { _field1 = value; } } public QueryParameterType Field2 { get { return _field2; } set { _field2 = value; } } } For each integration object for which data access is required a class of this structure will be defined.

C. LOV Service Factory Class The LOV service component provides the means to define, build, and access the list of values for an object field; providing a drop down list of acceptable values. The factory class works on a shared static dataset, to which access is controlled via a ReaderWriterLock. public class ListOfValues { /// <summary> /// Static method to define the types of LOV's to be persisted /// </summary> public static void SetLovTypes(string[] lovTypes); /// <summary> /// Static methods to extend the types of LOV's to be persisted /// </summary> public static void AppendLovTypes(string[] lovTypes); /// <summary> /// Static methods to extend the types of LOV's to be persisted /// The Table and Column names will be used /// </summary> public static void AppendLovTypes(DataTable table); /// <summary> /// Property that represents the XML of the static XML store


/// To be used to persist the store offline and later refresh /// </summary> public static string LovXml; /// <summary> /// Method used to repopulate the LOV store from defined set of values /// </summary> public static void PopulateStore(); /// <summary> /// Instance method to create the DataTable of appropriate list values /// Columns are Value, DisplayValue, Description (in sort order) /// </summary> public LovFieldDataTable GetListOfValues(string lovType); /// <summary> /// Allows for definiton of the credentials for Siebel Authentication /// </summary> public static void SetCredentials(

SiebelSecuritySessionType sessionType, string username, string password);

/// <summary> /// Allows for definiton of SOAP Siebel Authentication delegates /// </summary> public static void SetSoapProcessing(

SoapProcessingDelegate soapRequest, SoapProcessingDelegate soapResponse);

} To populate the store one has to call the Append operations with the required LOV types; after which calling PopulateStore will initialize the stores static dataset. To get a list of values for a particular field the GetListOfValues operation is used; passing in the required LOV type. The return dataset is created as a filter view of the static store; from which the returning dataset is constructed.

Security within the class is handled via the SetCredentials and SetSoapProcessing operations. These allow for the definition of a custom Siebel SOAP header and processing of the WS-Security options.

D. Siebel Object Factory Class The API for the Siebel object factory class is an amalgamation of the API required for access to both the Parent and child objects; both for enquiry and maintenance. In the example below, the API for the Parent object, the declarative PARENT would be replaced with the correct parent object name. public class FactoryDataSetParent { // string array representing the LOV types required public static readonly string[] PARENTDataLovTypes; public static readonly string[] PARENTDataLovColumns; /// <summary> /// Used to create the Dataset /// extended with metadata for the Lov Types /// </summary> public PARENTDataSet CreatePARENTDataSet(); /// <summary> /// Used to create a new Parent DataRow /// used when managing insertions outside of a datagrid /// </summary> public PARENTDataSet.PARENTRow CreatePARENTRow(PARENTDataSet dataset);


/// <summary> /// Get the Parent dataset for the given query and select parameters /// </summary> public PARENTDataSet GetPARENTS(PARENTQueryParams queryParent,

SelectParameters selectParams); /// <summary> /// Get the Parent dataset for the given query and select parameters /// Will merge the data with the passed in dataset /// </summary> public void GetPARENTS(PARENTQueryParams queryParent,

SelectParameters selectParams, PARENTDataSet dataset);

/// <summary> /// Gets the set of default values for a PARENT insertion /// </summary> public Hashtable InitializePARENTs(PARENTDataSet dataset); /// <summary> /// Inserts new PARENT data based on values in the given dataset /// </summary> public string[] InsertPARENTs(PARENTDataSet dataset); /// <summary> /// Updates current PARENT data based on values in the given dataset /// </summary> public string[] UpdatePARENTs(PARENTDataSet dataset); /// <summary> /// Deletes current PARENT data based on values in the given dataset /// </summary> public string[] DeletePARENTs(PARENTDataSet dataset); /// <summary> /// Deletes current PARENT data based on values in the given dataset /// Calls the Insert Update and Delete operations /// </summary> public string[] MaintainPARENTs(PARENTDataSet dataset); } The LOV types is an aid used to populate the LOV store; by providing the appropriate type names. The Get operation accepting a dataset is designed to support the construction of a dataset consisting of more than a single page of data.

The final API is a composite of the API for the Parent object and a series of operations for each child object. In the example below the declarative PARENT would be replaced with the correct parent object name and CHILD with the child object name. // string array representing the LOV types required public static readonly string[] PARENTCHILDDataLovTypes; public static readonly string[] PARENTCHILDDataLovColumns; /// <summary> /// Used to create the Dataset /// extended with metadata for the Lov Types /// </summary> public PARENTCHILDDataSet CreatePARENTCHILDDataSet(); /// <summary> /// Used to create a new Child DataRow /// used when managing insertions outside of a datagrid /// </summary>


public PARENTCHILDDataSet.CHILDRow CreatePARENTCHILDRow( PARENTCHILDDataSet dataset, string key);

/// <summary> /// Gets all the CHILD elements as a data table for the given parent key /// </summary> public PARENTCHILDDataSet.CHILDDataTable GetAllPARENTCHILDs(string id); /// <summary> /// Get the CHILD dataset for the given query and select parameters /// </summary> public PARENTCHILDDataSet GetPARENTCHILDs(PARENTQueryParams queryParent, SelectParameters selectParams); /// <summary> /// Get the CHILD dataset for the given query and select parameters /// </summary> public PARENTCHILDDataSet GetPARENTCHILDs(PARENTQueryParams queryParent, CHILDQueryParams queryChild, SelectParameters selectParams); /// <summary> /// Get the CHILD dataset for the given query and select parameters /// Will merge the data with the passed in dataset /// </summary> public void GetPARENTCHILDs(PARENTQueryParams queryParent, SelectParameters selectParams, PARENTCHILDDataSet dataset); /// <summary> /// Get the CHILD dataset for the given query and select parameters /// Will merge the data with the passed in dataset /// </summary> public void GetPARENTCHILDs(PARENTQueryParams queryParent, CHILDQueryParams queryChild, SelectParameters selectParams, PARENTCHILDDataSet dataset); /// <summary> /// Gets the set of default values for a CHILD insertion /// </summary> public Hashtable InitializePARENTCHILDs(PARENTCHILDDataSet dataset, string key); /// <summary> /// Inserts new CHILD data based on values in the given dataset /// </summary> public string[] InsertPARENTCHILDs(PARENTCHILDDataSet dataset); /// <summary> /// Updates current CHILD data based on values in the given dataset /// </summary> public string[] UpdatePARENTCHILDs(PARENTCHILDDataSet dataset); /// <summary> /// Deletes current CHILD data based on values in the given dataset /// </summary> public string[] DeletePARENTCHILDs(PARENTCHILDDataSet dataset); /// <summary> /// Deletes current CHILD data based on values in the given dataset /// Calls the Insert Update and Delete operations /// </summary> public string[] MaintainPARENTCHILDs(PARENTCHILDDataSet dataset); Again; the LOV types is an aid used to populate the LOV store and the Get operation accepting a dataset is designed to support the construction of a dataset


consisting of more than a single page of data. The GetAll operation can be used to acquire all the child objects for a given key value as a single dataset. Although useful, should be used with caution as it may involve multiple web services calls to populate.

The Insert, Update, and Delete operations work on the returned dataset to support their corresponding actions; returning the “Id” values of the affected items. The Maintain operation consumes the Insert, Update, and Delete operations, combining the processed “Id” values into a single return array. The Initialize operation is used to acquire a set of default values, and corresponding element names, for the columns within the child dataset. These values are to be used in presenting default values on a screen during an insert operation.

In addition to the data processing operations there are a series of operations in support of the security requirements. Security is handled via the SetCredentials and SetSoapProcessing operations. These allow for the definition of a custom Siebel SOAP header and processing of the WS-Security options. /// <summary> /// Allows for the definiton of the user credentials for Authentication /// </summary> public void SetCredentials(SiebelSecuritySessionType sessionType,

string username, string password); /// <summary> /// Allows for the definiton of SOAP processing delegates for Authentication /// </summary> public void SetSoapProcessing(

SoapProcessingDelegate soapRequest, SoapProcessingDelegate soapResponse);

A final word is warranted on the use of the dataset metadata; extended properties. As part of the data entry for field properties one is allowed to key in a “LOV Type”. This property represents the value of the type for locating lists values from the LOV store. This information, available form the static string arrays, is also persisted as an Extended Property of the dataset columns; property name “LovType”. If one needs to know the LOV Type for a column one just has to read this property string.

E. Smart Client Check List Because of the high degree of flexibility and somewhat ambiguous nature of smart client applications, it is often useful to talk about the key characteristics of a smart client. These characteristics serve as a guide to the features typically provided by smart clients over and above those provided by traditional rich client applications. If a client application displays these characteristics, then it can be said to be smart:

• Utilizes Local Resources A smart client application always has code artefacts on the client that enable local resources to be utilized. What do we mean by local resources? We mean everything from hardware to software resources. A smart client may take advantage of the local CPU or GPU, local memory or disk, or any local devices connected to the client, such as a telephone, bar-code/RFID reader, and so on. But it may also take advantage of local software, such as Microsoft Office applications, or any installed line-of-business (LOB) applications that interact with it.


• Rich Client Experience Tightly coupled with utilizing local resources a smart client provides a rich user experience. The .Net Framework Windows Forms library provides a rich and diverse set of capabilities for creating a rich interacting application. These capabilities far exceed those of a browser based application to provide a truly rich and interactive experience for the user.

• Highly Connected Smart client applications are never stand-alone and always form part of a larger distributed solution. This could mean that the application interacts with a number of Web services that provide access to data or an LOB application. Very often, the application has access to specific services that help maintain the application and provide deployment and update services.

• Offline Capable Because they are running on the local machine, one of the key benefits that smart client applications offer is that they can be made to work even when the user is not connected. For applications running in occasional or intermittent connectivity situations, such as those used by travelling workers or even those running on laptops, tablets, PDA's, and so on, where connectivity cannot be guaranteed at all times, being able to work while disconnected is essential. Even when the client is connected, the smart client application can improve performance and usability by caching data and managing the connection in an intelligent way.

• Intelligent Install and Update Smart client applications manage their deployment and update in a much more intelligent way than traditional rich client applications. The .NET framework enables application artefacts to be deployed using a variety of techniques, including simple file copy or download over HTTP. Applications can be updated while running and can be deployed on demand by clicking on a URL.

• Client Device Flexibility The .NET Framework together with the .NET Compact Framework provides a common platform upon which smart client applications can be built. Often, there will be multiple versions of the smart client application, each targeting a specific device type and taking advantage of the devices unique features and providing functionality appropriate to its usage.

More information on the Microsoft Smart Client can be found at: http://msdn.microsoft.com/smartclient/

http://msdn.microsoft.com/smartclient/

siebel web services rad development futures -...

Documents