Dynamic Approval Group
Dynamic Approval Group
Author: [email protected]
Oracle Corporation
1. Introduction
Audience: This document is intended for technical consultants who implement approval rule
customization for Fusion Financial use cases.
Abbreviations:
1.0 Introduction
Fusion Financial Applications uses SOA 11g Components like BPEL, Mediator, HWF, AMX,
OBR to handle the Approval flows. Out of these technology stack components,
HWF/AMX/OBR together handles the routing, assignment and approval of various approval
tasks like Expense Report Approval, Invoice Approval etc. Out of the box, in Fusion Financial
Applications, the approvers can be fetched from HCM tables based on the Supervisory/Job
level hierarchy or it can be based on a Static Approval Group or it can be based on a hard
coded set of users by modifying approval rules on BPM Worklist DT@RT UI. If approvers
have to be fetched from different sources like below mentioned examples, those are not
supported by any of the out of the box sources given above. Hence we need alternate
mechanism to bring approvers from these wide varieties of sources into the approval list.
To meet these use cases, Dynamic Approval Group feature in HWF can be used in following
pattern and this involves additional coding and customization at customer end. From
Approval Rule, use Approval Group List builder type. Use a Dynamic approval group in that
approval rule. This dynamic approval group will have programming logic to fetch approvers
from required sources.
Approval Rule
Web Service
In the above chart, Dynamic Approval Group and Web Service have to be developed,
deployed and maintained by customers. Dynamic Approval Group is a simple java program
from which various approval list customization use cases can be met. But at the same time,
best practices have to be kept in mind during development – if used wrongly, it could
adversely affect performance. Hence below approach is recommended.
NOTE: Dynamic Approval Group is in turn an out of the box feature delivered by HWF. But
to use that, customers/consumers have to write java code as given on this white paper.
Hence this can be done on Fusion V1 GA, V1 RUP1, V1 RUP2 or even earlier releases since
SOA/HWF has been supporting Dynamic Approval group for a very long time now.
Dynamic Approval Group – Fusion Financials
Step 1: Create a New Application from Jdeveloper and a Generic Project as shown below.
NOTE: Ideally when such customization classes are created in customer instance, the package prefix should not
start with “oracle”. Hence customers should choose to use a different package prefix name. Refer Fusion
Applications Extensibility Guide.
Right click on Project -> Project Properties -> Libraries and Classpath.
In case if a file named “ADF Library Dependencies” gets created, select the file, choose Edit
-> Delete and remove that file.
Navigate to Project Properties again -> Business Components. Select “Initialize Project for
Business Components” and select ApplicationDB Data Source connection by entering
appropriate connect string.
NOTE: If jdev prompts for any secondary imports, just ignore and skip them.
Dynamic Approval Group – Fusion Financials
In this demo application, a custom table called SOA_EMP is used, from where employees
with IS_APPROVER set to “Y” will be used as approvers of the submitted document.
Assumption for this sample is that SOA_EMP table is present in fusion schema of fusion data
base.
Right click on the project -> New -> ADF Business Components -> Business Components
from Tables.
Dynamic Approval Group – Fusion Financials
This will connect to the Data base used for ApplicationDB connection to lookup tables and
create appropriate ADF business component objects. Query for tables and create Entity
Object, View Object and Application Module.
Dynamic Approval Group – Fusion Financials
Dynamic Approval Group – Fusion Financials
Right click on AM, select Run and make sure the created business components are working
fine.
Dynamic Approval Group – Fusion Financials
Write a custom method which would fetch users for approval list as per the requirement and
would return a list of usernames. Generate an AMImpl java file for the AM, wrap the
business logic in it and expose the method through the Service Interface.
Dynamic Approval Group – Fusion Financials
Dynamic Approval Group – Fusion Financials
Now let’s expose the above method through Service Interface to expose it as a web service.
Dynamic Approval Group – Fusion Financials
Dynamic Approval Group – Fusion Financials
Step 7: Change Data Source, Context Root and Test the service.
Since Fusion Apps uses ApplicationServiceDB data source connection for Web Services, the
data source JNDI name has to be updated. Also the project context root can be updated to
have more user-friendly path.
Expand Application resources -> Connections -> Data base. Create a new Data base
connection.
Dynamic Approval Group – Fusion Financials
Dynamic Approval Group – Fusion Financials
Open Application Module XML -> Navigate to Configurations section and select the Default
Configuration as <AMName>Service – the configuration with Type as SI. Plus edit the
<AMName>Service configuration and make that to use ApplicationServiceDBDS data source
JNDI.
Navigate to Project Properties -> Java EE Application -> Java EE Web Context Root. Change
the context root to small camel case of project name –
“dynamicApprovalGroupWebService”. Right click on ServiceImpl file and select run to run
the service in test mode on Integrated Web Logic Server.
Dynamic Approval Group – Fusion Financials
Define Business Component Service Interface Deployment Profile for service project and
Enterprise Archive Profile [EAR] for the Application, add the BC Deployment Profile to EAR
and finally deploy the EAR to a standalone web logic server.
Dynamic Approval Group – Fusion Financials
http://host:port/dynamicApprovalGroupWebService/DynamicApprovalGroupService
Dynamic Approval Group – Fusion Financials
NOTE: Fusion Apps Domain is secured with GPA. So a global policy like
“wss_saml_or_username_token_service_policy” might get applied to the deployed
service. Hence appropriate user name password has to be passed to the service in
end point tester WS-Security section.
Dynamic Approval Group – Fusion Financials
Create a new Generic project and add required libraries. Then create a new java program –
say “FintechDemoDynamicApprovalGroup” that implements
oracle.bpel.services.workflow.task.IDynamicApprovalGroup.
Dynamic Approval Group – Fusion Financials
Now create the JAX-WS Proxy to invoke the service that was created in Section 2.0 [Custom
Web Service to return Approvers] and get the response with list of approver ids.
Package: oracle.apps.financials.commonModules.approvalCustomization.proxy
Types: oracle.apps.financials.commonModules.approvalCustomization.proxy.types
Dynamic Approval Group – Fusion Financials
Since Fusion Applications uses Global policy sets for WS Security, no client policy has to be
applied. Client policy would be applied at runtime through GPA.
Dynamic Approval Group – Fusion Financials
Step 3: Invoke and process the service from client java code.
Below is a java code that invokes the service and prints the list of approver names. This
uses JAX-WS Proxy.
Dynamic Approval Group – Fusion Financials
getMembers is the mandatory method that’s implemented from the interface. This method
would invoke above getApprovers method, get the approvers, add them to a java.util.List as
mandated by Dynamic Approval Group schema and return the list.
There are two key advantages of this approach. First obvious is that approvers can be
fetched based on dynamic sources like web service, excel sheet, custom tables, pl-sql etc.
Second advantage is that the “task” object that is sent as a parameter to this getMembers
method would carry the list of payload attributes and its values that are exposed to
configure approval rules on DT@RT UI. These values can be derived in the DAG java code
and can be passed to the service to be used as foreign key and retrieve values from
tables/custom tables that Fusion Apps does not expose through DT@RT. It would be a good
Dynamic Approval Group – Fusion Financials
practice having this client java code as simple as possible – just simply invoke the service
with required parameters, get the list of usernames and add them to the List and return
from getMembers method. Details of few of the methods used in getMembers API is below.
NOTE: System.out.println can be used only during development and debugging purpose.
Don’t apply the code with System.out.println to a production system as it might have
negative impact on performance of the system.
Sample case: In this case, I would want to retrieve “Providing organization name” in this
client java program. I can do this by executing iterateNode code once to read the list of
attribute node names and use them along with below APIs to retrieve the node value.
String providerOrgName =
this.getProviderOrgName(task.getPayloadAsElement().getElementsByTagName("IntercoOrg
Name"));
Dynamic Approval Group – Fusion Financials
Every time a dynamic approval group is created or updated, it has to be applied to SOA
Server - oracle.soa.ext shared library and SOA Server has to be bounced. That’s why to
avoid a bounce on SOA Managed Server, we do not recommend adding too many business
logic in DAG Client Java program – instead business logic can be wrapped inside the Web
service which could be redeployed as and when the code in the web service is modified.
Navigate to Client Project Properties and create an ADF Library Jar Deployment Profile.
Right click on the project and deploy this ADF Library jar.
Dynamic Approval Group – Fusion Financials
BPM Worklist -> Administration -> Approval Groups -> Create Dynamic.
To refer this approval group in an approval rule, from here, navigate to Task Configuration -
> Data Driven tab and select FinFunTransactionApproval [choose one task of your
requirement]. Now Edit -> Modify the rule -> Save and Deploy the rule.
Dynamic Approval Group – Fusion Financials
Dynamic Approval Group – Fusion Financials
1 Do not have System.out.println on Java This would have negative impact on the
Code or Web Service code. system.
2 Error Handling: Add Logger statements This will make debugging simpler in
wherever required. Use appropriate log production instance to debug any issues
levels to report exceptions. SEVERE log with DAG Java code or the Web Service.
level is required when there are
exceptions. Handle the exceptions
gracefully.
Reference Document
3 Avoid making any JDBC Calls from This wouldn’t go through the App Server
Dynamic approval group java program. services like JDBC connection caching
and might impact performance of the
system.
4 Avoid using any custom classes or open This would require the additional classes
source classes in Dynamic approval to be available on class path of the SOA
group java program. server and might impact SOA server
startup. Hence it would be recommended
to use such classes in custom web
service code and add required jars to the
classpath.
5 As much as possible, have only the web Reason being, every change on DAG
service invocation logic and addition of code requires bounce on FIN SOA Server
users to the List logic in Dynamic after applying the jar to SOA Extension
Approval Group program. package. Hence do the business logic in
custom web service so that just
redeploying the web service is fine.
6 Handle duplicate users gracefully as per When there are duplicate users returned
the requirement by the DAG, Human task is going to
assign the task based on participant
type. Eg, when duplicate participants are
present on single/parallel participant
type, the user has to approve once. If it
is used on Serial participant type, then
the user might get multiple notifications.
Dynamic Approval Group – Fusion Financials
The END!!
Thank you!!