If you receive errors when attempting to view this white paper, please install the latest version of
Adobe Reader.
"Green Beacon has worked with best of breed CRM, ERP, Marketing Automation, and Business Intelligence solutions from leading providers including Microsoft, Oracle (
Siebel), Epicor, Onyx, and Smartfocus - enabling
the Green Beacon team to serve as a trusted advisor for mid-market organizations"
Source : Green Beacon Solutions
Web 2.0: “Code Free” Siebel Web Service Integration
Web Service is also known as :
Web Service,
Web Services White Paper,
Services Web Projects,
Integrate Web Services,
Use Web Services,
Web Services for Apps,
Web Services to Build,
Webservice,
Web Services Architecture,
Web Services Glossary,
Basic Web Services,
Web Services Platform,
Term Web Services,
Creating Web Services,
Web Services Definition,
Web Services Developer Center,
Web Services Industry,
Web Services Portal,
Neutral Web Services,
Web Service Directory,
Web Service Sample,
Web Service Security,
Web Services Section,
Web Services Lists,
Web Service Technologies,
Applications Web Services,
Need Web Services,
Bloglines Web Services,
Find Web Service,
Web Services Blog,
Web Services Products.
Overview
One of the most challenging areas in the Siebel IT space has traditionally been setting up
and maintaining interfaces between Siebel and other systems. The amount of custom scripts,
the need for technical knowledge of both integrated systems, and problems with
upgradeability have all been significant challenges to over come during an integration
project.
In Siebel 7.8 and 8.0, there are a tremendous number of advancements in Web Services,
Workflow, and EAI Business Services that make it possible to create real-time web service
interfaces to other applications without having to script a single line of code. This was not
possible with prior versions, even as recent as v 7.5. These advancements also make it
possible to have a straight forward upgradeable path as well as reduce the need for cross
technical knowledge between the systems.
Web service integrations can give the Siebel end users extreme useful and current data.
Below are just a few examples of this type of interface:
- Internal Applications – Real-time account credit data, order submission, logistics
tracking, or payment status from the financials and back office applications;
- External Services - Address cleansing, news services, exchange rates, credit card
processing, or shipping information;
- Other Siebel Deployments – Exchange data with Universal Customer Master
(UCM) or a division of the company that is on a separate implementation; or
- Government Agency Data - Access to public database.
Understanding Web Services in Siebel
Diagram 1: Run-time Web Services
A Web Service is the end point of an interface in a Service-Oriented Architecture (SOA).
The interface is defined by a contract between the systems and published by the providing
system. The big advantage of this contract is that the technical teams can build to the
contract without needing to understand the technology of the other system.
Diagram 2: Web Service Set Up
The contact is defined as a Web Service Description Language or WSDL (pronounced
wiz-dl). It is an XML document that basically contains the following:
- Location of the service or network address
- Objects used in the interface e.g. if the interface deals with accounts, then the account object, including all the fields and child objects such as address and contacts associated to the account would be defined.
- Methods that can be called by the external system. The methods also include the input and output arguments. These arguments are objects described above.
Siebel uses 3 different objects to construct a WSDL:
- Web Services (Inbound and Outbound) which are administered in the Client Application and primarily define the location of the services;
- Integration Objects which define the structure of the data that will be used in the
interface; and
- Business Services which define the methods and process-oriented components of
the WSDL. These can be pre-built (out-of-the-box) or custom. Of course, the custom
Business Services would need to be coded, but often out-of-the-box business
services will meet the business requirements.
Using an Outbound Web Service
A good way of becoming familiar with web services is by working with an existing WSDL.
This can be an internal application or an external company’s service. By importing the WSDL
into Tools and using the resulting Business Service you can quickly become familiar with
passing data between the systems. Diagram 3 and Diagram 4 below demonstrate how to
get such an interface up and running.
This example uses an existing web service. This can be from an internal system with an
available web service or any external or government agency with a web service. Below is a
short list of websites that may help identify some available Web Services:
Diagram 3: Web Service Import into Siebel
- Once you have identified the source of the WSDL, save the xml file locally. It usually
has an extension .wsdl
- Create a new Web Service in Tools using the New Object Wizard.
• In the wizard, enter the WSDL that your Web Service will be based.
- The 4 results of the Web Service wizard are:
- Integration Object(s): Defines the structure of the objects in the external system.
- Business Service: The methods that Siebel can call as well as the inputs and
outputs to those methods. Unlike most Business Services where the
functionality behind the methods is in the Business Service itself, the newly created business service calls a web service, passes the input argument, and waits for the output argument.
- XML Document: Defines the location of the web service.
- Log: A List of the actions and errors.
- Compile the Integration Object(s) and Business Service into the SRF. The application
will need the definitions for the next step.
- Import the XML document created in Step 3 into the Outbound view on the
“Administration - Web Service” screen.
- Siebel now has the ability to call the external application by instantiating the
imported Business Service and calling the appropriate methods. The challenge is now
how to get the data into and out of a format that is appropriate for the Web Service.
This will likely be the bulk of the work in the interface and the most common place
where scripting is used.
The Web Service can be called any number of ways - though scripting, workflow,
runtime events, declarative configuration, or business service simulator. The next
section talks about a workflow and one possible way to work with the inputs and
outputs. (This is, however, by no means the only way to work with Web Services.)
Diagram 4: Siebel Workflow with Web Service Call
Working with Workflow
The workflow illustrated here is a straightforward example, where data is queried from
Siebel, transformed, and sent to an external system. The result from the external system is
transformed again before being saved back in Siebel. Here are some real examples of how
this might be used in a business setting:
- Account data is updated from the financial system with the credit status. The
workflow queries an account to determine the financial system’s account number
stored on the account record. The financial system is called via a web service, which
then returns the credit status and credit limit. The credit status and limit are updated
on the Siebel account record.
- An order is submitted from Siebel to a back office system for provisioning (or
perhaps creating a work order in the Mfg system.) The order is queried then
transformed to a format that is used by the back office system. Any order items that
are not applicable to the back office system are stripped out of the message before
being sent. The back office returns the status of each line item. The statuses are
updated on each item in Siebel.
Workflow Components
Diagram 5: Workflow Components
Web Service Inputs
The inputs to the Web Service may be either of 2 types: a simple string or a complex object.
The simple strings are straightforward, but the complex objects need to be constructed in
memory as Property Sets. These Property Sets need to have the same structure as the
Integration Object(s) that were created when the WSDL was imported.
Creating a Property Set with the right structure can be a 2-step process.
- Query the Siebel object into memory into an Integration Object that is an identical
structure to the Business Objects.
- Map that to an Integration Object that is the structure needed for the Web Service
The Business Service Siebel EAI Adapter can be used for the first step in the Workflow to
query the Siebel Data and populate a Property Set. The Property Set is in the same
structure as an Integration Object based on that Siebel Data.
- Create an Integration object via the wizard based on a Siebel Business Object (EAI
Siebel Wizard). Compile the object
- In the workflow, create a step calling the Business Service Siebel EAI Adapter witha method of Query
- The input to the method Query is the Newly created Integration Object Name
- The output is a Property Set (Siebel Message)
The next step in the Workflow is the Business Service EAI Data Transformation Engine,
(the display name is EAI Data Mapping Engine). This can map data elements between 2
Integration Objects. It uses a data map that is administered in the client. The Data Map
must be defined before the Business Service is added to the workflow.
- In the Client, go to the Administration- Integration -> Data Map Editor
- Create the mapping between a Source Integration Object, which is the object based
on a Business Object and Target Integration Object, which is the object based on
Web Service. Map the components and fields to populate.
- Click Validate to Activate the Map
- Now the data map can be used in the Workflow. Add a step to the Workflow calling
EAI Data Transformation Engine Business Service and use the ‘Execute’ method.
- The inputs to the method include the following:
- The Property Set (Siebel Message) that was an output in the last Workflow step
- The Data Map’s name
- Output Integration Object Name. This is the Integration Object that is both
the target in the data map and the Integration Object created when the
WSDL was imported.
- The output is a Property Set (Siebel Message). It can be the same Property Set as the input of this method.
Web Service in the Workflow
Diagram 6: Data Map Editor View
The Next step in the Workflow is the Business Service that calls the Web Service.
- Add a step to the workflow of the Business Service that was created when the WSDL
was imported.
- The input is the Property Set (Siebel Message) that is the output from the last
Step
- The output is usually a string that contains an XML message. The output may be
a complex object instead of an XML message, in which case it needs to be saved
as a Property Set in the workflow. The process property (or Property Set) should
be an Integration Object type process property. The Integration Object used for
this process property needs to be in the structure of the output from the Web
Service. Creating this Integration Object is explained in the next paragraph.
Web Service Outputs
Whether the output from the Web Service is an XML string or not, it will need to be stored
as a Property Set with a specific structure. That structure is defined by the output from the
Web Service. Another Integration Object needs to be created so that this structure can be
mapped into a structure that Siebel can use to update or insert records. Usually an
application that publishes a WSDL will have a XSD or DTD that defines the structure of the
output. An Integration Object that is the structure of the output can be created by using the
new object wizard and the XSD or DTD. Select the option EAI XSD wizard or EAI DTD
Wizard depending on the type of XML definition (XSD or DTD) from the external system.
Then compile this object. Create a process property in the Workflow that is an Integration
Object type. Reference this newly created object in the process property.
The outputs from the Web Service are usually an XML string that defines a complex
structure. Before that XML is useful, we will have to do 3 steps:
- Convert the XML into a Property Set (optional)
- Map that Property Set to a format similar to Siebel data
- Create or update Siebel records in the database based on the Property Set
To convert the XML into a Property set, use the Business Service XML Hierarchy
Converter with the Method ‘XMLDocToXMLHier’. Again this step may not be needed
depending on the output from the Web Service.
- The input is the Process Property that contains the XML
- The output argument “XML Hierarchy” is set to the process property that is an
Integration Object type.
The next step in the Workflow is to map the data from the structure of the external system
to a structure that Siebel can work with. As before, the Business Service EAI Data
Transformation Engine is used. The target Integration Object will likely need to be
created, then the data map can translate between the Integration Object that is the output
from the last step to an Integration Object that is a structure based on a Siebel Business
Object.
The source object is the data from the external system. The target object will be based on
the Siebel data you are trying to insert or update. This may be the same integration Object
that was in the first step of this Workflow. If it is not the same object, you will need to
create it using the same process as in the first step.
Once you have the both the source and target Integration Objects, map the two together
using the data map editor. Then use that Object Map in the Workflow step.
The last step in the workflow (other than the “End” step) is to persist this object from
memory to the Siebel database. The same Business Service , Siebel EAI Adapter, that
queried the Siebel data in the first step can be used in the last step to save the record. The
difference this time is the method is ‘Insert’ or ‘Update’.
- The input is the Property Set. When inserting or updating records, it is important to
make sure you have the unique User Keys accounted for. For example, if you are
updating an account, the application needs to now which account to update. If you
are creating a record you will need to ensure that the fields that define the record as
being unique as well as all required fields are populated with data.
Summary
By following this process, you should be able to provide extremely useful and timely data to
your Siebel end users.
There is a lot of information in these few pages, and it may take several days of work to
configure this solution. This is particularly true, depending on your familiarity with the tools
and concepts presented here. For the sake of brevity, I have also glossed over some areas
that may be critical for the overall success of this interface. For example:
- Workflow deployment
- How exactly to use the data map editor efficiently
- Error handling within workflows
- Error handling with interfaces and multiple systems
- Hooking up the workflow to triggering events in Siebel
There is a lot of information in Bookshelf on these topics, but maybe it will be the subject of
another Green Beacon Tech newsletter.
* “Code Free” refers to the fact that often these interfaces do not require scripting. When
the systems require very complex data transformations, or when there is extensive
triggering and post processing logic; scripting may be the best solution.
For questions and comments, please write to:
Mark Schneider
Green Beacon Solutions, LLC
100 Talcott Avenue
Watertown, MA 02472
(617) 612-3000
siebel@greenbeacon.com
www.greenbeacon.com