OSB11g –Adding OWSM Policy to OSB from Eclipse in case OWSM store is not accessible

In case the Eclipse is not able to access OWSM to fetch the policies, then workaround would be manually add the security policy entries into the proxy file from backend by editing the .proxy file.

Eclipse generated Proxy Service

<xml-fragment xmlns:ser="http://www.bea.com/wli/sb/services" xmlns:tran="http://www.bea.com/wli/sb/transports" xmlns:env="http://www.bea.com/wli/config/env" xmlns:http="http://www.bea.com/wli/sb/transports/http" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:con="http://www.bea.com/wli/sb/pipeline/config" xmlns:con1="http://www.bea.com/wli/sb/stages/logging/config" xmlns:con2="http://www.bea.com/wli/sb/stages/config" xmlns:con3="http://www.bea.com/wli/sb/stages/routing/config" xmlns:con4="http://www.bea.com/wli/sb/stages/transform/config" >

  <ser:coreEntry isProxy="true" isEnabled="true">

<ser:binding type="SOAP" isSoap12="false" xsi:type="con:SoapBindingType" xmlns:con="http://www.bea.com/wli/sb/services/bindings/config">

      <con:wsdl ref="GeoDownload/WSDL/v1/GeoService"/>

      <con:binding>

        <con:name>GeoServiceBinding</con:name>

        <con:namespace>http://geo.com/wsdl/download/v1.0</con:namespace>

      </con:binding>

      <con:selector type="SOAP body"/>

    </ser:binding>

    <ser:monitoring isEnabled="false">

      <ser:aggregationInterval>10</ser:aggregationInterval>

      <ser:pipelineMonitoringLevel>Pipeline</ser:pipelineMonitoringLevel>

    </ser:monitoring>

    <ser:reporting>true</ser:reporting>

    <ser:logging isEnabled="true">

      <ser:logLevel>debug</ser:logLevel>

    </ser:logging>

    <ser:sla-alerting isEnabled="true">

      <ser:alertLevel>normal</ser:alertLevel>

    </ser:sla-alerting>

    <ser:pipeline-alerting isEnabled="true">

      <ser:alertLevel>normal</ser:alertLevel>

    </ser:pipeline-alerting>

    <ser:ws-policy>

      <ser:binding-mode>owsm-policy-bindings</ser:binding-mode>

    </ser:ws-policy>

  </ser:coreEntry>

Message Level Security Configuration

To add OWSM Security Policy to Proxy Service

Add the highlighted fields in yellow into the proxy file to add the Policy to the SOAP service proxy.

<xml-fragment xmlns:ser="http://www.bea.com/wli/sb/services" xmlns:tran="http://www.bea.com/wli/sb/transports" xmlns:env="http://www.bea.com/wli/config/env" xmlns:http="http://www.bea.com/wli/sb/transports/http" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:con="http://www.bea.com/wli/sb/pipeline/config" xmlns:con1="http://www.bea.com/wli/sb/stages/logging/config" xmlns:con2="http://www.bea.com/wli/sb/stages/config" xmlns:con3="http://www.bea.com/wli/sb/stages/routing/config" xmlns:con4="http://www.bea.com/wli/sb/stages/transform/config" xmlns:con5="http://www.bea.com/wli/sb/services/security/config">

  <ser:coreEntry isProxy="true" isEnabled="true">

     <ser:security>

      <con5:inboundWss processWssHeader="true"/>

    </ser:security>

<ser:binding type="SOAP" isSoap12="false" xsi:type="con:SoapBindingType" xmlns:con="http://www.bea.com/wli/sb/services/bindings/config">

      <con:wsdl ref="GeoDownload/WSDL/v1/GeoService"/>

      <con:binding>

        <con:name>GeoServiceBinding</con:name>

        <con:namespace> http://geo.com/wsdl/download/v1.0</con:namespace>

      </con:binding>

      <con:selector type="SOAP body"/>

    </ser:binding>

    <ser:monitoring isEnabled="false">

      <ser:aggregationInterval>10</ser:aggregationInterval>

      <ser:pipelineMonitoringLevel>Pipeline</ser:pipelineMonitoringLevel>

    </ser:monitoring>

    <ser:reporting>true</ser:reporting>

    <ser:logging isEnabled="true">

      <ser:logLevel>debug</ser:logLevel>

    </ser:logging>

    <ser:sla-alerting isEnabled="true">

      <ser:alertLevel>normal</ser:alertLevel>

    </ser:sla-alerting>

    <ser:pipeline-alerting isEnabled="true">

      <ser:alertLevel>normal</ser:alertLevel>

    </ser:pipeline-alerting>

    <ser:ws-policy>

      <ser:binding-mode>owsm-policy-bindings</ser:binding-mode>

     <ser:policies>

        <ser:service-policy>

          <ser:owsm-policy-ref ID="geo/security/GeoCustomAuth"/>

        </ser:service-policy>

      </ser:policies>

    </ser:ws-policy>

  </ser:coreEntry>

After editing the .proxy file reload the file in eclipse.

Modified Message Level Security Configuration

The ProcessWS-Security Header value will be set to Yes.

Check the Service Policy Configuration tab to see the Policy assigned to the Service.

That’s it.

Passing custom soap headers in Invoke activity -SOA 11g

I had created a custom SOAP header to be passed in with the request, so while testing the service invocation passing in the soap security header the invocation was failing as the header was not getting passed properly. There is an issue with BPEL generated code for assigning the SOAP header. So you will need to manually change the headerVariable name to get it working.

I have used SOA PS4 environment.

   <soapenv:Header>

<geosec:UserTokenHeader soapenv:mustUnderstand="1" xmlns: geosec ="http://geo.com/geo-security">

         < geosec:UserSessionToken>xxxxxxxxxxxxx</ geosec:UserSessionToken>

         < geosec:TokenUserName>geotho</ geosec:TokenUserName>

         < geosec:ConsumerSystemId>MySystem</ geosec:ConsumerSystemId>

      </ geosec:UserTokenHeader>

      </soapenv:Header>

Add a SOAP header using the invoke Headers tab.

BPEL generated code

                     <invoke name="invokeStartSOAPProcess"

                          partnerLink="StartSOAPProcessService"

                          portType="ns17: StartSOAPProcessServicePType"

                          operation="startSOAPProcess"

                          inputVariable="startSOAPProcessMsgVar"

                          outputVariable="startSOAPProcessResponseMsgVar"

                          bpelx:invokeAsDetail="no"

                          bpelx: headerVariable ="SecurityHeader"/>

Need to change the headerVariable to  inputHeaderVariable

  Working code

                  <invoke name="invokeStartSOAPProcess"

                          partnerLink="StartSOAPProcessService"

                          portType="ns17: StartSOAPProcessServicePType"

                          operation="startSOAPProcess"

                          inputVariable="startSOAPProcessMsgVar"

                          outputVariable="startSOAPProcessResponseMsgVar"

                          bpelx:invokeAsDetail="no"

                          bpelx:inputHeaderVariable="SecurityHeader"/>

Runtime invocation failing with .__OAUX_GENXSD_.TOP.XSD Error /duplicate elements in XSD

Recently I was working with BPEL process which had multiple service invocations and my job was to enhance it by adding some OSB invocations. When I started modifying the code for new service invocations and WSDL modifications, the process stopped compiling due to the .__OAUX_GENXSD_.TOP.XSD. It looked bit odd, one of the main issues was due to some shared XSD’s and some services had included the XSD’s some were importing it, some had different XSD implementations for same namespace. So after consolidating the entire included schemas and existing schemas the process started working.

The biemond blog was helpful. 

The problem I faced was when I starting testing, I had the location replaced at runtime and it started failing with the same .__OAUX_GENXSD_.TOP.XSD error. This was new to me as I thought it will be going through since all the wsdls will be looked up at compilation time. Each invocation will be different. But it isn’t so, so finally I had to tweak the abstract wsdl to make it concrete (by adding service tags) composite.xml and config plan for deployment.

Error stacktrace

Exception: Can not build schema 'http://geo.com/commons/schema/type' locate

d at 'http://geo.com/commons/schema/type.__OAUX_GENXSD_.TOP.XSD' [Cause=Can

not build schema 'http://geo.com/commons/schema/type' located at 'http://geo

.com/ commons/schema/type.__OAUX_GENXSD_.TOP.XSD']

Reference WSDL (named in location of composite.xml)

Add service tags in wsdl definitions and have a dummy address, which can be updated during deployment.

composite.xml

Add the the property endpointURI which will hold the runtime URI (without the ?wsdl)

Depoyment Plan(soa config plan)

In the deployment plan ,don’t update the location attribute to the runtime location, keep it your local wsdl.Update the endpointURI property to the environment specific URI.

Add separate search replace for the wsdl and update the location value to the environment specific URI

Environment is 11g PS4

Hope it helps

RESTful Services - OSB transport headers for passing HTTP header / custom values

            In one of my projects I was implementing the Gateway architecture, where I have grouped together all common activities and will route to the different project /modules, based on relative URI and needs to pass on the http headers.

There is a misconception that HTTP headers can only be passed if the backend Proxies are using transport protocol as HTTP and not local. This is not true, even in the case of local proxies the headers can be passed through. I am explaining how this can be done using the frontend and backend proxies and using local and HTTP transport protocols.

 This is how you fetch the values from header in front –end proxy and set in the outbound to the backend proxy

Transport Protocol -HTTP

This is how the values will be passed in $inbound

    <tran:headers xsi:type="http:HttpRequestHeaders" xmlns:tran="http://www.bea.com/wli/sb/transports">

        <tran:user-header name="http-method" value="GET"/>

        <tran:user-header name="query-string" value="name=George"/>

        <tran:user-header name="relative-URI" value=”Customer/GetCustomerDetails”/>

        <http:Content-Type>text/xml</http:Content-Type>

      </tran:headers>

Transport Protocol -Local

This is how the values will be passed in $inbound

<con:qualityOfService>best-effort</con:qualityOfService>

    <con:request xsi:type="loc:LocalRequestMetaData" xmlns:loc="http://www.bea.com/wli/sb/transports/local" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

      <tran:headers xsi:type="loc:LocalRequestHeaders" xmlns:tran="http://www.bea.com/wli/sb/transports">

        <tran:user-header name="http-method" value="GET"/>

        <tran:user-header name="query-string" value="name=George"/>

        <tran:user-header name="relative-URI" value=”Customer/GetCustomerDetails”/>

      </tran:headers>

Receiving proxy

-----------------------------------

The caller will embedd the values in the user-header name-value pairs.

The receiving proxy can retreive the values  from tp:user-header and pass in the required the name to fetch the corresponding values..The syntax is below.

$inbound/ctx:transport/ctx:request/tp:headers/tp:user-header[@name="relative-URI"]/@value

Similarly you can fetch all the header values in backend proxy.

That’s it from my desk J