Follow Us on Twitter

Oracle Adaptive Case Management – Exposing the API – part 2

by Roger Goossens on May 24, 2014 · 0 comments

In the previous blogpost we’ve built a custom java API on top of the ACM api. In this blogpost we’ll make a service of this API exposing its public methods and test it against a small test case.


The TestCase for this blogpost is also available on GitHub. It’s a small composite containing a simple case called TestCase.


We’ve got 2 milestones in the case, one called caseStarted, which is set after the case has started, and the other is called testUserEventFired signalling that the user event testUserEvent has been fired.


The only stakeholder for the case is called CustomStakeholder of which the user weblogic is a member.

User Events

We’ve defined a user event called testUserEvent. This is the event we’ll be firing via our exposed API later on.


The CustomStakeHolder Role has been added to the project with the weblogic user as its member.

Business Rules

The TestCase contains 2 business rules for setting milestones.

Conditions R1 R2
CaseEvent.userDefinedEvent.event “testUserEvent”
CaseEvent.lifecycleEvent.lifecycleEvent STARTED
call reach milestone v v
milestoneName “caseStarted” “testUserEventFired”
comments null null

The milestone testUserEventFired will hereby show that the testUserEvent has been fired proving that our custom API service has done its proper job.


We’re almost there. Now the only thing left, is the service for our custom acm api. We’ll add this service to our case project composite.


First we need to add the jar we’ve built in our previous blogpost to our TestCase project. The custom-acm-api.jar file needs to be added to the SCA-INF/lib directory for the composite to be able to use it. Also make sure to add this library to your project libraries (Project Properties > Libraries and classpath).

Spring Component

Now we can use this library for our AcmApiService. We’ll use a Spring Component for this so make sure you’ve installed the Spring extension in your JDeveloper installation. Insert a Spring Context component into the TestCase composite and call it acmApi-context. This Spring context will get the following content:

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns=""
       xsi:schemaLocation=" META-INF/weblogic-sca.xsd">
  <!--Spring Bean definitions go here-->
  <bean id="credentialService" name="credentialService"
  <jee:local-slsb id="caseService" jndi-name="ejb/bpm/case/CaseService"
  <jee:local-slsb id="bpmUserAuthenticationService"
  <bean id="acmApiBean" name="acmApiBean" class="nl.whitehorses.acm.AcmApi"
        destroy-method="destroy" init-method="init">
    <constructor-arg ref="credentialService"/>
    <property name="caseService" ref="caseService"/>
    <property name="bpmUserAuthenticationService"
  <sca:service name="AcmApiService" target="acmApiBean"

Now this is where all the magic happens. Let’s break it down and explain what happens here.
First 3 beans are declared that are dependency injected into the main bean acmAPIBean which is a Spring Bean based on our AcmApi class. As you might recall the AcmApi has dependencies on 3 services, the ICredentialService, IBPMUserAuthenticationService and the ICaseService. The first one is present in our library and is injected as just another Spring Bean. The last two are available as EJBs on the SOA server and can be injected as such via their respective JNDI names.
The sca:service element finally makes the main bean eligible for exposure as a SOAP service. The contract of this service is based on the IAcmApi interface.

SOAP Interface

Now that our Spring Context is there, we can generate a SOAP service on top of it. Just drag a wire from the acmApi-context to the Exposed Services lane in you composite, choose expose as Web Service and the IAcmApi.wsdl will be generated for you on which the AcmApiService SOAP service, that is added to your composite, will be based. At this point your composite should resemble the picture below.

TestCase somposite

TestCase somposite

Please note that the generated IAcmApi.wsdl is a bit ugly, so it’s advisable to put a Mediator on top of it to serve a wsdl adhering to your company standards.


Now that all the pieces are in place, let’s deploy the composite to our SOA server and test the little beasty (The SoapUI testproject is also included in the GitHub example).
First call the startCase operation of the TestCase service to start a case instance.

Starting the case

Starting the case

Next call the AcmApiService.raiseUserEvent operation with the case id you’ve gotten back in the previous call.

Raising the user event

Raising the user event

The last step is to look up the case in the case management UI. As you can clearly see in the picture, the user event testUserEvent has been fired and the case milestone testUserEvent fired has been set .

Case overview

Case overview



We’ve shown you in these 2 blogposts how relatively easy it is to expose the ACM api as a webservice. Now that the basics are there, you can expand the API by adding additional methods at will, and thereby exposing all the case functionality you need.

Oracle Adaptive Case Management - Exposing the API - part 2, 5.0 out of 5 based on 1 rating
VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

{ 0 comments… add one now }

Leave a Comment


Previous post:

Next post:

About Whitehorses
Company profile

Whitehorses website

Home page

Follow us
Blog post RSS
Comment RSS