2Siebel CRM Web Services Overview
Siebel CRM Web Services Overview
This chapter provides an overview of Web services and guidance for implementing Oracle’s Siebel Web services. It contains the following topics:
How Siebel Business Applications Are Deployed as Web Services
Siebel Business Applications are Web service deployed through the following means:
Inbound and Outbound Web services
Integration Objects
The Siebel application
Business Services and Workflows
About Siebel Web Services
A Web service is a discrete piece of business logic, located somewhere on the Internet, which is accessible through Internet protocols. It is distinguished by the following:
It is specified using Web Services Description Language (WSDL).
It contains data represented in Extensible Markup Language (XML) and defined by XML Schema.
It is transported by Simple Object Access Protocol (SOAP), an XML-based transport protocol.
Web Service as a Server-Side Service
A Web service is considered a server-side service if the following are true:
It is the basis for interoperable, heterogeneous applications.
Its interface is defined by XML (XML Schema and WSDL).
Makes available coarse-grained, loosely-coupled operations on document-structured data.
It is independent of underlying implementation.
It is accessible through open standard protocols such as HTTP, SMTP, FTP, or JMS.
Web services are all of the following:
A delivery mechanism for integrating loosely coupled software components.
Delivered over standard Internet technologies.
Rooted in:
Interoperability
Standards
XML
Coarse-grained exposure of functionality
Core Technologies for Web Services
Oracle’s Siebel Web services use industry standard core technologies. The following topics provide an overview of each main core technology:
About Web Services Description Language (WSDL)
WSDL is an XML-based format for describing the interface of a Web service. WSDL describes the endpoints, location, protocol binding, operations, parameters, and data types of all aspects of a Web service:
The WSDL file that describes a Web service has the following characteristics:
It is published by the service provider.
It is used by the client to format requests and interpret responses.
It can be optionally submitted to a registry or service broker to advertise a service.
Additionally, the WSDL file describes the following:
The operations provided by a Web service.
The input and output message structures for each Web service operation.
The mechanism to contact the Web service.
About XML and XML Schema
A WSDL file is published in the form of an XML document instance. Document or Literal is required as part of the WS-I interoperability standard that forms the basis of modern Web service usage, where:
Document means that the payload for an operation, however complex, must be defined in a single XML element.
Literal means that the definition of that element must be described by an XML Schema embedded in the WSDL file.
When using Document/Literal formatting, the WSDL file will contain an XML Schema definition that defines all messages and data types that will be used for a particular service. The payload itself will consist entirely of XML data structures.
About Simple Object Access Protocol (SOAP)
SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML to define an extensible messaging framework.
SOAP messages consist of the following:
An envelope for wrapping messages, including addressing and security information.
A set of serialized rules for encoding data types in XML.
Conventions for a procedure call and or response.
Web Services Deployment Cycle
A service provider describes its service in the form of a WSDL file. Typically, the WSDL file is obtained directly by the developer of the service client consumer.
At the time of the design of a Web service, the service consumer uses the WSDL to generate a proxy in his own native development environment, allowing him to program interactions with the service provider.
At run time the following occurs:
The service consumer formats a request in accordance with the WSDL definition.
The service provider provides the expected response to the service consumer.
Siebel Web Service Documentation
In addition to the documentation provided here, detailed documentation on the use of Siebel objects to create and maintain Web services can be found on the Siebel Bookshelf in Integration Platform Technologies: Siebel Enterprise Application Integration.
Information can be found on Siebel Web service technology and on Siebel Enterprise Application Integration (EAI) technologies like the Siebel Adapter (ASI) and the UI Data Service (UDS), which are designed for direct data-level access to the Siebel Object Manager. Information is also available there on XML Schema development, WSDL generation, Outbound Web service configuration, file attachments, authentication and security.
Support for Siebel Web Services
The following elements contribute to the deployment of Siebel Web services.
Inbound and Outbound Web Services
Siebel Business Applications support both inbound and outbound Web services:
Inbound Web services allow external clients to access Siebel functionality. For example, a custom UI that wants to view and modify Siebel service requests.
Outbound Web services allow Siebel Business Applications to make requests of external applications. For example, if the Siebel Server wanted to provide its clients the option of either searching internally or searching the Internet, then the Siebel Server would invoke an Outbound Web service operation against a third-party search engine, incorporating the results in its own reply to the client.
The following image displays Inbound and Outbound Web services.
Integration Objects
Integration objects provide the primary means of structuring Web service messages. An integration object can be used to support both inbound and outbound Web services, its use with inbound Web services is more tightly bound to the Siebel Object Manager. An integration object represents a subset of a Siebel Business object. The ways in which the elements of the integration object correspond to the elements of the business component are explained as follows:
Integration components represent business components.
Integration component fields represent business component fields.
Typically defines the structure of data being exchanged between a Siebel application and an external application.
Internal Component Field names and WSDL element, and attribute names can be different. In Siebel Tools, In the Integration Component Fields applet, the column XML Tag governs the way the field name will appear in the WSDL.
The following image displays the correspondence between Siebel objects and Integration objects.
Business Services
Business services allow you to deploy a reusable object that contains a predefined set of methods. Additionally, deploying business services allows you to model your Web services within Siebel Tools.
Siebel Web services employ two types of business service:
CRUD (Create, Read, Update, Delete) data services, of the type: UDS and ASI.
Functional Services such as custom business services and workflow.
The following image displays business services and their corresponding Web service entities.
Siebel Web Services Architecture
The following image displays the basic architecture for Siebel Web services.
Process of Making Available a Siebel Web Service
There are two major phases to the development of Siebel Web services. The Siebel objects involved meaning workflows, business services, and integration objects must be configured at design time in Siebel Tools. Then, those objects must be assembled into Web services using Siebel Business Applications. This topic describes the steps you must perform to make a Siebel Web service available.
Determine Which Siebel Objects to Make Available
When exposing a Siebel Web service, you must first use Siebel Tools to determine which Siebel objects, such as business services, workflows or integration objects, you will make available.
Business Services and Workflows
Consider the following when exposing business services and workflows:
Business service methods and arguments correspond to Web service operations and messages. Most business services with methods registered in Siebel Tools can be designated for participation in a Web service.
A workflow is one-to-one equivalent to a single Web service operation, and its process properties are the arguments to that operation. Like most business services, most workflows can be designated for participation in a Web service.
Integration Objects
Consider the following when exposing integration objects:
Integration objects allow mapping of complex business service and workflow data structures to XML Schema as required by Web services.
Integration objects act as boundary proxies for business objects and business components.
General Guidelines for Business Services, Workflows and Integration Objects
Consider the following general guidelines when exposing Siebel objects:
In Siebel Tools, create and open a workspace, make changes to business services, workflows and integration objects to model desired Web service interfaces.
Deliver the workspace and deploy the objects to be made available.
Assemble the Services
In the Siebel application, the Administration - Web Services screens and views allow you to create and configure all Web services at run time.
In the Administration - Web Services screens and views, administrators can select business services and associated methods that they want to make available as Web services.
All Siebel objects must be design-time configured and deployed in to the runtime repository before they can be used in Web service administration screens and views.
For a limited subset of Web services, a Siebel Tools design-time wizard is available to set up most required configuration elements for UDS (UI Data Service) Web service exposure. These elements must also be compiled in the runtime repository before they can be referenced in the Web service administration screens and views.
To assemble your Web services, do the following:
To assemble a Web service in the Web Service Administration view
In the Siebel Mobile Web client, navigate to the Administration – Web Services screen.
Select either Inbound Web Services or Outbound Web Services.
Click New to create a new Web service, or select a Web service in the Inbound or Outbound Web Services list.
In the Service Ports list applet, select a business service or workflow to act as Web service invocation boundary object.
To combine the operations of several business services or workflows into a single service, add them to the port for the Web service.
In the Operations list, model WSDL by configuring methods belonging to the business service, or services and or the workflow or workflows listed in the service port.
Click the Generate WSDL button in the Inbound or Outbound Web Services list.
About Siebel Web Service Modeling
This topic includes the following information:
Exposing a Business Service as a Web Service
The following statements can be applied to business services consumed as Web services:
Business service methods are Web service operations.
Business service method arguments are Web service methods.
You can make business services available through the following means:
Classifying Business Service State Requirements in Siebel Tools
Most Siebel Web service operations are classified as Stateless. In the Siebel Tools Object List editor, under business service, you can determine state requirements.
Stateless means that each Web service operation exists independently of any other.
Stateful means that Siebel Object Manager context must be maintained and correlated from one Web service operation invocation to the next.
If a Web service operation is classified as Stateful, then the application data needs to be retained by the Siebel Server between method calls to determine whether the service could be made logically stateless.
If a business service is either Stateless, or Server Managed, then it must be classified as Server Managed. When a Web service operation is classified as Server Managed, the business service can participate in either a Stateless or a Stateful Web service exchange. When Stateless is chosen, a business service cannot be enlisted at run time for participation in a Stateful exchange.
Registering Public Methods in Siebel Tools
Create and open a workspace in Siebel Tools.
Specify the complete input and output arguments for each of these methods.
If any of the arguments are a property set hierarchy, then do the following:
Define the property set structure as an integration object in Siebel Tools.
Specify the data type for this argument as Hierarchy and associate with integration objects.
To specify whether an argument appears in the input operation and or the output operation, use the Business Service Method Args Type column. Choose Input, Input/Output, or Output to direct the use of the argument in generating the WSDL.
Once the preceding configuration steps in Siebel Tools are complete, and the workspace has been delivered to the runtime repository, continue creating a Web service definition for this business service in Siebel Business Applications.
In the Administration - Web Services screen, Inbound Web Services view, configure the business service in the Service Ports list, create a service operation or operations in the Operations view and designate the business service method to execute.
Create a new Web service or choose an existing Web service in the Inbound Web Services view. Enter the WSDL XML namespace here.
Create a record in the Service Ports view, choose the business service in the Business Service/Business Process name column, set the Transport and URL, and select SOAP_DOC_LITERAL in the Binding column.
Create a service operation in the Operations view, set the WSDL operation name in the Operation Name column, and designate the Business Service method as the Siebel method to execute in the ‘Method Display Name’ column. Operations are mapped in Operations applet.
Deploying a Business Service as a Web Service
You deploy business services as Web services in Siebel Tools. To be deployed, a business service must have at least one accessible method that is supported in Siebel inbound Web services. The business service must include a valid integration object name for any hierarchical argument. The following procedure explains how to deploy a business service as a Web service.
To deploy a business service as a Web service
In the Siebel Tools Object Explorer, select the Business Service object.
The Business Services list appears.
In the Object List Editor, right-click the business service to deploy, and then choose Deploy as Web Service.
Specify the following in the dialog box, and then click Finish:
Business Service methods to make available. The operation names for the business service methods are system generated. To edit an operation name, click it in the list.
URL for Web service. Replace webserver with a valid host name and lang with a valid language code, such as ENU.
Generate WSDL checkbox. To generate a Web Services Description Language (WSDL) file, click the checkbox, and then choose a location to save the WSDL file.
The business service is deployed. Deployed business services are shown in the Administration - Business Services screen in the Siebel client. Deployed Web services are shown in the Administration - Inbound Web Services view.
For more information about deploying business services as Web services, see Integration Platform Technologies: Siebel Enterprise Application Integration on the Siebel bookshelf.
Exposing a Workflow as a Web Service
The following statements can be applied to workflows consumed as Web services.
A workflow corresponds to a single Web service operation.
Workflow process properties are Web service messages. A workflow property set has no direct external representation but can be mapped to an Integration object.
The following procedure explains how to make workflows available as Web services.
To make workflows available as a Web services
Identify process properties that are to be made available and correctly mark them as follows:
In if used as an input argument.
Out if used as an output argument.
In/Out if used as both input and output.
Note: The In, In/Out, and Out arg types are included in the interface definition.If any process property is a property set hierarchy, then complete the following steps:
Define the property set structure as an integration object in Siebel Tools.
Specify data type for this process property as hierarchy and associate with an integration object.
Note: This is important as you must make available a strongly-typed interface, including arguments.In the Administration – Web Services screen, Inbound Web Services view do the following:
Create a new Web service record or choose an existing Web service in the Inbound Web Services list. Enter the WSDL XML namespace here.
Create a record in Service Ports, choose the workflow in the Business Service/Business Process name column, set the Transport and URL properties, and select SOAP_DOC_LITERAL in the Binding column.
Note: To model a complete Web service with more than one operation, several service ports might be specified under a single Web service. This is normal and expected.Create a service operation in Operations, set the WSDL operation name in the Operation Name column, and designate RunProcess as the Siebel method to execute in the Method Display Name column.
Using the Web Services Deployment Wizard
As a convenience, Siebel Tools has wizard-style tools to assist in the configuration of business services, workflows and integration objects into Web services.
If you already have a business service configured and ready for use as a Web service, then right-click on the business service and select Deploy as Web Service... from the menu. You can perform this task for workflows by right-clicking on the desired workflow process record.
If you have modeled an integration object and want to use it for low-level data operations like Create, Read, Update, Delete (CRUD) and the use of the UDS (UI Data Service) service meets your needs, then you can have a wizard build a business service based on the underlying UDS class (CSSEAIUIDataService) and publish the resulting business service as a Web service. From the Siebel Tools file menu, select File, New Object, EAI, and then Data Access Service.
About Siebel Web Service Authentication and Performance
In implementations where scalability is critical, a lightweight context management facility for authentication is available and its use is recommended. With this facility, authentication is managed using a combination of user credentials and a sessionID token:
When user credentials are presented in the SOAP header of a Web service request, formal authentication is performed prior to the application execution of the Web service operation. If the authentication succeeds, then the operation proceeds and a special SessionID token are placed in the SOAP header of the Web service reply.
Whenever the SessionID is included by the client in subsequent Web service requests, that SessionID will be used to restore cached session information, thus bypassing the substantially more expensive process of re-executing the authentication. Note that, when presented with both the SessionID and a valid set of user credentials, an attempt will be made to use the SessionID before resorting to the user credentials and re-authentication. As expected, the session that is being tracked by the SessionID is subject to expiration and other security checks.
The facility is a distinct alternative to the basic authentication standard described by WS-Security. Using the UserName token as provided in WS-Security, while fully supported as part of Siebel’s WS-I Basic Profile compliance, will not yield the same benefit as using the higher-performance session optimization facility provided by the Siebel implementation.
For detailed information on authentication and security see Integration Platform Technologies: Siebel Enterprise Application Integration, and Siebel Security Guide.
Invoking Web Services from the Siebel Mobile Client
The Siebel Mobile Web Client can serve the same Web services as those deployed on the Siebel Server, while protecting access through simple authentication. Invoking Web services from the Siebvel Mobile Client allows developers to integrate external applications with Siebel Business Applications and to test their integrations, without having to install an entire Siebel Enterprise.