Our Web Service is complete – now we can use soapUI to test it.

1. First up, make sure everything is deployed:
   • SRF - compiled and deployed to the server
   • Workflow Process – Deployed through Tools and Activated through the Web Client. Double check that the Integration Object property has been set against the ‘SiebelMessage’ process property
   • Web Service – click the ‘Clear Cache’ button in the Inbound Web Services view to ensure Siebel can process incoming requests
2. Launch soapUI and create a new project via File > New soapUI project
3. Give the project a name of ‘My Siebel Web Service’ and browse for the WSDL file that we generated last time. Leave the ‘Create Requests’ checkbox as the only one checked for now
4. In the navigator on the left you’ll see you project. Beneath that, you’ll see your Web Service and the ‘port’ that we exposed in Siebel – getCustomerDetails. Beneath that is a sample request called ‘Request 1′. Double click it
5. soapUI will use the WSDL to construct a SOAP message in the format Siebel will expect. This includes a handy placeholder for the ‘CustNum’ input property. Populate this will a ROW_ID of a Contact from your server environment
6. Click the green ‘Submit Request’ button in the top left of the window. soapUI will use the URL that you gave in the Web Service definition, as it’s now part of the WSDL. It will submit the package via HTTP to your Siebel Web Server
7. On receipt, the SWE will pass the message contents on to the appropriate object manager for processing, returning the response back to the caller
8. In the right side pane of soapUI, you should shortly see a response in the format defined in the IO that we created in Part 1!
   • If the response looks garbled, go to File > Preferences, HTTP Settings and uncheck ‘Accept compressed responses from hosts’

And that, as they say is that.

I hope you have enjoyed this series of articles and that you have learned a little about Web Services and their application in Siebel.

Next time, we’ll take a look at Outbound Web Services, where Siebel can be configured to consume functionality exposed through external applications.

Now that we have our IO and Workflow Process defined, we can look at exposing these through a Web Service. Luckily, Siebel has a number of functions that will allow us to do this quickly and easily!

1. Having tested the Workflow Process that we created last time, check in the IO and Workflow Process. Compile and deploy an SRF and deploy the Workflow Process through Administration > Business Processes > Workflow Deployment
2. Here comes the easy part! In Siebel Tools, connected to the Server data source, locate your Workflow Process, right click and select ‘Deploy As Web Service…’
3. The ‘operation name’ is the ‘port’ that the external system will refer to. Think of this as a function name in a class or Business Service definition. Specify a value of ‘getCustomerDetails’
4. The URL of the Web Service is the URL on which the external system will communicate with the Object Manager supporting the Workflow process. For example:
   • http://myhost/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1
   • Stick to this template for now – you can always change it later and we’ll see how to do so shortly
5. Leave ‘Generate WSDL’ unchecked for now and click ‘Finish’
6. Now log into the application thin client. Navigate to Site Map > Administration – Web Services > Inbound Web Services and query for ‘My Web Service Workflow’. Siebel will have set it all up for you, based on the properties of the Workflow Process
7. In order to get things working quickly, make a few changes to the Service Port. Be sure to set the login details appropriately. This allows the external application to call the Web Service without having to supply authentication details:
   • Binding: SOAP_RPC_LITERAL
   • Address: http://myhost/eai_enu/start.swe?SWEExtSource=SecureWebService&SWEExtCmd=Execute&UserName=SADMIN&Password=SADMIN
8. Click the ‘Generate WSDL’ button and save the resulting file somewhere safe
9. Click the ‘Clear Cache’ button, to force a referesh of Siebel’s Web Service cache – if you don’t do this, you’ll get an error when you try to call the Web Service

You have now created a Siebel Web Service that can be called remotely, from any machine with access to your Web Server.
In the next post, I’ll explain how to test this and see some useful results.

Having created our IO, we can now move on to the Workflow Process. We’ll use this to pull in the inputs, extract the data and map it into the IO.

1. Start off by creating a new Workflow Process in the Project that we created last time. Call it ‘My Web Service Workflow’ and set the Business Object property to ‘Contact’
2. Let’s set up some important Process Properties:
   • CustNum – In – String: this will act as our ‘input’ to the Web Service
   • SiebelMessage – Out – Integration Object: this will act as the ‘output’ of the Web Service
   • Setting the other Process Props to ‘None’ helps to keep things neat and tidy
3. An important step here is to set the ‘Integration Object’ property of the ‘SiebelMessage’ property to ‘My Contact IO’. This will allow Siebel to work out the ‘output’ format when it generates the WSDL for our Web Service
4. Edit the Workflow: drag Start, Business Service and End steps into the designer and link them up. If you have an exception handler Business Service, you can also add a Business Service step with an exception branch from the other. Link this up to the End step to complete the design:



5. In the first Business Service, set the following properties:
   • Business Service Name: EAI Siebel Adapter
   • Business Service Method: Query
   • This will invoke the Siebel Adapter ‘Query’ method, which will query the underlying BC and populate the SiebelMessage using the IO that we created earlier. You can get more information on this Business Service in the ‘Integration Platform Technologies: Siebel Enterprise Application Integration’ bookshelf guide
6. Set the input arguments as follows:
   • SearchSpec – Expression – “[Contact.Id] = ‘” + [&CustNum] + “‘” : This provides the search criteria for the query. In this case, we’re passing in the ‘ROW_ID’ as the CustNum. Note that Siebel evaluates the whole string as an expression, hence the quotes
   • OutputIntObjectName – Literal – My Contact IO : this tells the method how to retrieve and map the Contact fields to our output format
7. Now set the output arguments:
   • SiebelMessage – Output Argument – SiebelMessage
8. Test through the simulator by populating the ‘CustNum’ default string value with a ROW_ID from a Contact in your environment. By enabling the ‘Watch’ window you should see a fully populated ‘SiebelMessage’ with the contact details that we’re looking for

Our next step is to expose this Workflow through a Web Service, which will allow our external application to push in a Contact ROW_ID and pull back the name and address details.

To begin creating our Inbound Web Service, let’s first recall what that means: we’re going to expose some function of Siebel for an external client to access. There are two basic entities that we can expose externally: Workflow Processes and Business Services. Siebel Tools offers some really helpful functions to expose Workflows so we’ll take that for our example.

Let’s consider this requirement:

We’ll create a Web Service to achieve just this.

First of all, consider the components we mentioned in the last post:

1. Integration Object – this is important as it defines what data we’ll pull from the Siebel BCs and how it will be presented in XML
2. Data Map – this is useful, but not essential: if we want to map and transform data, we can put a DataMap step in the Workflow to achieve this, using a defined Data Map object. We won’t do this in the example.
3. Workflow Process – we’ll create a Workflow to read in our inputs, pull out our outputs and handle any exceptions. This will also form the basis for our Web Service
4. Inbound Web Service – we’ll get Siebel to create this for us and this will allow us to generate our WSDL file that we can deploy to our external system

In the next four posts, I’ll cover off these items culminating in testing our new Web Service. Today, we’ll start off by creating a new Integration Object.

Let’s start by creating a new project in Tools called My Web Service and lock it. Then follow these steps to build the components:

1. Select the ‘File > New Object’ menu item, select the ‘EAI’ tab and select the ‘Integration Object’ item
2. Select your Project then select the ‘EAI Siebel Wizard’
3. We’re returning Contact details so select the ‘Contact’ BO and ‘Contact’ BC from the drop down lists. Let’s call the new IO ‘My Contact IO’
4. You’ll see a number of relationships returned, but we’re only interested in name and address details, so uncheck everything except for the top level ‘Contact’ and ‘Contact_Personal_Address’ objects
5. Once the process is complete, your new IO will be brought to focus in Tools. Expand it fully and you will see we have created basic mappings for all Contact and Personal Address fields. Tools has even specified XML tags for each field and relationship, so you don’t have to.
6. We don’t need all these fields returned, so inactivate all Integration Component Fields in Contact except for:
   • Id
   • First Name
   • Last Name
   And for the purpose of maintaining the user keys:
   • Account Integration Id
   • Employee Number
   • Personal Contact
   • Person UId
   • Personal Contact
   • Primary Organization

Use the ‘Edit > Change Records’ menu item to do this quickly.

7. Personal Address has a far more manageable number of fields, so leave that as it is.

We now have the basis for the extracting of information from our Contact BC into a format that can be mapped directly into the XML of our SOAP message. This is a major stepping stone to completing our Web Service.