Tag Archives: 11g

How to implement permissions on your activities with Oracle Adaptive Case Management ?

When our Oracle Adaptive Case Management project started we initially used the default permissions on the case (Public, Restricted) to make sure our activities where available to the correct BPM application roles. A complex authorization model of roles, with LDAP groups, with users to allow access to the activities, but also custom UI and human tasks.


An important concept of knowledge worker automation (on which off course our whole case is based) is that the users should not be locked into rigid BPM processes (and access constraints I would like to add) which the IT department came up with. So activities on one hand would be allowed access to by all internal knowledge workers anyway, because: “hey .. they are knowledge workers and know best, right ?”

The first exception

However for some exceptions we got the requirements to only allow a specific role to a specific activity. So what we did was adding a new permission for that role and made sure that the activity was only available for that role.

Screen Shot 2016-07-29 at 11.08.18

new permission for role Senior Employee

Screen Shot 2016-07-29 at 11.08.35

set the permission on the activity

And all was good, for a while …

Challenge accepted

This went pretty well for some time, until we ran into a new requirements which made us rethink our design:

  • We had the requirement that on a specific activity where currently only permRoleSeniorEmployee had access now, we had to add the role Medior Employee. Therefor the original design thought that all activities are available for all employees OR for just 1 specific role (senior) for quality assurance was no longer valid.

So we looked at our options :

  1. We allowed the application role Medior to the permRoleSenior permission for a quick win for now, but looking at our naming convention this would be a bit confusing in the long run. All other options below required a code change, build and deploy so we tried to be smart to prevent this from ever happening again.
  2. The activity sadly doesn’t have a multi-select (both 11g and 12.2.1) so it is not possible to select both permRoleSenior and permRoleMedior
  3. We could add a new permission like permRoleMediorAndSenior, but still limiting ourselves to the code base
  4. In future identical requirements we do not want to change the codebase of our ACM project and permissions should be able to change on runtime. So both option 2 and 3 are not smart in the long run.

Our “Best Practice”

We have long running cases (like, really long) and redeployment of a new version will not fix any new permissions requirements on running instances. However since we have 50+ activities in our case where most of them are (currently) allowed access to by all employee levels (the example here just uses 2, but in reality we have much more roles). So the idea of creating a separate permission for each activity was not appealing, we eventually decided that we just had to. So for each activity we created a unique permission and configured in on the activity.

Screen Shot 2016-07-29 at 11.41.15

new unique permission for the activity

Screen Shot 2016-07-29 at 11.41.20

set the permission on the activity


Scripted Configuration

Because know we have a LOT of permissions and roles we are gratefull for having a WLST script to make sure these are automatically configured through our environments. Scripts have some customization, but the main logic was found on the big WWW (sorry, not sure where and who to give credits).

So first we need a property file

# permActMyProcess2

And the WLST script

from java.util import Properties
from import FileInputStream
from import File
from import PortablePrincipal
from import PortablePermission
from import PrincipalType
import os, sys

PROPERTIES = sys.argv[1]

propInputStream = FileInputStream(PROPERTIES)
configProps = Properties()
print '... property',pmTotal

connect('weblogic', 'welcome1', 't3://myserver:7001')

print '============================='
print 'Granting permissions...'
print '============================='
print '... property',pmTotal
while (i <= int(pmTotal)) :


  jpsBean = ObjectName('')

  print 'INFO - Index:',str(i),'| Name:',pmPrincipalName,'| Target:',pmPermTarget,' |Action:',pmPermActions

  principal = PortablePrincipal(pmPrincipalClass, pmPrincipalName,PrincipalType.CUSTOM)
  params = [pmAppStripe, principal.toCompositeData(None)]
  sign = ["java.lang.String", ""]
  perms = mbs.invoke(jpsBean, "getPermissions", params, sign)

  permExists = false
  for perm in perms:
    p = PortablePermission.from(perm)
    if( and p.permissionClassName==pmPermClass and pmPermActions in p.actions):
      permExists = true
      print 'INFO - Permission',pmPermTarget,'(',pmPermActions,') already set for ',pmPrincipalName

      grantPermission(appStripe=''+pmAppStripe,principalClass=''+pmPrincipalClass,principalName=''+pmPrincipalName, permClass=''+pmPermClass, permTarget=''+pmPermTarget,permActions=''+pmPermActions)
      print 'INFO - Permission',pmPermTarget,'(',pmPermActions,') set for ',pmPrincipalName
      print 'ERROR - Failed adding permission ',pmPermTarget,'(',pmPermActions,') to',pmPrincipalName
      print sys.exc_info()

  i = i + 1


The longer we thought about this the more we think the current permission solution lacks some maintainability. It would (for instance) be nice if the BPM WorkSpace would allow some graphical interface where all activities could be easily connected to the (already their) BPM Application Roles. So hopefully in the near future ?

Leave a comment

Posted by on 29-07-2016 in BPM, Oracle


Tags: , , , , ,

Limitation in Oracle Adaptive Case Management (ACM) revision ID length

All our Oracle BPM projects use a revision id during deployment of the SCA component which is something like [4 digits].[svn-revision] which might look like 1602.71234

The Oracle SCA version format convention

In the Oracle documentation it states that the Oracle SCA composite revision must apply this format:
n0[.n1[.n2[.n3[.n4]]]][-milestone-name[milestone-number] | _patch-number]
Where all but “milestone-name” and “comment” are numeric, composed of one or more digits (0-9) from 0 up to a maximum value of 99999999.

This is the same convention you see on the error when deploying a composite with an incorrect revision format.


So we are good due to the fact that our revision naming standard only use n0.n1 and both numbers will not reach the max value of 99999999 anywhere soon.

The problem

However when testing we discovered that when our revision passed 99999 we have a problem. Not due to the normal SOA or BPM components, they can easily handle the longer n1 digits. But due to the fact that our Oracle ACM projects will throw the following error when deploying a composite with a total(!) revision length of 10+


: Case metadata deployment failed. 
Case metadata deployment failed for MyCase. 
Contact system administrator for assistance. 
at oracle.bpm.casemgmt.fabric.CaseManagementServiceEngine.deploy( 
at oracle.bpm.casemgmt.fabric.CaseManagementServiceEngine.deploy( 
at oracle.bpm.casemgmt.fabric.CaseManagementServiceEngine.deploy( 
Caused By: BPM-72806 
Caused By: javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.1.v20111018-r10243): org.eclipse.persistence.exceptions.DatabaseException 
Internal Exception: java.sql.SQLException: ORA-12899: value too large for column "SOA_SOAINFRA"."CM_CASE_DEFINITION"."COMPOSITE_VERSION" (actual: 12, maximum: 10)</pre>

So when checking the SOAINFRA database design we discovered that for ACM components the revision is also stored in a column with a definition of VARCHAR2(10)

Name Null Type
----------------- -------- --------------


The solution

So we logged a service request (SR 3-12014738981) and together with Oracle Support we concluded that this is actually a bug in both 11g and 12c.
Bug 22564283 – Limitation in ACM revision ID due to CM_CASE_DEFINITION.COMPOSITE_VERSION

Yesterday we received confirmation from Oracle Support that the bug is fixed and we will receive a patch.
Meanwhile we can already use the workaround to update COMPOSITE_VERSION column in CM_ACTIVITY_DEFINITION and CM_CASE_DEFINITION to VARCHAR2(200).
So actually an easy fix on the SOAINFRA schema we assumed would work if we “hacked” it in our self, but we’re still very glad that it was quickly handled and solved through Oracle Support with an official supported patch.

alter table CM_ACTIVITY_DEFINITION modify (COMPOSITE_VERSION varchar2(200))
alter table CM_CASE_DEFINITION modify (COMPOSITE_VERSION varchar2(200))

So, if you run into the same problem you can refer with Oracle Support to the SR and BUG numbers mentioned above

Leave a comment

Posted by on 17-02-2016 in Uncategorized


Tags: , , , ,

Oracle Service Bus 11g – Another session operation is in progress. Please retry later.

Since our Bamboo pipeline uses the same account for deployments we sometimes get this error “Another session operation is in progress. Please retry later.” during deployment.
So 1st of all, don’t use the same user (like weblogic) to deploy when your with a lot of developers / build pipelines / etc.
Time for us to use multiple users for each agent (or think of something else really smart), but in the meanwhile we sometimes have to discard the changes from an open session.

sbconsole -> View all Sessions -> Select session -> Discard all changes



However sometimes the sbconsole does not allow this action and we need to restart the Admin + Managed server.
Usually this fixes the issue, however this time it didn’t.

Luckily for us the great Pierluigi has a blog which tells us to clear the OSB domain session folder, so:

  • shutdown the Admin + Managed servers
  • clear all the SessionXXX folders in the ${DOMAIN_HOME}/osb/config/sessions
  • start the environment

The content of

[oracle@server sessions]$ ls -l
drwxr—–. 5 oracle oinstall 4096 Jan 13 13:22 SessionScript1452682586592
drwxr—–. 5 oracle oinstall 4096 Jan 13 13:22 SessionScript1452687725653
[oracle@server sessions]$ rm * -rf


Leave a comment

Posted by on 13-01-2016 in OSB


Tags: , ,