Invoke Inbound Web Service Locally Using Web Service Inbound Dispatcher

How To Invoke Inbound Web Service Locally Using Web Service Inbound Dispatcher

This document demonstrates a method of testing an inbound web service locally (i.e. no Siebel Server / web server required). It is an alternative approach to that outlined in How To Use Local Web Service.

Activate Siebel Contact Inbound Web Service

In this document, the Siebel Contact ASI will be used as an example.

1. Activate the Siebel Contact ASI in the Administration - Web Services > Inbound Web Services view.
   
   
    
2. We will use binding SOAP_DOC_LITERAL (see below for examples of other bindings) :-
   
   

Generate Example SOAP Document

When invoking the Web Service Inbound Dispatcher directly, you will need to provide a correctly formed input SOAP document.  If you need to create one :-

1. For the Siebel Contact web service in the Administration - Web Services > Inbound Web Services view, click the Generate WSDL button, you may get a download popup asking where you want to save the file. You may want to change the FileName to a meaningful value such as SiebelContact.WSDL and save the file.
2. Import the wsdl to the web service tool (e.g. soapui) and cut/paste the example request doc

Invoke the Web Service Inbound Dispatcher 

Using the SOAP document, invoke the Web Service Inbound Dispatcher to call the Siebel Contact web service.

1. In the Business Service Simulator, set the Service Name and Method Name :-

   Service Name	Method Name
   Web Service Inbound Dispatcher	Dispatch

2. In the Input Arguments applet, provide a SOAP document in the Value field, an example is shown below (you should use encoding declarationUTF-16 for this test from the Business Service Simulator) :-
   http://schemas.xmlsoap.org/soap/envelope/

" xmlns:asi="http://siebel.com/asi/"> 1-W9D

Click the glyph on the Property Name, and provide the following Property information :-

Property Name	Property Value
TransportType	HTTP
SOAPAction	"document/http://siebel.com/asi/:SiebelContactQueryById"

Note : If unsure of the required soap action to set, check the wsdl for 'soapAction' and cut and paste.

Prior to invoking, the screen should look like :-



 

Invoke it, click Run :-

Other Bindings

For either SOAP_RPC_ENCODED or SOAP_RPC_LITERAL, you can also test with the Web Service Inbound Dispatcher.  For these, you should not set aSOAPAction property as for the SOAP_DOC_LITERAL example (but do setTransportType=HTTP).  You can generate sample SOAP requests as above (e.g. using soapui) after generating a wsdl from Siebel with the binding set as required.  Example SOAP structures are shown below :-

1. SOAP_RPC_ENCODED
   http://www.w3.org/2001/XMLSchema-instance

" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">http://schemas.xmlsoap.org/soap/encoding/">1-W9D

SOAP_RPC_LITERAL

http://schemas.xmlsoap.org/soap/envelope/

" xmlns:asi="http://siebel.com/asi/"> 1-W9D

Invoking Web Services on the Siebel Mobile Web Client

Invoking Web Services on the Siebel Mobile Web 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. This feature allows developers to integrate external applications with Siebel Business Applications and test their integrations, without having to install an entire Siebel Enterprise.

NOTE:  The functionality described in this topic is provided as ACR 492. For release 8.1 of Siebel Business Applications, implementing this functionality requires installing a patch release and performing postinstallation configuration tasks. For an ACR that is included in a Siebel Fix Pack 8.1.1.x release, see the relevant instructions in the applicable Siebel Maintenance Release Guide on My Oracle Support.

NOTE:  All information provided in this topic for the Siebel Mobile Web Client also applies to the Siebel Developer Web Client.

The Web service functionality is an extension of the Siebel Mobile Web Client, and runs as a separate siebel.exe process. This second siebel.exe process is started by the Siebel Mobile Web Client as its child process. The child process listens on the specified port for all Web service requests. The Web service requests are processed and sent to the EAI Inbound Dispatch Service, and then the response is sent back to the Siebel Mobile Web Client. The child process exits when the Siebel Mobile Web Client exits.

NOTE:  If any changes are made to Web services in the run time, then these will not be available to the child process. You must restart the Siebel Mobile Web Client; you cannot clear the Web services cache.

Exceptions to Web Service Support

The Siebel Mobile Web Client provides the same Web service support as an EAI-enabled Siebel Server, with the following exceptions:

• The Web service consumer, such as soapUI, must be on the same computer as the Siebel Mobile Web Client.
• HTTPS is not supported.
• The Stateless, Stateful, and ServerDetermine session types are not supported. Only the None session type is supported.
• Concurrent requests are not serviced in parallel. There is only one siebel.exe process that serves Web services, so concurrent requests are queued.
  NOTE:  When multiple Siebel Mobile Web Client instances are running, there will not be multiple processes serving Web services. However, if the port number is modified in the application configuration file, then with the next Siebel Mobile Web Client instance a new siebel.exe process will start and listen to requests on the new port specified in the configuration file.
• Anonymous Web service requests are not supported.
• Chunked HTTP requests and responses are not supported.

Supported Authentication Formats

User authentication is the same as for the Siebel Mobile Web Client. The following authentication formats are supported:

• Username and password in the URL
• Username and password inside the SOAP header
• Username and password inside the Web Services-Security (WS-Security) header

Application Formats That Are Not Supported

The following authentication formats are not supported:

• Single sign-on (SSO)
• Stateful Web services using separate login and logout requests
• Stateless Web services using a SessionToken

Enabling Web Services on the Siebel Mobile Web Client

Two new parameters have been added to the application configuration file to enable the Web service functionality: EnableWebServices and WebServicesPort.

To enable Web services on the Siebel Mobile Web Client

• Set the following parameters in the [Siebel] section of the application configuration file, such as uagent.cfg:

  Parameter	Value
  EnableWebServices	TRUE
  WebServicesPort	Port number on which to listen. The default is 2330.

The next time the Siebel Mobile Web Client starts, it will start the siebel.exe child process. After the process has started, it can send requests and receive responses.

Starting the siebel.exe Process From the Command Line

When it is not required to start a Siebel Mobile Web Client instance, you can start the siebel.exe process independently using the command line.

To start the siebel.exe process from the command line

• Enter the following command:
  SIEBEL_CLIENT_ROOT\bin\siebel.exe /l <language_code> /c <configuration_file> /u <username> /p <password> /d <datasource_in_cfg> /webservice <port_number>
  For example:
  C:\Siebel\80\client\bin\siebel.exe /l enu /c enu\uagent.cfg /u SADMIN /p SADMIN /d Sample /webservice 2330

NOTE:  To stop a siebel.exe process started from the command line, you must end the process from the Windows Task Manager.

Confirming that the siebel.exe Process is Listening

You can use the netstat utility from the DOS prompt to determine whether the siebel.exe child process is listening for Web service calls.

To confirm that the siebel.exe process is listening

1. From the DOS prompt, type the following:
   netstat -a -p TCP
2. Examine the output for the port number you set in the application configuration file, for example:
   TCP mycomputer:2330 mycomputer.mycompany.com:0 LISTENING
   LISTENING indicates that the siebel.exe process is listening for Web service calls.

Invoking Web Services on the Siebel Mobile Web Client

You can invoke Web services on the Siebel Mobile Web Client by passing credentials in the URL, in the SOAP header, or in the WS-Security header.

Example of Passing User Credentials in the URL

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&Username=<username>
&Password=<password>

For example:

http://localhost:2330?SWEExtSource=WebService&Username=<username>
&Password=<password>

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  

  

99-28B0A

  

Example of Passing User Credentials in the SOAP Header

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=WebService&WSSOAP=1

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  

SADMIN

SADMIN

None

  

  

99-28B0A

  

Example of Passing User Credentials in the WS-Security Header

The URL format is:

http://<host>:<port>?SWEExtSource=SecureWebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=SecureWebService&WSSOAP=1

The following is an example of a request:

  

SADMIN

SADMIN

  

  

04-LLSQ5

  

Publishing Inbound Web Services

Inbound Web Services

---

The Inbound Web Service allows an external system to call a Siebel published Web Service. You can publish a business service or a business process as a Web Service and generate a Web Service Definition Language (WSDL) file that an external system can import. The Inbound Web Services can only be published from Siebel C using SOAP-RPC binding.

Publishing Inbound Web Services

You can create and publish an inbound Web Service using the Inbound Web Services view, as illustrated in the following procedure. You can then use the new Inbound Web Service when generating a WSDL document.

To create a new Inbound Web Service record

From the application-level menu, choose View > Site Map > Web Services Administration> Inbound Web Services view.


In the Inbound Web Services list applet, create a new Inbound Web Services record.


Enter the namespace for your organization's Web Services in the Namespace column.


Enter the name of the inbound Web Service in the Name column.


Select Active or Inactive in the Status field.
NOTE:  If the Web Service is inactive, then the external applications cannot invoke the Web Service. If the status is changed, the server component running the inbound transport, such as HTTP, requires a restart for the change to take effect.


Enter a description of the Web Service in the Comment column.


Create a new inbound service port record in the Service Ports list applet.


Enter the name of the port in the Name column.


Pick the type of object published.
If the required type is not available, add a new type following Step c through Step f; otherwise, move to Step g.


Click New and select the implementation type (Business Service or Workflow).


Select the implementation name (the business service or workflow that implements the port type).


Enter a name for the new type in the Name field and click Save.


Click Pick in the Inbound Web Services Pick Applet to complete the process of adding a new Type.


Select the protocol or transport to publish the Web Service on.


Enter the URL or queue to publish the Web Service on.
NOTE:  When publishing over EAI MQSeries or EAI MSMQ, you cannot generate WSDL files.


The format to publish over EAI MQSeries or EAI MSMQ Server transports is:
mq://send receive service point name@policy name
msmq://queue name@queue machine name


The URL format to publish over HTTP is:
http://webserver/eai_lang/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&UserName=username&Password=password
Where:
lang is the default language of Object Manager to handle the request.
webserver is the machine name of the Siebel Web Server.
username is the Siebel user to execute the request.
password is the password of the Siebel user.
NOTE:  The Siebel application supports only one type of binding, SOAP_RPC, for each Inbound Web Service.


Enter a description of the Port in the Comment column.


In the Operations list applet, create a new operation record for the new service port you created in Step 4 and want to publish.
NOTE:  Only the operations created in this step will be published and usable by applications calling the Web Service. Other business service methods will not be available to external applications and can only be used for internal business service calls.


Enter the name of the Web Service operation.


Select the name of the business service method in the Business Service Method column to complete the process.
NOTE:  The Business Service Method column defaults to RunProcess if you have chosen Workflow Process in Step 4 as the Type for your Service Port.

Generating a WSDL File

Once you have created a new Inbound Web Service record you can generate a WSDL document, as described in the following procedure.

To generate a WSDL file

Choose the inbound Web Services you want to publish and click GenerateWSDL.
A WSDL file is generated that describes the Web Service.


Save the generated file.


Import the WSDL to the external system using one of the following utilities.------------
The following will be already defaulted into this field: http://[webserver]/eai_[lang]/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1 Change to the name of the web server and to the language. For example the value of this at my implementation is as such: http://daac3cs6/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1 Click the Finish button. You or your Siebel Administrator now need to ensure that the EAI component is up and running and the web server eapps.cfg file has an entry for the virtual directory eai_. This will ensure that the web server knows where to route the web service calls to. I am not going to go into this in detail. In the Siebel UI, navigate to Administration - Business Process, query for the workflow Test Contact Import and click the Activate button. Restart the Siebel server(s) as this needs to occur for the new Integration Object to work. Navigate to Administration - Web Services > Inbound Web Services and query for Name: Test Contact Import. This is the web service that we created. Click the Generate WSDL button and save the XML file to your PC. Now we are ready to test the process. We can use a free software called soapUI that can call the web service. Download soapUI and install it. Google "Download soapUI" and you will find the link as the first in the list. Open Soap-UI and select File > New soapUI Project, then in the new project window enter the following: Project Name: TestContactImport Initial WSDL/WADL: Browse for the WSDL you saved earlier and select this. Create Requests: Once created, expand the TestContactImport project and then expand the ImportContact interface and then expand the operation under this and then double click the Request properties icon. This will display the sample XML for the web service. It will have ? characters for all field values, remove the ? from all the fields and enter data into the First Name, Last Name and Person UId fields as such: Person UId: ABC123 First Name: John Last Name: Smith Now the address bar at the top of this window is the address of the web service. Verify that this is correct, if not edit this address. Then click the green arrow button at the top left of the window, this will invoke the web service passing the XML. The result will be displayed in the right hand pane of this window. Verify that the contact has been imported.

File attachments in web service calls

Siebel 7.7.2.10 and higher supports attachments encoded as base-64.
All you need is :

a) attachments properly working at the user interface as a pre-requisite
b) the integration object you use contains an attachment integration component.
c) You also need the 3rd party application communicating with siebel to be able to handle base-64 encoded attachments.

We do not have detailed and exact step by step procedure as this is mostly a design decision and as such is beyond scope of support.
I am glad to share ideas though and suggest the following exercise to gain insight:

1) Use the thin client.Query for an account or service request.
Add an attachment to it in the UI.
Ensure you can attach and download a file from the UI.if not, fix it first.

2) Use an integration object with the correct structure for attachments. 
Some siebel versions had issues with the siebel tools wizard when creating an IO with attachments so I suggest you try a standard one and once it works you can use it as a reference for other objects.
e.g: activate and compile Sample Account.
or use Service Request IO
(once this works you can just extend your own IO to have an attachment IC with the same fields)

3) Log in to thin client. 
Site map -> administration - Business service -> Simulator.
Simulate EAI Siebel Adapter, method Query and provide the input arguments:
OutputIntObjectName = Sample Account (or Service Request, or other of your choice).
PrimaryRowId = a valid row id for accounts, srs or the object you chose. This object must have an attachment.

4) once #3 works. scroll down to the lowermost applet. Click save to file.
This will save the output to file and now you have a sample message to play with and know what the attachment looks like in the XML. (SIEBEL MESSAGE at this point. not a SOAP.)

5) since the goal is to use webservices... once #3 is good, create a custom BS or a workflow that calls EAI Siebel Adapter with the specific IO you tested and publish it as a webservice.

6)To thest the web service you may want to downloadhttp://www.soapui.org. This is a free 3rd party tool. We do not offer support for it and have limited experience with it. You may find it usefull for simple tests though.
Import the siebel inbound web service WSDL to it.
Call the method query.
Give it a valid row id for a record that has an attachment and there you are !!! you have a sample SOAP message this time (item 3 gave you a sample Siebel message as opposed to SOAP)
The attachment should be in base-64

Edit the response message to call a different method e.g: insert and make sure the message has a new parent data (like a new account or a new SR).
Send it through SOAP UI and it should create a new record with the same attachment.

Now you know how to query and also how to insert.
Your last point of attention is :
 

The attachment is encoded as base-64 and there is not much we can do about it.. the 3rd party app has to be able to handle that.

Once you can get this simple example to work it should be feasible extend the idea to your existing web service.
Basically you just have to create an extra IC for attachments using a standard attachment IC as an example.

Unix Shell Script Commands

path to go to logs : cd cronlogs/2014.04.02(Current Date)

To check the interface jobs in the log file using the shell script name: ls -lrt shellscriptname* To check the Scheduler timing of the Shell script: crontab -l|grep -i Shellscript Name to login with crmdev : sudo su - crmdev Command to remove the Previous Instance running  : rm XYZ_outbound.run to know the current path : pwd Command to run the Interface: nohup `run.sh crm8/pa_renewal/code/ab_abc_abcd.sh &`

Volume Discount in Siebel

Volume Discount

Volume Discount is probably the easier discount to understand and to implement.The idea is to give a discount if you buy more of the same product. Example:

• If you buy 4 products ABC, you get 3%
• If you buy 5 products ABC, you get 3.5%
• If you buy more than 6 products ABC, you get 4%

You add product ABC to the Quote/Order, you update the Qty field to a value of 4 or greater and you will see your volume discount applied.

Now, there is something the bookshelf very vaguely mentions (see “Volume Discounts Across Line Items): the Volume Discount only works per Line Item in the Quote/Order. Not per product!!!

Example:

You add product ABC to your quote and specify a qty of 2.

Then you add product ABC again to your quote (maybe with a different size/color) and specify a qty of 3.

Your quote now contains 5 products ABC.

Common sense will tell you that you should get 3% discount since you’re buying 5 of the same product (Pricing Engine works with Product Row Id). But the Pricing Engine will evaluate the Volume Discount rule line item after line item. Therefore, you won’t get the discount at all.

If you want the pricing engine to consider all shirts in the quote before calculating the volume discount, you have to implement it in the Pricing workflows. This will be discussed in section: Aggregate Volume Discount.

Note: I will not discuss the differences between Simple and Tier volume discount as this is a no-brainer and the bookshelf is crystal-clear on this.

Finally, the Volume Discount must be linked to each individual product that qualifies for this discount. This is done in the Price List Line Item.

Alternatively, you can also link the Volume Discount to a Discount Matrix, although be careful with this option, make sure the Start/End Dates of the Discount Matrix and the Volume Discount are consistent. Also the Price Waterfall will not be able to show calculations of the Volume Discount, only its result (see my upcoming chapter on this wonderful Waterfall)

How will I know that a volume discount is available for a product?

It is important that your customers know that you are offering such a discount. Knowing that such a discount exist could lead to higher sales volumes.

Unfornately, the only way to know that such a discount exists is to first add a product to the quote and then look in the Discount Negociation Form Applet (Quote Screen > Pricing > Discount Negociation). Similar view exists in Orders and you can always expose these fields to other applets)

In this applet, you will see 3 fields:

• Current Volume Discount
• Next Volume Discount
• Upsell

The first 2 fields are self-explanatory. The Upsell field shows a message that you can customize with Siebel UMS. The message could be: Buy 2 more and get 3% Discount.

The “2” and the “3%” are dynamically generated, depending on the current qty of the product in the Quote/Order.

If you increase your quantity by 2 to get these 3% you may get a new message:

Buy 1 more and get 3.5% Discount.

Etc… until you’ve reached the highest possible Volume Discount segment as per your volume discount rule. At that point the Upsell field would be empty.

I’d like to add one recommendation here: I believe it is important that the existence of a Volume Discount must also be shown in the Product Catalog. Again, the idea is to convince the customer to buy your products. If you sell realms of paper, you get a better chance to sell them if you inform the customer of volume discount while he/she browses the Catalog.

To achieve this you have 2 options:

Option 1:

Expose the volume discount name in the Catalog Applet (there are 2 Catalog Applet to update). But this is not enough. You should also take into account that volume discount have Start and End dates:

• Create fields in the underlying Catalog BC (again there is 2 to update) to get those dates,
• Use a calc field that will show the Volume Discount name depending of whether it is active or not
• Expose this field in the 2 Catalog Applets.

Option 2:

If you want to go a little step further, you can also expose the Next Volume Discount and Upsell (so you can benefit from the Siebel UMS). This is possible since those fields are populated in the Buscomp by the Pricing PSP procedure)

But you need to be comfortable with the Siebel PSP architecture before you can play with this. My opinion is that from a Sales/Marketing point of view, showing the Volume Discount name is already a nice added value; showing more info doesn’t justify the extra man-days implied (unless your Product Catalog is segmented by language or geographical regions).

Note: If your Volume Discount is part of a Discount Matrix you will not be able to recommend it to the customer.

Discount Matrices in Siebel Pricing

In many industries, prices and price adjustments often depend on both the product that is being sold and other information relevant to the sale. Often, customer and market conditions affect the price for which a product is sold.

Discount matrices allow you to tailor prices and adjustments to specific customer and market segments. They allow you to create and manage prices and adjustments for products in conjunction with other customer and market factors. The discount matrix administrative framework allows pricing administrators to logically group factors that result in a price or adjustment, working in the Siebel client without changing the Siebel repository.

For example, a company that sells laptop computers can create a discount matrix that allows it to charge a different price for laptops based on customer account type and sales region. In this example, customer account type, product, and sales region are the criteria for the price or discount. Therefore, the columns of the matrix would be Product, Account Type, Sales Region, Adjustment Type, Adjustment Amount, and a few additional columns that will be covered later in this chapter. Each row of the matrix defines the price or discount that will be applied when a given product is sold to a given account type in a given sales region, as shown in Table 5.

Table 5. An Example of a Matrix Defining Discounts

Product	Account Type	Sales Region	Adjustment Type	Adjustment Amount
Laptop 2000	Platinum	Europe	% Discount	10
Laptop 2000	Gold	Europe	% Discount	5
Laptop 2000	Platinum	Asia	% Discount	11
Laptop 2000	Gold	Asia	% Discount	6

Discount matrices allow you to maintain all of this critical pricing information in a single matrix, instead of dispersing it across numerous Siebel views.

Discount matrices are recommended in cases where:

• There is a high volume of prices and adjustments.
• The criteria for prices and adjustments are known ahead of time and do not change frequently.

Because prices and adjustments are frequently stored in disparate applications, discount matrices:

• Support integration with SAP condition tables.
• Can be loaded using Enterprise Integration Manager (EIM) or Enterprise Application Integration (EAI) integration objects.
• Can be integrated with legacy applications using other XML-based integration technologies.