Sometimes the default XSLT-mapper in the SOA Suite just is not enough. You want a little bit more or you want something that is re-usable for other components. The answer lies in writing your own XPath function. The first thing we need is to create a jar file which contains our functionality. Say we want a function which creates a displayname based on a few parameters. We will use Maven Continue ReadingCreating a custom XPath function for the XSLT mapper in the SOA Suite
This is a very short post on how you can test your webservices build in the OSB or SOA Suite. We are going to use SoapUI for our tests, Maven for our build process, SVN as our repository and Jenkins as our Continuous Integration server. First we need a service which we want to test. Lets use a very simple Hello service. All this service does is greet the user. Continue ReadingUsing Jenkins to test your OSB/SOA Suite services
In a first post over security I explained how to authenticate a user using ws-security for a webservice in the SOA Suite 11G. Previously we create a user Hugo which was a member of the Test-group. We now want to secure the webservice so that only members of this group can access it. How do we do this?
When you build a component which has an exposed service, you want to make sure that it is secure. This means we have to apply authentication and authorization to the service in question. Lets see how we can get this done in the SOA Suite 11G (PS2).
We where trying to connect from BPEL to a HTTPS service but we ran into SSL problems. After checking all the keystores and it’s locations, it still didn’t seem to pick our keystore up. The error we found in the log looked like this: Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
When you create a database poller in the SOA Suite you will encounter that empty values in the database will appear in your request as xsi:nil=”true”. When calling another service with values like: <sch:voorvoegsel xsi:nil="true"/> you will run into validation problems so you want to remove those elements.
When you are building a composite using the SOA Suite you quite often want to call an external webservice. These services can have a form of security on them….wss-username-token in our example. To attach the policy to the service in the SOA Suite is quite straight forward.