Advertisements
RSS

Tag Archives: Siebel

OSB Xquery function DateTime conversion

17 Mar

>Yesterday at the Oracle SOA and E2.0 Partner Community Forum in Utrecht I had a good talk with Edwin, Guido and Eric about OSB and one of the topics was our experience with Xquery functions in the OSB. So I mentioned some examples I used in the past and decided to post them on my blog when I had the time.

So here is one to start.

First we declare a nice namespace for our function ‘library’ in the top of our XQuery file.

declare namespace funcRBX = "http://www.rubix.nl";

Then we create our function, the following example is used for altering the format of Date and Time values to the specific format that Siebel expects. The code should be clear enough I hope with the comments in them. This is off course just one of the possible ways to do it and contains some specific environment checks I had to use. For instance this function was also used when the source is not XML but files (the old BEA MFL way of working) where day and month could have a value of 00 and we had to alter this to 01 as a business requirement.

declare function funcRBX:siebelDateTime ( $inputDate as xs:string?, $inputTime as xs:string?) as xs:string
{
 if (($inputDate = "" or empty($inputDate)) and ($inputTime = "" or empty($inputTime)))     (: no input :)
 then ""
 else if ($inputTime = "" or empty($inputTime)) then              (: only inputDate received :)
  concat(
  if (substring(data($inputDate),5,2) = "00") then ("01") else substring(data($inputDate),5,2)  (: check if day is not 00 :)
  ,"/",if (substring(data($inputDate),7,2) = "00") then ("01") else substring(data($inputDate),7,2) (: check if month is not 00 :)
  ,"/",substring(data($inputDate),1,4))
 else if ($inputDate = "" or empty($inputDate)) then              (: only inputTime received :)
  concat(
  substring(data($inputTime),1,2)
        ,":",substring(data($inputTime),3,4)
        ,":00")
 else                          (: both inputDate and inputTime received :)
  concat(
  if (substring(data($inputDate),5,2) = "00") then ("01") else substring(data($inputDate),5,2)  (: check if day is not 00 :)
        ,"/",if (substring(data($inputDate),7,2) = "00") then ("01") else substring(data($inputDate),7,2) (: check if month is not 00 :)
        ,"/",substring(data($inputDate),1,4)
        ," ",substring(data($inputTime),1,2)
        ,":",substring(data($inputTime),3,4)
        ,":00")
 };

And then down in the XQuery mapping you can call your function like this:

{
 funcRBX:siebelDateTime($someInputDate)
}

Due to the the fact that the input parameters are optional (the ? character after the declaration) you can leave the second input for time out or use ” as input.

Advertisements
 
5 Comments

Posted by on 17-03-2011 in Oracle, OSB, Siebel, XQuery

 

Tags: , , ,

Oracle Service Bus and Siebel UserNameToken

01 Apr

In this case we need to publish messages from the OSB 10.3.1 to Siebel 8.1.1.2 where Siebel supports different options for authentication of incoming HTTP webservice requests.

  • passing the user name and password in the URL (basic authentication)
  • A sort of custom Siebel Soap Header token like:
<soap:Header>
     <UsernameToken xmlns="http://siebel.com/webservices">user</UsernameToken>
     <PasswordText xmlns="http://siebel.com/webservices">hello123</PasswordText>
     <SessionType xmlns="http://siebel.com/webservices">None</SessionType>
</soap:Header>
  • And last but not least; Siebel claims to support the WS-Security UserName Token mechanism. However Siebel only supports the PasswordText option so the password will still be send in clear text.

We concluded that the URL or the custom header option was not acceptable due to the customers security requirements. The only acceptable solution for them would be the WS-security UsernameToken. Within the OSB this can be arranged by using a WS-policy and a Service Account and connect them to the outgoing business service. Since the password will still be in cleartext, we will use SSL to protect the password on it’s journey over the dark trenches of our WAN.

So here we start off:

1st the Siebel configuration for inbound services. Make sure the authentication type is set to username/password clear text.


2nd the WS-policy used (very basic):


<wsp:Policy wsu:Id="WS-Policy-Siebel"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <wssp:Identity xmlns:wssp="http://www.bea.com/wls90/security/policy">
    <wssp:SupportedTokens>
      <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken">
        <wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"/>
      </wssp:SecurityToken>
    </wssp:SupportedTokens>
  </wssp:Identity>
</wsp:Policy>

Attach the policy to the OSB business service together with the service account and go !!! 
With tcpmon we catch the SOAP-header and it looks like:

<soapenv:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
    <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="unt_hzo9Xh2IiCqSYGaH">
      <wsse:Username>SADMIN</wsse:Username>
      <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SADMIN</wsse:Password>
    </wsse:UsernameToken>
  </wsse:Security>
</soapenv:Header>

Bummer, we get our 1st error. Well let’s say that good things always take some extra effort.
The error response from Siebel:
<Body>
  <Fault>
    <faultcode>SOAP-ENV:MustUnderstand</faultcode>
    <faultstring>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</faultstring>
      <detail>
          <siebelf:siebdetail xmlns:siebelf="http://www.siebel.com/ws/fault">
          <siebelf:logfilename>EAIObjMgr_nld_0014_14680077.log</siebelf:logfilename>
          <siebelf:errorstack>
          <siebelf:error>
          <siebelf:errorcode>SBL-EAI-08000</siebelf:errorcode>
          <siebelf:errorsymbol/>
          <siebelf:errormsg>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</siebelf:errormsg>
          </siebelf:error>
          </siebelf:errorstack>
          </siebelf:siebdetail>
      </detail>
    </Fault>
</Body>

The error might let you think that Siebel simply fails on the mustUnderstand attribute which would force it to understand the SOAP header. However this is not the whole case.

After some debugging and using the Assign action in the OSB to manually build the SOAP-header with the WS-security definition it was possible to send out a UserName token Siebel accepted.

After this my conclusion is that Siebel apparently expects another wsse namespace then the OSB is generating.

Siebel requires the old wsse IBM/Microsoft/VeriSign definition of “http://schemas.xmlsoap.org/ws/2002/04/secext&#8221; while the OSB uses the newer namespace “http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&#8221; which was changed to match the OASIS specifications after their approval of WS-security as a standard in 2004.

After contact with Oracle Support I received confirmation from the Siebel Team that this is a limitation from Siebel, as it is not accepting the latest WS-Security definition. The option they give you is that for now it’s the caller’s responsibility to change the header to conform to the namespace Siebel is expecting.

So a new challenge for the OSB. The project looks something like this:

The solution for it is the fn-bea:lookupBasicCredentials function. We use an Assign Action to get the expression
fn-bea:lookupBasicCredentials(‘myRubixProject/security/SA.Siebel.MyRubixProject’)
result in a variable named $varBasicCredentials with the following content:

<con:UsernamePasswordCredential xmlns:con="http://www.bea.com/wli/sb/services/security/config">
  <con:username>SADMIN</con:username>
  <con:password>SADMIN</con:password>
 </con:UsernamePasswordCredential></pre>
We edit the Replace action to use the username and password elements.
<pre class="brush: xml"><soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" soapenv:mustUnderstand="1">
   <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsse:Username>{$varBasicCredentials/con:username/text()}</wsse:Username>
     <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{$varBasicCredentials/con:password/text()}</wsse:Password>
    </wsse:UsernameToken>
   </wsse:Security>
 </soapenv:Header>

Don’t forget to add the con namespace to the Replace action.

Finally, succes at last !!! :)
Off course this is just a workaround to make sure that Siebel and OSB speak te same “namespace language”. Let’s hope that Siebel 11g fixes this. After all, when it runs on Weblogic it must be good ;-)

Special thanks to Anuj Dwivedi for pointing me out the posibilities of the  fn-bea:lookupBasicCredentials function

 
Leave a comment

Posted by on 01-04-2010 in Oracle, OSB, Siebel, WS-Security, XQuery

 

Tags: , , ,