Siebel 8 Local DB Encryption & Backend Access

 

Anyone who has worked on the Siebel version 8 flavours is bound to have run into problems with its new local db encryption feature. As a default setting, Siebel encrypts the local db with an RSA encryption key, which means the local db thus extracted, cannot be accessed via the backend. Tools and the locally installed client will continue to work, but if you need to actually debug data entry issues in the database, the system will just respond saying incorrect password.

Traditionally, there is a tool called dbisqlc, an executable present in the Tool\Bin folder, which is mean to access Sybase databases. I have used this tool numerous times in the past to debug data entry issues and run spooled SQL statements. But if your localdb is encrypted, you will need to provide some more inputs to dbisqlc so that it can open up the dbf file.

Thankfully, there are helpful documents on suppportweb here and here which explains everything in detail.

 

1. Determine the location of the local database that user wants to connect to and note down the full path of the database file for example %SIEBEL_CLIENT_ROOT%\local\sse_data.dbf.

2. Launch dbisqlc.exe from the %SIEBEL_CLIENT_ROOT%\bin directory to bring up the Connect to Adaptive Server Anywhere dialog. On the Login tab fill out the following fields.NOTE: The values for the User ID and Password have to be in upper case:

Field	Value
User ID	DBA
Password	<Enterprise Name> in ALL CAPITALS

NOTE: The default DBA password value is the enterprise name. If the enterprise name has less than 8 characters, the name is padded with consecutive digits 1234. For example:

o If the Enterprise Name is Siebel2005, then the DBA password is SIEBEL2005.

o If the Enterprise Name is Siebel, then the DBA password is SIEBEL12.

o

On the Database tab fill out the following field:

Field	Value
Database File	C:\Sea\local\sse_data.dbf

NOTE: Starting in Siebel version 8.0, you will need to run the following query to retrieve the encrypted value for the local database owner and enter this value on the Encryption Key field. 

SELECT PREF_CD, VAL FROM S_NODE_PREF s1, S_NODE s2 WHERE s1.PREF_CD ='RemLocSec:PlainKey' AND s1.NODE_ID = s2.ROW_ID AND s2.NAME='<mobile client name of the local database';

3. After clicking on the OK button, the user will connect to the local database. A message "Connected to database" should appear in the Statistics sub-window.

 

Knowing the DBA password for your local db can also be useful when the tables need to be extended.  Sometimes in Siebel tools, when you do an apply activate, the tools wizard goes into a hang and refuses to come out. I found that when I entered the userid as DBA and corresponding password generated as in the steps above, the tools system was able to complete the apply DDL step easily.

 

Also refer to this excellent post which explains how to reset forgotten passwords.

Java integration to Siebel Webservice

 

A few weeks back we had this requirement to have a Java client connect to our Siebel Webservice and do various operations. In this model, the Siebel side was the backend, and a Java applet was the frontend to the system. I setup the inbound Webservice in Siebel in no time, using ASIs. But the Java folks were having problems in setting up a connection to the system. They even said there were problems in the WSDL and Webservice, and that they were getting various parser errors on their side. Guess they were too dependent on eclipse, and they could not find an import WSDL feature on it !!

Truth is, Java is one of those languages which understands webservices very well, and if properly used, could make the integration work easiest to implement. You don’ have to build the SOAP request by hand (though, that is one option) as is done in some scripting languages. You just have to figure out how to generate the stub file, or the necessary class files into the system.

Now there are two ways to import a WSDL into a  Java system, you would use the WSDLtoJava.bat file if you are using the apache axis framework. This is when a Java servlet on Tomcat/Apache is talking to another server. I preferred the easier way to using the wsimport command as this is a simple client talking to a Siebel server. I will be using the Service Request ASI WSDL from a previous post.

You need to have the Java SDK installed and the paths properly configured on your system. Open up a command prompt window and type in  “java  -version” or “javac” to see if the paths have been added correctly.

Go ahead and import the wsdl using the command wsimport SR_WSDL.wsdl. Here I am running the command from the root of C: drive. You will see the importer at work generating class files.

You can ignore any warnings you see as long as you don’t get any errors. wsimport would have created a nested folder structure with multiple class files. Here the path created is C:\com\siebel\xml\sm_servicerequest.

Now its time to start writing your main java file which will make an instance of these class files and trigger the integration to siebel. You will have to know which class represents the webservice, here it is SMServiceRequestWS_Service.class. You can also generate the actual java files to see how the class and methods under them have been defined. Inorder to do this, use the command wsimport –keep.

This time wsimport will create the java files for each class file.

Back to our main java file. Import the generated class files using:

import com.siebel.xml.sm_servicerequest.*;

As can be seen, this string is actually the path of the generated class files. This is what my final Client.java file looked like :

///////////////////////////////////////////////////////////////////////////////////////////////////////////////

import com.siebel.xml.sm_servicerequest.*;

import java.io.Writer;

//the above namespace is from the generated code from the wsdl.

public class Client

{

static SMServiceRequestWS_Service service = new SMServiceRequestWS_Service();

public static void main(String[] args)

{

try

{

Client client = new Client();

client.doTest(args);

}

catch(Exception e)

{

e.printStackTrace();

}

}

public void doTest(String[] args)

{

try

{

SMServiceRequestWS pm = service.getSMServiceRequestWS();

// Building the Request hierachy

QueryPageSRInput req = new QueryPageSRInput();

req.setPageSize("10");

req.setViewMode("All");

req.setStartRowNum("0");

ListOfSmServicerequest list = new ListOfSmServicerequest();

ServiceRequest SR =new ServiceRequest();

list.getServiceRequest().add(SR);

req.setListOfSmServicerequest(list);

// Variable to store Response hierarchy

QueryPageSROutput res = new QueryPageSROutput();

// Invoke the service

System.out.println("Invoking the Webservice ");

res =pm.queryPageSR(req);

System.out.println(res.getLastPage());

for (int i = 0; i < res.getListOfSmServicerequest().getServiceRequest().size(); i++)

{

System.out.print(res.getListOfSmServicerequest().getServiceRequest().get(i).getStatus() + "\t");

System.out.print(res.getListOfSmServicerequest().getServiceRequest().get(i).getSRNumber() + "\t");

System.out.println(res.getListOfSmServicerequest().getServiceRequest().get(i).getOwner());

}

}

catch(Exception e)

{

e.printStackTrace();

}

}

}

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

All the information you need to build up the request and parse out the response is in the .java files created by wsimport. As can be seen, the final code does not have any variables for the URL,namespace or SOAPAction. These details are taken care of in the .java files.

Time to compile and run the Client.java file. Commands are:

javac Client.java

java Client

The client instance should connect to the Siebel Webservice now :

This code runs a  Query and prints out the Service Request Status, RowId and Owner details.

That’s it !! This is all you need to have a java client invoking a Siebel Webservice.