Oracle Adaptive Case Management – Exposing the API – part 2
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
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
Next call the AcmApiService.raiseUserEvent operation with the case id you’ve gotten back in the previous call.
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
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
Geen reacties
Geef jouw mening
Reactie plaatsenReactie toevoegen