icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij Integration & Application Talents
Blog 24/05/2014

Oracle Adaptive Case Management – Exposing the API – part 2

Exposing

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.

TestCase

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

Milestones

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

Stakeholders

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.

Organization

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.eventType LIFECYCLE_EVENT USER_DEFINED_EVENT
CaseEvent.userDefinedEvent.event “testUserEvent”
CaseEvent.lifecycleEvent.lifecycleEvent STARTED
Actions    
call reach milestone v v
milestoneName “caseStarted” “testUserEventFired”
comments null null

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

AcmApiService

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.

Library

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="http://www.springframework.org/schema/beans"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd http://www.springframework.org/schema/tool http://www.springframework.org/schema/tool/spring-tool-2.5.xsd http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd">
  <!--Spring Bean definitions go here-->
  <bean id="credentialService" name="credentialService"
        class="nl.whitehorses.acm.security.CredentialService"/>
  <jee:local-slsb id="caseService" jndi-name="ejb/bpm/case/CaseService"
                  business-interface="oracle.bpm.casemgmt.ICaseService"/>
  <jee:local-slsb id="bpmUserAuthenticationService"
                  jndi-name="ejb/bpm/services/BPMUserAuthenticationServiceBean"
                  business-interface="oracle.bpm.services.authentication.IBPMUserAuthenticationService"/>
  <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"
              ref="bpmUserAuthenticationService"/>
  </bean>
  <sca:service name="AcmApiService" target="acmApiBean"
               type="nl.whitehorses.acm.IAcmApi"/>
</beans>

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 Serviceslane in you composite, choose expose as Web Service and the IAcmApi.wsdlwill 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.

Testing

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

Conclusion

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.

Overzicht blogs

Ook interessant?

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.

Geen HTML

  • Geen HTML toegestaan.
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.

Wil je deel uitmaken van een groep gedreven en ambitieuze experts? Stuur ons jouw cv!