Web Services

Siebel Enterprise Application Integration Monday, April 04, 2011
Siebel Enterprise Application Integration

This document serves as a quick reference to various concepts of Siebel Integration. The objective of
this document is to cover the inbound web services, outbound web services, virtual business
components and integration objects. Besides a detailed technical explanation, the document also
provides a simple practical example for each described area.
Author: Saiganesh Padmanabhan

Version: Initial Draft
1|Page
Contents
INBOUND WEB SERVICES .............................................................................................................................. 4

1. Definition of Inbound Web Service ............................................................................................... 4
2. Business Scenario .......................................................................................................................... 4
3. Objects that can be deployed as Inbound Web Services .............................................................. 4
4. Types of Inbound Web Services .................................................................................................... 4
5. Flow of Inbound Web Services...................................................................................................... 5
6. User name token security measure .............................................................................................. 6
7. Incorporation of Soap Headers ..................................................................................................... 6
8. Anonymous Web Services............................................................................................................. 7
9. Authentication Types for Web Services ........................................................................................ 8
10. Enabling session management for web services .......................................................................... 8
11. Implementing session management ............................................................................................. 8
12. Inbound Web Service Example ................................................................................................... 10
12.1 Solution Outline .................................................................................................................... 11
12.2 Creation of Request Integration Object ................................................................................ 11
12.3 Creation of Response Integration Object .............................................................................. 12
12.4 Creation of Workflow Process Properties ............................................................................. 14
12.5 Workflow Skeleton ................................................................................................................ 14
12.6 Workflow Step Details........................................................................................................... 14
12.7 Creation of data map ............................................................................................................ 18
12.8 Creation of Business Service ................................................................................................. 19
12.9 Deploying a workflow as a web service ................................................................................ 20
12.10 Generating WSDL .................................................................................................................. 20
12.11 Consuming the web service .................................................................................................. 21
12.12 Testing the web service ......................................................................................................... 21
12.13 Using Local Web Service ....................................................................................................... 21
OUTBOUND WEB SERVICES ........................................................................................................................ 22
1. Definition of Outbound Web Service .......................................................................................... 22
2. Business Scenario ........................................................................................................................ 22
2|Page
3. Consumed Information through a web service .......................................................................... 22

4. Flow of Outbound Web Service .................................................................................................. 23
5. Request Filter Service.................................................................................................................. 24
6. Response Filter Service ............................................................................................................... 24
7. Local Business Service ................................................................................................................. 25
8. Outbound Web Service Workflow Example ............................................................................... 25
9. Outbound Web Service Workflow File........................................................................................ 27
3|Page
INBOUND WEB SERVICES
1. Definition of Inbound Web Service
Inbound web services in Siebel are used to provide business services to external systems. Siebel CRM
system exposes these inbound web services to external systems so that they can consume the business
services residing within the Siebel CRM application.
2. Business Scenario
Quite often, external systems consume services of a centralized system to store all the data in a
centralized database. In this context, the centralized database is that of Siebel CRM system. In a
telecom sector, the trouble management system generally addresses the most critical issues of the
customers. While the problem is addressed by the trouble management system, the critical issue is
logged and tracked in the Siebel CRM system as a trouble ticket.
In this specific business scenario, an inbound web service of Siebel CRM System would be quite useful to
the trouble management system. Siebel CRM System provides a web service to create a trouble ticket in
Siebel Database. This web service can be consumed by trouble management system to create trouble
tickets within Siebel CRM application. In general, the same web service can be consumed by any
external system.
3. Objects that can be deployed as Inbound Web Services
In Siebel tools, business logic is generally found in two particular objects – business service and a
workflow. The rest of the objects may or may not be used as references in these two objects. A web
service also holds business logic, which can be consumed by other systems. So, the only two objects
that can be deployed as an inbound web service are
 Workflow
 Business Service
If the requirements to implement the business logic are straight-forward, building the logic in a
workflow and deploying the workflow as a web service is always the best option. To implement
complex business logic, a business service is a good option and it can be deployed as a web service.
4. Types of Inbound Web Services
4|Page
There are two types of inbound web services –
1) Inbound with no response

2) Inbound with response
Inbound with no response is a type, which is used to accept the request from the external system,
perform the process and forget the response. No response is sent to the external system. For instance,
in case of the above business scenario, the trouble management system sends a Soap Request to Siebel
to create the trouble ticket. Nevertheless, it did not expect the trouble ticket number or any other data
as a response.
Inbound with response is a type, which is used to accept the request from the external system, perform
the process and send the response to the external system. For instance, if we consider the same
business scenario, the trouble management system sends a Soap Request to Siebel to create the trouble
ticket. In turn, it did expect a Soap Response from Siebel to get the trouble ticket number.
5. Flow of Inbound Web Services
The address or the end-point URL of a web service is the main trigger point for an inbound web service.
This end-point URL is used by the external system to send a Soap Request to Siebel CRM system. The
below points explain the flow of a Soap Request from an external system to Siebel CRM System.
 External system executes the end-point URL to send a Soap Request. The end-point URL
generally looks like below:
o http://172.18.113.6/eai_enu?start.swe&SWEExtSource=WebService&SWEExtCmd=Exec
ute&UserName=eaiuser&Password=eaiuser
o The above end-point URL gets generated, when the web service is deployed.
172.18.113.6 is the Siebel web server address. Eai_enu is the name of the virtual
directory. WebService is the name of the external data source or named sub-system.
UserName and Password are used to log onto Siebel session.
 When the request reaches Siebel web server, SWSE searches to see if the virtual directory
named eai_enu exists or not. If it exists, it further searches to see if eai_enu is defined in
eapps.cfg or not. If it is not present in eapps.cfg, it further searches to see if it exists in the CFG
files included in the INCLUDE section of eapps.cfg. If any one of the above conditions fails, the
request from the external system is rejected.
 If the virtual directory eai_enu is defined in eapps.cfg, then an EAI Siebel session is created with
the help of the connect string specified under the eai_enu virtual directory.
5|Page
 When the Siebel session is created, it executes the named sub-system called WebService. In
this named sub-system, a dispatch service called Web Service Inbound Dispatcher accepts the
Soap Request of the external system.
 Web Service Inbound Dispatcher extracts the Soap Body from the Soap Request, converts the
Soap Body into a Siebel Message and inputs it to the workflow or the business service that is
deployed as a web service.
 The workflow or business service starts executing the business with Siebel Message as the input.
It completes the process and outputs the Siebel Message back to Web Service Inbound
Dispatcher.
 Web Service Inbound Dispatcher accepts the output Siebel message, formulates the Soap
Response and sends it back to the Siebel Web Server. Siebel Web Server, in turn, sends the
Soap Response to the external system over HTTP protocol.
6. User name token security measure
User name token mechanism is one of the security measures available with inbound web services from
the Siebel version 7.7. With this security measure, it is possible to get rid of the user credentials as part
of the end-point URL and send them as part of the Soap Header instead.
7. Incorporation of Soap Headers
While generating WSDL through Siebel client, Soap Header does not get included in the WSDL. Soap
Headers are supposed to be manually incorporated in the Soap Message. If the Soap Message is of type
Request, then it is the responsibility of the external system to incorporate the Soap Header in the Soap
Message before it reaches Siebel CRM system. If the Soap Message is of type Response, then it is the
responsibility of the Siebel CRM system to incorporate the Soap Header in the Soap Message before the
Soap Message Response reaches the external system.
If Siebel CRM system is sending a Soap Response to external system and if external system demands to
have certain Soap Header parameters, then the Soap Header can be created and incorporated in the
Soap Response through a business service. The business service creates the Soap Header with required
parameters using the property set functions. Once the Soap Header is created, it is incorporated at the
required position in the Soap Response using the same property set functions. This business service
needs to be picked from the Response Filter Service of the Web Service in the Web Services
Administration Screen.
6|Page
Web Services Administration -> Inbound Web Services -> Operations Applet’s property
If Siebel CRM system is receiving a Soap Request from external system, then it’s the responsibility of the
external system to incorporate the Soap Header in the Soap Request. If the requirement is to read and
store the Soap Header parameters or Soap Body parameters before starting off the actual process, then
a business service needs to be created in Siebel Tools. This business service needs to be picked from the
Request Filter Service of the Web Service in the Web Services Administration Screen.
Web Services Administration -> Inbound Web Services -> Operations Applet’s property
8. Anonymous Web Services
Anonymous web service is one kind of web service, which is rarely used. This web service becomes an
inevitable option if the requirement demands to have user name token security mechanism. The user
name token mechanism requires the user credentials to be passed as part of the Soap Header of the
Soap Message instead of passing them through the end-point URL.
Anonymous web services and user name token mechanism are complementary. If user name token
mechanism is required, anonymous web services are required. The following steps are supposed to be
followed to implement anonymous web services.
 The end-point URL gets the majority of the changes to implement anonymous web service. And
the end-point URL should look like this.
o http://172.18.113.6/eai_anon_enu?start.swe&SWEExtSource=SecureWebService&SWE
ExtCmd=Execute
o The virtual directory gets changed from eai_enu to eai_anon_enu. The named sub-
system changes from WebService to SecureWebService. The user credentials have to be
removed from the end-point URL. Instead, they should be sent as part of the Soap
Header.
o Note: External system should hold the responsibility of passing user credentials as part
of the Soap Header in the Soap Request Message. The Soap Header snippet, in this
particular context, should look like below.
 The virtual directory eai_anon_enu has to be defined in the eapps.cfg or in one of its included
CFG files. Under this virtual directory entry, UseAnonPool should be set to TRUE and
Anonymous Pool should have a value. By default, the anonymous pool is set to 10.
 The Authentication Type of the web service operation should be ‘Username/Password – clear
text’ instead of ‘None’. It can be changed at the following path:
7|Page
o Web Services Administration -> Inbound Web Services -> Operations Applet property
 In the named sub-system SecureWebService, the profile configuration parameter Impersonate

should be set to TRUE. It can be changed at the following path:
o Server Configuration Administration -> Enterprises -> Profile Configuration
9. Authentication Types for Web Services
Authentication Type is mandatory to be chosen for each and every web service. It can be selected at the
Operations applet of the web service in the Web Services Administration Screen. There are two kinds of
authentication types for inbound and outbound web services.
 None
 Username/Password – Clear text
None is the authentication type that should be chosen if the user credentials are present as part of the
end-point URL in the web service. When the Authentication Type is selected as None, SWSE treats it as
a normal web service request and does not read the user credentials from the Soap Header, even if they
are present. Instead, the user credentials in the Soap Header are just ignored.
Username/Password – Clear text is the authentication type that should be chosen if the user
credentials are sent as part of the Soap Header. In general, this is the authentication type that should
be chosen if the user name token security measure is implemented. When the Authentication Type is
selected as Username/Password – Clear text, SWSE treats it as an anonymous web service request and
reads the user credentials from the Soap Header to initiate a new EAI session.
10. Enabling session management for web services
When there is no session management enabled, a new EAI session is created, the automatic logon
request onto the EAI session is issued with the help of the user credentials, the operation of the web
services gets executed in the EAI session and an automatic logoff request is issued to terminate the
session immediately.
Enabling session management will give flexible options of either terminating the session or retaining the
session for subsequent requests. To enable session management in Siebel, the end-point URL in the
web service should contain the parameter WSSOAP and it should be set to 1. To be precise, the end-
point URL should look like below.
http://172.18.113.6/eai_enu?start.swe&SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1
11. Implementing session management
8|Page
The session management will be enabled if the end-point URL consists of the parameter WSSOAP set to
1. The session management implementation requires the incorporation of Soap Header in the Soap
Message. The Soap Header should contain the following parameters as mandatorily.
 SessionType
 UsernameToken
 PasswordText
 SessionToken (needed only for stateless session type)
SessionType is one of the Soap Header parameters, which has the following values.
 None
 Stateless
 Stateful
None: If the SessionType is None, a new session is created, the request is processed, the response is
sent out and the session is terminated.
Stateless: If the SessionType is Stateless, a new session is created, the request is processed, the
response is sent out and the session stays alive to accept sub-sequent requests. If the session is closed
explicitly, relogin occurs automatically with the help of the Session Token. For the initial login, this
SessionType requires UsernameToken and PasswordText included as part of the Soap Header.
Note: If the web service requests are massive in number or if the requests occur most frequently for the
web services, then Stateless is the best session mode interface to be considered for the implementation
of the session management for the web services.
Stateful: If the SessionType is Stateful, a new session is created, the request is processed, the response
is sent out and the session stays alive to accept sub-sequent requests. If the session is closed, relogin
does not occur automatically. For the initial login, this SessionType requires UsernameToken and
PasswordText included as part of the Soap Header.
While SessionType is one of the Soap Header parameters, the other Soap Header parameters used in
the session management are listed below.
 UsernameToken
 PasswordText
 SessionToken
UsernameToken is a Soap Header parameter, which is used to log onto an EAI session. This Soap
Header parameter is mandatory for session types – Stateless and Stateful – only for initial request.
9|Page
PasswordText is another Soap Header parameter, which holds the password to log onto an EAI session.
UsernameToken and PasswordText are used together to log onto an EAI session. This Soap Header
parameter is also mandatory for session types – Stateless and Stateful – only for initial request.
SessionToken is used only for Stateless session type. Relogin to the session automatically happens in
Stateless session type, just because of this SessionToken Soap Header parameter. When a stateless web
service request reaches Siebel from an external system, the Siebel server generates a session token,
assigns its value to the SessionToken Soap Header parameter and makes sure that it travels as part of
the Soap Response to the external system. The Session token is an encrypted string that contains the
session ID and the user credentials.
The external system should make sure to send this SessionToken Soap Header parameter back to Siebel,
in case of firing sub-sequent requests. When the external system fires stateless requests to the same
web service again, Siebel Server reads the SessionToken Soap Header parameter, decrypts the session
token and uses the user credentials to automatically relogin to the EAI session. In this way, the Stateless
session type automatically relogins to a session, even if it is closed.
The following is an example of a Soap Header in the Soap Request that’s being fired from external
system to Siebel CRM System.
 <soap: Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>

 <soap:Header>
o <SessionType xmlns=http://siebel.com/CustomUI/>Stateless</SessionType>
o <UsernameToken xmlns=http://siebel.com/CustomUI/>EAIUSER</UsernameToken>
o <PasswordText xmlns=http://siebel.com/CustomUI/>EAIUSER</PasswordText>
 </soap:Header>
 <soap:Body />
 </soap:Envelope>
The following is an example of a Soap Header in the Soap Response that’s being fired from Siebel CRM
System to external system.
 <soap: Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>

 <soap:Header>
o <SessionToken xmlns=http://siebel.com/CustomUI/>ASFasdfaseikdkLESELESS</SessionToken>
 </soap:Header>
 <soap:Body />
 </soap:Envelope>
The above example clearly shows that the external system initially sends a stateless request with the
required Soap Header parameters. Siebel responds to that request by including an encrypted session
token back to the external system. When the external system wants to fire sub-sequent requests to the
same web service, it should just send the SessionToken Soap Header parameter to Siebel. With the help
of SessionToken parameter, Siebel automatically relogins to the EAI session.
12. Inbound Web Service Example
10 | P a g e
Consider a scenario of creating a service request in Siebel from an external system. This scenario
requires the implementation of an inbound web service in Siebel. Once implemented, it will be
provided to the external system for consuming services from Siebel.
12.1 Solution Outline
The steps for implementing an inbound web service are shown below.
1) Create request and response integration objects.

2) Create a workflow to incorporate the SR creation logic.
3) Deploy the workflow as an inbound web service.
4) Define the end-point URL as appropriate.
5) Generate the WSDL.
6) Give it to the external system.
12.2 Creation of Request Integration Object
Integration Objects could be created through Siebel Tools. The wizard easily guides the creation of the
integration object. To create the request integration object, do the following.
In Siebel Tools, open File -> New Object -> EAI tab in the wizard -> Select Integration Object.
The wizard systematically guides you to select the source object, to give a name to the integration
object, and to select the components from the tree structure to create the integration components. The
Meta data of this integration object is specified in the below tabular format.
Integration Object Row Details

Name AZ QUATTRO Create SR Request IO
Base Object Type Siebel Business Object
External Name Home (eService)
XML Tag ListOfAzQuattroCreateSrRequestIo
Integration Component Row Details

Name Service Request (eService)
External Name Service Request (eService)
Cardinality Zero or More
XML Tag Request
Integration Component Field Details

IC Field 1
Name INS Area
11 | P a g e
External Name INS Area

XML Tag Area
IC Field 2
Name INS Sub-Area
External Name INS Sub-Area
XML Tag SubArea
IC Field 3
Name SR Type
External Name SR Type
XML Tag Type
IC Field 4
Name Abstract
External Name Abstract
XML Tag Description
IC Field 5
Name Status
External Name Status
XML Tag Status
 Green shaded text indicates the manually edited properties of IC field
Note: The Meta data is provided just for your reference. You do not have to create any of the data in
the above tabular format manually. Integration Object should be created only through wizard to avoid
any kind of human error. After the creation of the integration object through wizard, the only part that
should be modified is the XML Tag in IC and IC Field. The manually edited values are shaded in green
color in the above tabular format. Let me emphasize once again that the rest of the data will be created
automatically by the wizard. Be very cautious in changing the XML tags. You should never change the
XML tag of the IO; however, the XML tags of IC and IC fields are flexible enough to undergo changes.
12.3 Creation of Response Integration Object
Integration Objects could be created through Siebel Tools. The wizard easily guides the creation of the
integration object. To create the request integration object, do the following.
In Siebel Tools, open File -> New Object -> EAI tab in the wizard -> Select Integration Object.
The wizard systematically guides you to select the source object, to give a name to the integration
object, and to select the components from the tree structure to create the integration components. The
Meta data of this integration object is specified in the below tabular format.
Integration Object Row Details

Name AZ QUATTRO Create SR Response IO
Base Object Type Siebel Business Object
External Name Home (eService)
12 | P a g e
XML Tag ListOfAzQuattroCreateSrResponseIo
Integration Component Row Details

Name Service Request (eService)
External Name Service Request (eService)
Cardinality Zero or More
XML Tag Response
Integration Component Field Details

IC Field 1
Name INS Area
External Name INS Area
XML Tag Area
IC Field 2
Name INS Sub-Area
External Name INS Sub-Area
XML Tag SubArea
IC Field 3
Name SR Type
External Name SR Type
XML Tag Type
IC Field 4
Name Abstract
External Name Abstract
XML Tag Description
IC Field 5
Name Status
External Name Status
XML Tag Status
IC Field 6
Name SR Number
External Name SR Number
XML Tag SRNumber
 Green shaded text indicates the manually edited properties of IC field
Note: The Meta data is provided just for your reference. You do not have to create any of the data in
the above tabular format manually. Integration Object should be created only through wizard to avoid
any kind of human error. After the creation of the integration object through wizard, the only part that
should be modified is the XML Tag in IC and IC Field. The manually edited values are shaded in green
color in the above tabular format. Let me emphasize once again that the rest of the data will be created
automatically by the wizard. Be very cautious in changing the XML tags. You should never change the
XML tag of the IO; however, the XML tags of IC and IC fields are flexible enough to undergo changes.
13 | P a g e
12.4 Creation of Workflow Process Properties
The following are the process properties to be created in the new workflow.
Workflow Details
Name AZQUATTROCreateServiceRequestWF
Business Object Home (eService)
Mode Service Flow
Process properties
Name Data Type In/Out Integration Object
Request Integration Object In AZ QUATTRO Create SR Request IO
Response Integration Object In AZ QUATTRO Create SR Response IO
Area String None NA
Sub Area String None NA
Type String None NA
Description String None NA
SR Number String None NA
Status String None NA
XML Hierarchy Hierarchy None NA
Siebel Message Hierarchy None NA
Important Note: The workflow, by default, generates process properties like Error code, Error Message,
et cetera. You should make sure to change the In/Out property to None for all those default process
properties. To be precise, there should be only one IN and one OUT. The rest of the process properties
should be set to NONE.
12.5 Workflow Skeleton
The canvas editor of the workflow should have the following workflow steps dragged and dropped from
the palette window. The steps should be properly connected through connectors.
12.6 Workflow Step Details
The following tabular formats detail the input and output argument required for each workflow step.
Step 1
14 | P a g e
This workflow step converts the integration object instance into an XML Hierarchy instance. XML
Hierarchy is required for the next workflow step in sequence.
Step Details
Name IO to XML Hier
Business Service EAI Integration Object to XML Hierarchy Converter
Business Service Method IntObjHierToXMLHier
Input Arguments
Name Type Value Property Name
SiebelMessage Process Property NA Request
Output Arguments
Property Name Type Value Output Argument
XML Hierarchy Output Argument NA XMLHierarchy
Step 2
This workflow step extracts the values of each service request parameter. The extracted parameters will
be used to create the service request. The extraction happens through a vanilla business service, which
is quite handy in these kinds of situations. To extract values, the mandatory input is the instance of type
XML Hierarchy, without which, the extraction cannot happen.
Step Details
Name Extract Parameters
Business Service FINS Industry XML Query Service
Business Service Method Execute
Input Arguments
XMLHierarchy Process Property NA XML Hierarchy
QueryString_1 Literal /*/Request/Area NA
QueryString_2 Literal /*/Request/SubArea NA
QueryString_3 Literal /*/Request/Description NA
QueryString_4 Literal /*/Request/Type NA
QueryString_5 Literal /*/Request/Status NA
Output Arguments
Area Output Argument NA QueryString_1
Sub Area Output Argument NA QueryString_2
Description Output Argument NA QueryString_3
Type Output Argument NA QueryString_4
Status Output Argument NA QueryString_5
Step 3
15 | P a g e
This workflow step creates the service request through the usage of a custom business service. The
extracted parameters, in the previous workflow step, will be passed to this custom business service. The
business service creates Service Request, and returns the SR Number to the workflow step.
Step Details
Name Create SR
Business Service AZ QUATTRO Create SR Service
Business Service Method CreateSR
Input Arguments
BSArea Process Property NA Area
BSSubArea Process Property NA Sub Area
BSDescription Process Property NA Description
BSType Process Property NA Type
BSStatus Process Property NA Status
Output Arguments
SR Number Output Argument NA BSSRNumber
Very Important Note: In general, a custom business service is not required for the creation of a very
simple entity. A Siebel Operation workflow step or the vanilla business service Inbound E-mail
Database Operations could also perform the same job. But, the Service Request entity is a bit different
from other entities as it has got hierarchical pick lists in it – especially for Area and Sub Area. While
creating SR through Siebel Operation, if Sub Area is set first, and then the Area, then it leads to the
violation of the hierarchical pick list. So, for the creation of a service request, it is always suggested to
have a custom business service.
Optionally, the service request can also be created by EAI Siebel Adapter. To create the Service Request
through EAI Siebel Adapter, the integration object named AZ QUATTRO Create SR Request IO should
have a user key defined in it. But, it is not possible to have a user key for this entity.
Step 4
The objective is to send the response in the form of a Siebel message. So, an empty Siebel message has
to be created with the help of this vanilla business service. The vanilla business service in this workflow
step accepts the name of the integration object, and outputs an empty Siebel message.
Step Details
Name Create Empty Property Set
Business Service PRM ANI Utility Service
Business Service Method CreateEmptyPropSet
Input Arguments
Hierarchy Name Process Property NA AZ QUATTRO Create SR Response IO
Output Arguments
16 | P a g e

Siebel Message Output Argument NA SiebelMessage
Step 5
The empty Siebel message should now be populated with the Service Request values. The easiest way
of populating an empty Siebel message is with the usage of a declarative data map. The values to be
populated in the Siebel message are passed to the data map as integration arguments in this workflow
step. This workflow step executes the data map, performs the transformation and outputs the
transformed Siebel message.
Step Details
Name Populate Response
Business Service EAI Data Transformation Engine
Business Service Method Execute
Input Arguments
SiebelMessage Process Property NA Siebel Message
Map Name Literal Create SR Data Map NA
Area Process Property NA Area
Sub Area Process Property NA Sub Area
Description Process Property NA Description
Type Process Property NA Type
Status Process Property NA Status
SR Number Process Property NA SR Numb
Output Integration Literal AZ QUATTRO Create SR NA
Object Name Response IO
Output Arguments
Siebel Message Output Argument NA SiebelMessage
Step 6
The Siebel message generated through a data map will always have the header as Siebel Message. But,
the external system expects the header of the Siebel Message as Response. This workflow step uses a
vanilla business service to rename the header of the Siebel Message from Siebel Message to Response.
Step Details
Name Rename Response Header
Business Service PRM ANI Utility Service
Business Service Method SetChildType
Input Arguments
ChildType:SiebelMessage Literal Response NA
17 | P a g e
SiebelMessage Process Property NA Siebel Message

Output Arguments
Response Output Argument NA Response
12.7 Creation of data map
The data map is required to populate the Siebel message with values of the Service Request parameters.
The data map and data map arguments can be created at the following places, respectively.
Data map: Integration Administration -> Data Map Editor
Map Arguments: Integration Administration -> Data Map -> Arguments Applet
The tabular format shows the integration map arguments to be created.
Data Map Details

Name Create SR Data Map
Map Arguments
Name Type
Area DTYPE_TEXT
Sub Area DTYPE_TEXT
Description DTYPE_TEXT
Type DTYPE_TEXT
Status DTYPE_TEXT
The tabular format shows the integration object map to be created in the Data Map Editor.
Integration Object Map Details

Name Create SR Data Map
Source Integration Object AZ QUATTRO Create SR Response IO
Target Integration Object AZ QUATTRO Create SR Response IO
The tabular format shows the integration component map.
Integration Component Map Details

Name Map1
Source Integration Component Service Request (eService)
Target Integration Component Service Request (eService)
The tabular format shows the integration component field maps.
Integration Component Field Map Details
18 | P a g e
Source Expression Target Field

[&Area] INS Area
[&Sub Area] INS Sub-Area
[&Description] Abstract
[&Type] SR Type
[&Status] Status
[&SR Number] SR Number
12.8 Creation of Business Service
The following business service is used to create a service request record. It returns the SR Number to
the calling function. The business service details are shown in the below tabular format.
Business Service Details

Name AZ QUATTRO Create SR Service
Method CreateSR
Method Arguments
Name Type Input/Output
BSArea String Input
BSSubArea String Input
BSType String Input
BSDescription String Input
BSStatus String Input
BSSRNumber String Output
Pseudo code
function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
if (MethoName == "CreateSR")
{
var strArea = Inputs.GetProperty("BSArea");
var strSubArea = Inputs.GetProperty("BSSubArea");
var strDescription = Inputs.GetProperty("BSDescription");
var strType = Inputs.GetProperty("BSType");
var strStatus = Inputs.GetProperty("BSStatus");
var BO = TheApplication().GetBusObject("Home (eService)");

var BC = BO.GetBusComp("Service Request (eService)");
BC.ClearToQuery();
BC.NewRecord(1);
BC.SetFieldValue("INS Area", strArea);
BC.SetFieldValue("INS Sub-Area", strSubArea);
BC.SetFieldValue("Abstract", strDescription);
BC.SetFieldValue("SR Type", strType);
BC.SetFieldValue("Status", strStatus);
BC.WriteRecord();
Outputs.SetProperty("BSSRNumber", BC.GetFieldValue("SR Number"));
19 | P a g e
return (CancelOperation);
}
return (ContinueOperation);
}
12.9 Deploying a workflow as a web service
This is the final step in the implementation of the inbound web service. For registering an inbound web
service, navigate to Web Services Administration -> Inbound Web Service
The tabular format shows the web service details.
Web Service Details

Name AZ QUATTRO Create Service Request
Namespace http://siebel.com/CustomUI
Status Active
Service Port Record Details

Name Create Service Request
Type Workflow
Business Service/Process AZQUATTROCreateServiceRequestWF
Transport HTTP
Binding SOAP_DOC_LITERAL
Address http://172.18.113.6/eai_enu?start.swe&SWEExtSo
urce=WebService&SWEExtCmd=Execute&UserNam
e=eaiuser&Password=eaiuser
Operation Record Details

Name Create SR
Method Display Name Run Process
Authentication Type None
Note: Once the web service is registered, make sure to click the button Clear Cache. This button is
supposed to be clicked every time a change occurs to the web service.
12.10 Generating WSDL
If the web service has been registered appropriately with the port and operation records, then the
WSDL will get generated successfully. WSDL can be generated by clicking the button Generate WSDL.
This button appears on the first applet of the inbound web service view.
20 | P a g e
12.11 Consuming the web service
Once the WSDL is generated, the next step would be to share it with the external systems. It could be
shared with those who want to create service request remotely in the CRM system. External systems do
their configurations to consume the functionality of creating the SR in Siebel.
12.12 Testing the web service
Before passing it to the external system, it would be recommended to test the WSDL using some third
party tool like Soap UI or XML Spy or any other Soap Tool. This would make sure that CRM system has
generated an ideal WSDL, which can be consumed by any other external system.
12.13 Using Local Web Service
Local Web Service is one of the transports, which is used to test the inbound web service within the
Siebel application. No third party tool is required if we change the transport of the inbound web service
from HTTP to Local Web Service. Another important change would be to have the same value of the
Port Name to the Address as well. Precisely, these would be the changes required to the port record to
use the Local Web Service transport.
1) Change transport from HTTP to Local Web Service

2) Port Name and Address fields should have the same value
Once the changes are done, click the Clear Cache button. Now, you could successfully test your inbound
web service by simulating it in the Business Service Administration Screen.
In the Simulator View of this Screen,
1) Select business service as Web Service Inbound Dispatcher

2) Select method as Dispatch
In the parameters to be passed, pass
1) The Soap Request

2) The Transport Type as LOCAL_WEB_SVC
Then, click the Run button on the Simulator View. The results appear on the third applet of this view.
For more details on this transport, check the support web.
21 | P a g e
<?xml version="1.0" encoding="UTF-16"?><SOAP-ENV:Envelope xmlns:SOAP-

ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cus="http://siebel.com/CustomUI"
xmlns:oi="http://www.siebel.com/xml/Oi%20Conta%20IO"><SOAP-
ENV:Body><cus:ImportAccount><oi:Request><oi:ListOfOiContaIo><oi:OiConta><oi:IntegrationId>11111
</oi:IntegrationId><oi:Name>Inga Account</oi:Name><oi:ParentAccountName>Test
Account</oi:ParentAccountName><oi:Type>Client</oi:Type></oi:OiConta></oi:ListOfOiContaIo></oi:Re
quest></cus:ImportAccount></SOAP-ENV:Body></SOAP-ENV:Envelope>
OUTBOUND WEB SERVICES
1. Definition of Outbound Web Service
Outbound web services are typically used to consume the business services from an external system.
The consumed information will be displayed onto the Siebel User Interface. Nevertheless, the displayed
information might not be stored in the Siebel database. The consumed information will be displayed on
the UI using the concept of Virtual Business Components.
2. Business Scenario
The Siebel CRM application wants to show the billing related information like Account Balance on the
Siebel application. In general, the billing related information will not be replicated in the Siebel
database. The only way to show the Account Balance on the Siebel application is to fetch the data from
the billing database and show it on the Siebel User Interface.
To achieve such a requirement, the usage of an outbound web service is one of the effective solutions.
The billing system provides Siebel CRM system a web service, through which, Siebel CRM system can
consume the account balance and show it on the Siebel User Interface.
3. Consumed Information through a web service
Siebel CRM system consumes the services provided by the external system through a web service. The
consumed information can be either stored into the Siebel database or just showed on the Siebel User
Interface without storing them in the Siebel database.
 To store the consumed information into the Siebel database, the methods of a predefined
business service EAI Siebel Adapter will be used.
 To display data onto the Siebel User Interface without replicating data in the Siebel database,
the concept of Virtual Business Component will be used.
22 | P a g e
4. Flow of Outbound Web Service
The following steps describe the end-to-end flow of consuming a web service of an external system by
the Siebel CRM system and using the fetched data as required.
Create a Virtual Business Component with required fields. This VBC is used to show up the data
consumed from the external system through the outbound web service.
Create an internal request integration object based on this Virtual Business Component. Also, create an
internal response integration object based on the same Virtual Business Component.
Generate the XSD for internal request integration object, and generate the XSD for internal response
integration object. Generate Schema button can be used to generate XSD.
Hand over both the XSD files to the external system, typically a middleware system like AIA. AIA will
generate the WSDL based on these XSD files.
Get the WSDL from the AIA team. The crucial step is to import the WSDL in Siebel Tools. Precisely, the
WSDL can be imported in Siebel Tools using a wizard – File -> New Object -> EAI tab -> Web Service.
On a successful import of the WSDL, Siebel Tools creates a proxy business service, a request external
integration object and a response external integration object. It also creates an XML, which can be used
to register the outbound web service in the thin client.
Use the generated XML to register the outbound web service in Administration – Web Services ->
Outbound Web Services. Make sure to correctly specify the end-point URL in the service port record. If
no security is required, make sure to select the Authentication Type as None.
Please note that it is always not mandatory for the Siebel Tools to create the external integration
objects. To create or not to create the external integration object is completely dependent on the kind
of WSDL we get from the external system. If the WSDL does not have any complex or hierarchy data
types in it, no external integration object gets created in Siebel Tools. However, the mandatory object
that gets created in Siebel tools is Proxy Business Service.
Create a workflow to formulate the request Siebel message, to trigger the proxy business service for
sending the web service request, to get the response from the external system and to use the response
to display it on the Virtual Business Component Applet.
Create user properties in the Virtual Business Components, which will be used for the initiation of the
outbound web service request from Siebel CRM system. The user properties are
Service Name – SIA Billing Extern Service
23 | P a g e
Process Name - <Name of the workflow you create>
Outgoing Integration Object Name - <Name of the internal request integration object>
Proxy BS Name - <Name of proxy BS generated after importing WSDL>
Proxy BS Method - <Method of proxy BS generated after importing WSDL>
Proxy BS Param: Request Message Type - <Request argument of proxy BS>
Proxy BS Param: Response Message Type - <Response argument of proxy BS>
Disable Execute – N
Enable Caching – Y
Make sure the class of the Virtual Business Component is CSSFABCVRec
Whenever the Virtual Business Component gets executed, the predefined business service SIA Billing
Extern Service gets executed. It accepts two parameters from the user properties. The first one is the
name of the workflow and the second one is the name of the Outgoing IO Name.
This business service formulates the request Siebel message with the help of Outgoing Integration
Object Name and inputs the same to the workflow; and it starts executing the workflow as well. This is
exactly how the process of outbound web service starts.
The workflow accepts the request Siebel message from the predefined business service SIA Billing Extern
Service. Optionally, the workflow will have its own mechanism to prepare the request Siebel message
using either EAI Siebel Adapter or (PRM ANI Utility Service and Data Map). In such a case, the request
Siebel message sent by the SIA Billing Extern Service will be ignored.
The workflow triggers the proxy business service to send the request Siebel message as part of the Soap
Request, and then gets the Soap Response from the Siebel Message. The workflow uses the method
AddSiebelMessage of the predefined business service CMU External Integration Service to display the
response data onto the Virtual Business Component’s applet.
5. Request Filter Service
Before sending the Soap Request to the external system, if you want add Soap Header to the Soap
Message, Request Filter Service is an ideal approach to incorporate the Soap Header. Basically, a
business service should be created to create the Soap Header and to attach it to the Soap Request.
6. Response Filter Service
24 | P a g e
The Response Filter Service is rarely used. If there are certain critical parameters as part of the
Response Soap Header, and if you want to use them for some logical purposes or if we want to store
them in profile attributes, then a custom business service can do the job for you. This custom business
service should be picked from the Response Filter Service property of the outbound web service.
7. Local Business Service
Local Business Service is one of the transports, which is specifically used in Outbound Web Services.
While one of the ways for adding the Soap Header to the Soap Request is Request Filter Service, the
other way is to first route the Soap Request to a custom business service through the Local Business
Service transport, add the Soap Header to the Soap Request as required in the custom business service,
and then trigger the proxy business service to send across the Soap Request Message to the external
system. Besides adding the Soap Header, the custom business service can perform any kind of
modifications to the Soap Request.
To enable the Local Business Service transport, make sure the following is done.
1) Select the transport as Local Business Service in the Service Port record.
2) In the address field, instead of end-point URL, type the name of the custom business service.
8. Outbound Web Service Workflow Example
The following workflow diagram is a typical example for an outbound web service.
25 | P a g e
1) Get Parameters: This workflow step is a business service step, which uses Workflow Utilities business
service and an Echo method. This will make sure that all the required values for the processing of this
workflow are stored in the process properties.
2) Create Empty Siebel Message: The request siebel message has to be sent before the proxy business
service is triggered. So, this workflow step creates an empty siebel message first. This workflow step
uses PRM ANI Utility Service business service and CreateEmptyPropSet method.
3) Populate Siebel Message: This workflow step makes sure that the empty siebel message is populated
with the required data in it. The population of data happens through a declarative data map. This
workflow step uses EAI Data Transformation Engine and Execute method.
4) Convert request to XML: This workflow steps converts the request siebel message into an XML
document. In crisis, if you want to see the kind of request siebel message being formulated, it’s better
to write it to a flat file. However, the siebel message is not readable. So, instead of writing the siebel
message to the flat file, you convert the siebel message to an XML, and then write XML to the flat file.
5) Request Write to File?: The process of writing the request to the flat file is conditionally enabled. If
the condition is enabled, it’s written to the flat file. Otherwise, writing to flat file is ignored.
6) Write Request to File: This workflow step makes sure that it writes the request XML document to the
flat file. It uses EAI File Transport business service and the Send method.
7) Rename request proxy header: While sending Soap Request to the external system, you should
make sure the top header of the request siebel message is the name of the input argument of the proxy
business service. Otherwise, the Soap Body goes empty to the external system.
In this workflow, the top header element of the request siebel message will surely be Siebel Message
and will not be the name of the input argument of the proxy business service. Because, the output of a
data map will always make sure that the top header of the siebel message as Siebel Message.
So, you need to make sure that the top header element Siebel Message is renamed to the specific input
argument name of the proxy business service. This workflow step renames the Siebel Message to the
desired name. It uses PRM ANI Utility Service and SetChildType method.
Please note that this conversion is required only when the workflow mode of your workflow is specified
as 7.0 instead of the Service Flow. Otherwise, this workflow step can be ignored.
8) Proxy Business Service: Proxy Business Service is used to send the Soap Request to the external
system, and to get the response from the external system. This workflow step uses the name of the
proxy business service (generated after importing WSDL) as the business service and the name of the
proxy business service’s method as method.
26 | P a g e
9) Rename response proxy header: To use the response, you need to make sure the top header of the
response will be Siebel Message. So, a conversion is required from the output argument of the proxy
business service to Siebel Message. This is similar to the step 7.
10) Convert response to XML Hier: This workflow step is used to convert the siebel message to XML
Hierarchy. It uses EAI Integration Object to XML Hierarchy Converter business service.
11) Extract Status: This workflow step extracts the status from the XML Hierarchy. The requirement is
to place the data onto VBC Applet, only when the status is Successful (1). So, this workflow step extracts
the status using FINS Industry XML Query Service business service and Execute Method.
12) Is Status Error: This decision point workflow step check if the extract status is Success or Error.
Accordingly, it moves further in the workflow.
13) Update VBC: This workflow step places the response data onto the VBC applet using CMU External
Integration Service Business Service and AddSiebelMessage method. This predefined business service
and method reduces a lot of effort.
14) Convert response to XML: This workflow steps converts the response siebel message into an XML
document. In crisis, if you want to see the response siebel message sent by external system, it’s better
to write it to a flat file. However, the siebel message is not readable. So, instead of writing the siebel
message to the flat file, you convert the siebel message to an XML, and then write XML to the flat file.
15) Response Write to File?: The process of writing the response to the flat file is conditionally enabled.
If the condition is enabled, it’s written to the flat file. Otherwise, writing to flat file is ignored.
16) Write Response to File: This workflow step makes sure that it writes the response XML document to
the flat file. It uses EAI File Transport business service and the Send method.
9. Outbound Web Service Workflow File
The workflow described above is embedded below. This can be imported in any of the versions of Siebel
Tools starting from Siebel 7.7. Go through the workflow steps in Siebel Tools to get more awareness of
the workflow steps described in the above section.
27 | P a g e
28 | P a g e

Web Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services

Uploaded by

Copyright:

Available Formats

Siebel Enterprise Application Integration Monday, April 04, 2011

Siebel Enterprise Application Integration

Author: Saiganesh Padmanabhan

INBOUND WEB SERVICES .............................................................................................................................. 4

3. Consumed Information through a web service .......................................................................... 22

INBOUND WEB SERVICES

1. Definition of Inbound Web Service

3. Objects that can be deployed as Inbound Web Services

4. Types of Inbound Web Services

There are two types of inbound web services –

1) Inbound with no response

5. Flow of Inbound Web Services

6. User name token security measure

7. Incorporation of Soap Headers

8. Anonymous Web Services

 In the named sub-system SecureWebService, the profile configuration parameter Impersonate

9. Authentication Types for Web Services

10. Enabling session management for web services

11. Implementing session management

 <soap: Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>

 <soap: Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>

12. Inbound Web Service Example

12.1 Solution Outline

1) Create request and response integration objects.

12.2 Creation of Request Integration Object

Integration Object Row Details

Integration Component Row Details

Integration Component Field Details

External Name INS Area

 Green shaded text indicates the manually edited properties of IC field

12.3 Creation of Response Integration Object

Integration Object Row Details

XML Tag ListOfAzQuattroCreateSrResponseIo

Integration Component Row Details

Integration Component Field Details

 Green shaded text indicates the manually edited properties of IC field

12.4 Creation of Workflow Process Properties

12.5 Workflow Skeleton

12.6 Workflow Step Details

Property Name Type Value Output Argument

SiebelMessage Process Property NA Siebel Message

12.7 Creation of data map

Data map: Integration Administration -> Data Map Editor

The tabular format shows the integration map arguments to be created.

Data Map Details

Integration Object Map Details

The tabular format shows the integration component map.

Integration Component Map Details

The tabular format shows the integration component field maps.

Integration Component Field Map Details

Source Expression Target Field

12.8 Creation of Business Service

Business Service Details

var BO = TheApplication().GetBusObject("Home (eService)");

Outputs.SetProperty("BSSRNumber", BC.GetFieldValue("SR Number"));

12.9 Deploying a workflow as a web service

The tabular format shows the web service details.

Web Service Details

Service Port Record Details

Operation Record Details

12.10 Generating WSDL

12.11 Consuming the web service

12.12 Testing the web service