Short overview of some last week failing builds at our site ;)
Since a while ago it's possible to register proxy repositories in Nexus based on the Oracle Maven Repository.
To be able to proxy this repository you need to make use of an oracle account for the autenthication before you can download the artifact.
Let's check the logging to understand what it does (i can rephrase the logfile or just copy/paste it ;), when others google for it it will find the hit much easier)
[code language="xml"]
2016-11-11 15:17:54 INFO ...
Short overview of some last week failing builds at our site ;)
Since a while ago it's possible to register proxy repositories in Nexus based on the Oracle Maven Repository.
To be able to proxy this repository you need to make use of an oracle account for the autenthication before you can download the artifact.
Let's check the logging to understand what it does (i can rephrase the logfile or just copy/paste it ;), when others google for it it will find the hit much easier)
[code language="xml"]
2016-11-11 15:17:54 INFO ...
Short overview of some last week failing builds at our site ;)
Since a while ago it's possible to register proxy repositories in Nexus based on the Oracle Maven Repository.
To be able to proxy this repository you need to make use of an oracle account for the autenthication before you can download the artifact.
Let's check the logging to understand what it does (i can rephrase the logfile or just copy/paste it ;), when others google for it it will find the hit much easier)
[code language="xml"]
2016-11-11 15:17:54 INFO ...
Short overview of some last week failing builds at our site ;)
Since a while ago it's possible to register proxy repositories in Nexus based on the Oracle Maven Repository.
To be able to proxy this repository you need to make use of an oracle account for the autenthication before you can download the artifact.
Let's check the logging to understand what it does (i can rephrase the logfile or just copy/paste it ;), when others google for it it will find the hit much easier)
[code language="xml"]
2016-11-11 15:17:54 INFO ...
Short overview of some last week failing builds at our site ;)
Since a while ago it's possible to register proxy repositories in Nexus based on the Oracle Maven Repository.
To be able to proxy this repository you need to make use of an oracle account for the autenthication before you can download the artifact.
Let's check the logging to understand what it does (i can rephrase the logfile or just copy/paste it ;), when others google for it it will find the hit much easier)
[code language="xml"]
2016-11-11 15:17:54 INFO ...
In my current project i need to build some integration to a cobol application.
To generate the interface used from within bpel the cobol team supplies the copybook file which i can use in bpel to generate the xsd by use of the Native Format Builder.
Generating the xsd gave me the next error : ‘Unable to generate native format’.
Check the copybook file and check if the array element is defined as
[sourcecode language=”xml”]
15 POITEM OCCURS 3 TIMES.
[/sourcecode]
instead of
[sourcecode language=”xml”]
15 POITEM OCCURS 3.
[/sourcecode]
On the Oracle Forums someone had a question on how to construct your own fault message based on the fault-part of the wsdl element.
In this blog we will add several activities to the flow to constantly see the output which will be generated by the proxy service.
The flow we will be creating should be looking like this
For the business service i used the helloworld service and imported the wsdl resource and xsd.
To be able to ‘throw’ the custom soap fault from within the proxy service to the service caller i edited the same wsdl, and added the fault part to the wsdl with my own fault response.
Resources
wsdl
[sourcecode language=”xml”]
[/sourcecode]
xsd
[sourcecode language=”xml”]
[/sourcecode]
soapUI
We will be using soapUI to test the soap faults, and also check the http headers we receive back on the invokes of the proxy service.
Create a new project and add the wsdl of the deployed proxy service.
The happy flow
The service comes back with a ‘helloResponse’ and HTTP Response of 200
Error situation1
Change the endpoint of the business service to some non-existing endpoint. At this point we won’t add any error handling yet, just to see the response coming back from the Oracle Service Bus.
Oracle Service Bus generated a SOAP Fault and in the details part we will find extra info about in which part of the process it failed. For faultstring it will concat the values errorCode and reason.
The service comes back with a HTTP Response of 500, Internal Server Error.
Error situation2 with empty service error handler
Now we only added an empty service error handler to the process.
The response in soapUI will still look the same.
If we we test the proxy service from the testconsole we will get the next output.
The service fails, the error gets propogated to the service error handler, in here we do nothing with it, and it’s get propogated to the toplevel error handler, the system error handler.
Error situation3 with serivce error handler and reply success
Only thing we now are going to add is the ‘reply’ activity in the serivce error handler. First add the ‘Reply With Success’.
Now the response in soapUI will look like this
So the business service triggers a soap fault, we end up in the service error handler, and over here we ‘handle’ the soap fault and decide our self what to reply back to the ‘caller’. In this case we replied back with success.
So we receive HTTP Response code of 200, but no payload in the body.
Let’s try to send back a ‘helloResponse’ back from the service error handler.
Add the next replace replace . in variable body with expression, Replace Node contents
[sourcecode language=”xml”] Returning helloResponse from within the service error handler
[/sourcecode]
In this case we also end up in the service error handler, we construct the soap body, and add the helloResponse to it.
We still get a HTTP Response of 200 back.
This scenario we can use if you never want to reply back a soap fault to the caller. So we propogate all errors to the service error handler, and in here we decide what we’re going to do with it.
In case of no soap faults, we can construct our own helloResponse. So we’re actually transforming a soap fault to a business fault, reply it back on the output of the wsdl and the caller itself can decide what wants to do with it. Since the soap fault won’t be thrown back to him, he needs to check the body of the response to actually see if any error happened.
In this reply we only used some static message of ‘Returning helloResponse from within the service error handler’. At this point the context of the $fault is lost and the caller won’t know anything about the ‘real’ error.
If we still want to reply back any information about the fault context we can also enrich the response with values from the $fault.
for example :
[sourcecode language=”xml”] Returning helloResponse from within the service error handler, {concat($fault/ctx:errorCode/text(),’ – ‘, $fault/ctx:reason/text())}
[/sourcecode]
Error situation4 with service error handler and reply failure
The only situation which is left is the construction of the soap fault, and reply it back on the fault-element of the wsdl with the correct HTTP Response.
First only add the ‘Reply with Failure’ activity, to see what the response will be.
Again we end up in the service error handler, since we don’t do any handling of the error itself besides a reply with failure no soap fault will get propogated (neither the one generated by the service bus itself) either.
So we receive a normal empty soap body response, but with HTTP Response of 500, Interal Server Error.
The only thing what’s left is constructing the soap fault payload.
If you check the payload of the first error testcase we see the soap envelope with soap fault needs to look like this
[sourcecode language=”xml”] soapenv:Server BEA-380002: Not Found in here we will add our own soap fault response payload message
[/sourcecode]
The format of the replacement we will base on the ‘helloFaultResponse’ of our xsd and when we reply it back we apply to the interface of the wsdl, specifically to the fault-part of the invoke of hello-operation.
To show you a bit what is possible in constructing, the ‘helloFaultResponse’ is rather full of elements. It’s just to show you what’s possible with constructing the payload and how you can enrich it by making use of the $fault, $inbound, $outbound, etc.
The replace i used in the service error handler
[sourcecode language=”xml”] soapenv:Server {concat($fault/ctx:errorCode,’: ‘,$fault/ctx:reason)} {$fault/ctx:errorCode/text()} {$fault/ctx:reason/text()} {$fault/ctx:location/ctx:node/text()}{$fault/ctx:location/ctx:path/text()} {$inbound/ctx:service/ctx:operation/text()} {$inbound/ctx:transport/ctx:uri/text()} {$inbound/ctx:transport/ctx:request/tp:headers/http:Host/text()} {$copyBody}
[/sourcecode]
And the output in soapUI
I hope it’s a bit clear on how to handle the faults in the Oracle Service Bus. In my testcases i only added the logic to the service error handler. But we can also the the error handlers to the other locations like stages and routing activities. It depends on the logic you want to execute at which place you want to handle the error itself.
On the 20th July 2010 (Time: 10 a.m. PT/1 p.m. ET) Oracle will give a live Webcast on the launch of the new Oracle Service Bus 11g.
“Introducing Oracle Service Bus 11g—Extending Oracle SOA Suite Leadership”
Interesting for all of you who already use or will be using the new service bus.
Hopefully they will discuss all the nice new features.
Thanks to Manoj for this overview on how to run the osb and soa suite in one jvm.
My machine was almost dying when i wanted to run both the osb server and the soa suite server.
For development this solution is great and it will save you some resources.
After creating the domain and starting up the admin server i faced the next stacktrace and the adminserver won’t start up.
[sourcecode language=”java”]
#### <> <> <> <1276500520469> \user_projects\domains\soa_osb_domain\config\config.xml
[/sourcecode]
Find the named jms servers, and check the related filestore. They will have different targets. Fix them so they both target the soa_server1 and start the AdminServer again.
In this second part of the serie about communication between Oracle Service Bus and Composite Applications from the SOA Suite we will discuss the synchronous communication from the service bus to the composite application.
When developing composite applications, you could expose these services to the outside world to be used by customers. In these cases you could decide to make use of a service bus in front of the services to virtualize them.
Sync call from Oracle Service Bus to SOA Suite Composite
In this blog we will develop the next flow
Oracle SOA Suite Composite Application
In JDeveloper create a new SOA Application with an empty SOA Project in it.
For this blog i created a simple synchronous HelloWorld bpel process which will return the “Hello ” + the inputparameter string.
Direct Binding
To be able to invoke the bpel process we need to expose the service interface of the bpel process.
Drag the Direct Binding Service Adapter to the left swim lane.
For the service interface i will just re-use the wsdl of the bpel process.
In the first part of this serie we used ‘Reference’ type for the Direct Binding. In this case we want to invoke the composite from our Oracle Service Bus project, so we will be using the ‘Service’ Type.
And that’s pretty much it what is needed for the composite. The flow should look something like this
Deploy the application. If we lookup the process in the Enterprise Manager and select it we will see a overview of the next components in it
In the first part of the serie we used the Hello_PS_Direct with the ‘Reference’ usage for the DirectBinding and in this blog we will be using the ‘Service’ usage.
Oracle Service Bus
For the development of the Oracle Service Bus process we need a few components
Proxy Service
Business Service (invoking the bpel process)
Create a new OSB Configuration Project in Oracle Enterprise Pack for Eclipse.
Creata a new OSB Project.
Communication with the Oracle SOA Suite components will make use of the new SOA-DIRECT transport available in the Oracle Service Bus 11g.
The SOA-DIRECT transport provides native connectivity between the Oracle Service Bus and the Oracle SOA Suite service components.
The SOA-DIRECT transport supports wsdl type services with soap1.1 and soap1.2 or XML Bindings.
The SOA-DIRECT transport supports the following features: (copy/paste)
Invocation of any SOA binding component services through Java remote method invocation (RMI)
WS-Addressing, including optional auto-generation of ReplyTo properties for asynchronous callbacks
Identity propagation
Transaction propagation
Attachments
Optimized RMI transport for invoking SOA services
High availability and clustering support
Failover and load balancing (not available for services in the Service Callback role
Connection and application retries on errors
To be able to invoke the bpel service we will need the service endpoint.
In JDeveloper go to the ‘Application Server Navigator’. Select the soasuite applicationserver > SOA > soa_server1 > default > your composite name > name of your expose service interface. Right mouse click on it and select ‘Copy Path’.
If we look into the wsdl we will see it created two services for us (soap1.1 and soap1.2) with the t3 endpoint in it.
[sourcecode language=”xml”]
[/sourcecode]
In your Oracle Service Bus project (switch ide again), import the wsdl resource from the location we just copied. The import will create a wsdl + xsd from the bpel process for us.
Create a new Busines Service in this project and use the next settings.
We’ll be using a wsdl based business service, and for this interface we will use the wsdl we just imported.
By default the soa-direct transport is selected with the t3 endpoint of our bpel process (direct binding interface).
On the SOA-DIRECT Transport tab we can select some other settings. Since we will be invoking a synchronous bpel process the ‘Synchronous client’ option will do just fine and the rest isn’t needed.
JNDI Service Account – Configurat security credentials for the jndi lookup of the target soa service
Role – Synchronous Client/Asynchronous Client/Service Callback, depending on the service you invoke
Callback Proxy – needed for the Asynchronous Client, specify the proxyservice where to deliver the callback
Fault Proxy- needed for the Asynchronous Client, specify the proxyservice where to deliver the fault situations
WS-Addressing version, needed for Asynchronous Client, specify the version of WS-Addressing is provided in the request or proxy service pipeline
Dispatch Policy – Select the instance of Oracle WebLogic Server Work Manager that you want to use for the dispatch policy for this endpoint
From the business service generate the proxy service. This will be a SOAP over HTTP service based on the same wsdl of the business service.
We should end up with the next list of resources
Publish the Oracle Service Bus project to the server.
Test the proxy service and see if the outcome is correct
Request
Response
Go back to the Enterprise Manager console, and see if a new instance got created. Instance audit trail
The steps we need to communicate sync from the Oracle Service Bus with the Composite Application :
Create a composite application with Direct Binding Service Reference. Import the resources in your Oracle Service Bus project. Create a business services based on these ans use the SOA-DIRECT transport to communicate with the composite application.
In the other parts of this serie i will discuss the asynchronous flows between the Oracle Service Bus and the Composite Applications.
Deploy the service and test it to see if if the invocation works.
Oracle Servicebus components
Create a new OSB Configuration Project in Oracle Enterprise Pack for Eclipse.
Creata a new OSB Project.
Create a new Busines Service in this project and use the next settings.
Use the wsdl of the deployed MyHelloService. Easiest way to find this url is to go to the Console > Deployments > MyHelloServiceEAR > Testing > MyHelloServiceService > ?WSDL
Basicually we can use the default settings after browsing to the correct wsdl.
Create a new Proxy Service based on this Business Service
By default it will create a Proxy Service with HTTP Transport, change this to SB Transport. This will be used eventually when we invoke the service from our Composite Application.
We will have the next list of resources
proxy service
business service
imported helloworld wsdl
imported helloworld xsd
We’re ready with the Oracle Service part. Deploy the project.
Oracle SOA Suite Composite Application
In JDeveloper create a new SOA Application with an empty SOA Project in it.
Eventually we will be creating the next flow
First we need the effective wsdl of our Proxy Service. This we will be using for the Direct Binding reference from our composite to the Oracle Service Bus resource.
From Eclipse :
From OSB Console :
In the wsdl we’ll see the Binding- and the Service-parts. In the Service location we will see the sb:// endpoint of the Proxy Service.
[sourcecode language=”xml”]
[/sourcecode]
Direct Binding
Drag the Direct Binding Service Adapter on the swim lane
In this case we are invoking an osb resource, so we will be using ‘Reference’ as Type and ‘Oracle Service Bus’ as Reference Target.
For the WSDL URL browse to the location at which your exported and unpacked the Effect WSDL. Let the wizard copy the resource into the project and don’t maintain the original directory structure.
Mediator
Drag the Mediator component to the middle swim lane.
For the mediator interface i will use the same wsdl, to keep it simple.
Drag the left arrow of the mediator the to the left swim lane. Now we will have a soap endpoint to test against.
Drag the right arrow to the Direct Binding Service we created in the first step. Doubleclick the mediator to add the transformations.
The process should be done by now. Deploy the SOA Composite.
Go to the Enterprise Manager Console and test the application.
Click “Launch Message Flow Trace” to see what got executed.
In here we will see the Hello_PS_Direct of type ‘Direct Binding’ got executed.
To see if the invoke really triggered my OSB Resources i added tracing to the Proxy Service.
[sourcecode language=”xml”]
[OSB Tracing] Routing to SOADirectBinding/hello_bs with message context:
$body = Eric
[/sourcecode]
[sourcecode language=”xml”]
[OSB Tracing] The following variables are changed:
$body = Hello Eric
[/sourcecode]
The steps we need to communicate sync from the Composite Application with the Oracle Service Bus :
Create a proxy service with sb-transport in the Oracle Service Bus, use the effective wsdl from this service to create a reference service with the Direct Binding adapter and you’re ready to go.
The other steps needed are just the usual steps to create and implement the Composite Application and the resources in the Oracle Service Bus.
After reading a nice article about TimerManager functionality in Weblogic, i wanted to see how easy it would be to schedule my test composite application.
First deploy your composite and go to SOA > soa-infra > default > Test > WSDL.
Copy/paste the wsdl, this one we will use to generate the web proxy.
Back in JDeveloper create a new Application (or add it to an existing one), and create a new Web Project.
Select the jsp option, we will use this page later to trigger the scheduler.
Generating the Web Proxy
Right mouseclick on the Project > New > Business Tier > Web Services > Web Service Proxy
Fill in the url which we copy/pasted from the Test console of the composite application.
Fill in your package structure
We only have a synchronious service call
Here we have the option to apply any policies
This will generate all the code we need to invoke the composite application (wsdl).
The class with the name ending with ‘_ptClient’ contains all the code needed to do the invoke from java. This we will reuse later on.
For a little test, change the code so it calls the correct method of your composite application and check the console to see if it triggers a new instance.
Now we know for sure the proxy code itself is working, so we can go on with the code to schedule the invoke.
TimerManager
The code of the TimerManager i borrowed from this excellent blog.
Create both ‘TimerServlet’ servlet and the ‘TimerListener’ class, edit web.xml, and add link to the servlet to the index.jsp which we generated in one of the earlier steps.
Now copy/paste the example code of the ‘_ptClient’ class to the ‘TimerListener’ class, and select the method you want to call (in my case the ‘process’ method).
Deploy and Run
Add a new WAR File Deployment Profile to the project.
Right mouseclick on the Project > Deploy > MyTimerApp and either select to deploy right away to the Application Server or to a local WAR archive.
Go to the url of the index.jsp to trigger the scheduler, for example http://localhost:8001/MyBPELTimer-MyTimerClient-context-root/index.jsp
Console output
[sourcecode language=”java”]
inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:03 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()
inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:13 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()
inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:23 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()
[/sourcecode]
Overview of the Composite instances which were created
JDeveloper Project – It includes the generated code/imports against my own composite application. Regenerate the code against your own wsdl, and revalidate the code.
