Naming Conventions - part 3

ADF Namings Conventions – Part III

Hi all,

In my previous post ADF Namings Conventions – Part II I have focused my attention on:

  • Model & View Controller Project

Today I will focus on:

  • Task Flows
  • Templates
  • JAVA Events
  • JAR, WAR, EAR files


Task Flows

In this section we will provide the namings related with task flows.


Task Flow Namings


The name for Task Flows should be defined as follows:


Example: myTaskFlowTF

We may have different task flows types, each one built to address one purpose. For these cases we added a constant to the name in order to easily recognize their purpose/target. Next table presents the Types and Target Names:

Type Task Flow Target Name
 Task Flow to filter data  <TASK_FLOW_CAMEL_CASE> + Filter + TF
 Task Flow to perform actions on data <TASK_FLOW_CAMEL_CASE> + Action + TF
 Task Flow to list data <TASK_FLOW_CAMEL_CASE> + List + TF
 Task Flow to detail data <TASK_FLOW_CAMEL_CASE> + Detail + TF
 Task Flow to combine multiple task flows <TASK_FLOW_CAMEL_CASE> + Container + TF


Task Flow Managed Beans


Task Flows’ managed beans are responsible for managing data. Multiple managed beans can be created for a single Task Flow. Nevertheless you usually have one main managed bean. For these cases managed beans should have a similar name as the task flow.

As you may have already noticed, you are free to provide any name you want to the Java Class you assign to your managed bean in “Managed Beans” task flow’s tab. For this scenario we recommend to use the same name of the Java Class.

By following this two advises you will be able to find what you are looking more easily without losing time and effort to understand the mappings made by each developer. This is very important for developers during development and maintenance phases. Based on these assumptions take a look on the following example:

 Task Flow Name:  myTaskFlowTF
 Java Class Name:  MyTaskFlow
 Managed Bean Name:  MyTaskFlow


Task Flow Input & Return Parameters


Task flow’s input parameters should be prefixed with “in”:


Example: inMyParameter

Task flow’s return parameters should be prefixed with “rtn”:

rtn + <CAMEL_CASE>

Example: rtnMyParameter



ADF lets us to create different types of templates to abstract common functionalities used in our projects, for example: Page Templates and Task Flow Templates. This templates should be created using the following pattern:

<CAMEL_CASE> + Template

Example: myTaskFlowTemplate, myPageTemplate



Pages names should have a self-explanatory name in order to be easily identified and recognized with its purpose. The default pattern we followed was:



In Task Flows you may have multiple pages depending on the route it takes, but for the main page (if we have one) we should provide it with the same name as the task flow but without ‘TF’ suffix.


 Task Flow Name: myFinantialTasksListTF
 Page Name: myFinantialTasksList


Java Events Namings

For our controls events we set suffixes for them. This will help you to understand the event type you are taking care without the need to go directly to the page, only if you need to understand it in more detail. The list of suffixes for each type of event are listed in the following table:

Event Type Suffix
 Action Event Action
 Value Change Listener VCL
 Selection Event Listener SEL
 Client Event Listener CEL
 Return Event Listener REL
 Action Event Listener AEL



Building and deploying projects lead us to create deployment profiles. In this deployments profiles you should use the same namings. The next table addresses this topic by providing the namings for each type of deployment profile.

File Type Prefix
 ADF JAR Library adflib + <PROJECT_NAME> + <MODULE_NAME>
 Shared Library sharedlib + <PROJECT_NAME> + <MODULE_NAME>


You can find the PDF with these series of posts right here.

I hope these series of posts may help you in your projects 🙂



Pedro Gabriel


This is a cross post with LinkConsulting. For more Oracle Middleware related posts, please visit

Post Header photo by Geoffrey Fairchild

Case Management using PCS

Case Management Patterns using Oracle Process Cloud Service

Hi and welcome to a new article on Oracle Process Cloud Service (PCS).

This time, we’re going to address some use patterns that may seem difficult to implement using PCS, and tackle the need for unstructured parts of the process, which is to say, parts of the process that can’t be previously modelled because, well… we don’t know how they’ll turn out.

Take for instance a complaint to your customer service department. You’ll never know, in advance, what kind of complain it will be, or if you need one, two, five or fifty interactions with the customer, or if you need to get approval from department A or B to try and compensate the customer, or even if any legal action will be needed with a supplier of yours, after they failed to compensate the complainer in due time.

So, you see, there are some elements that may render part of your process impossible to predict, at least in terms of activity sequence. You know that these may take place at some point in time in the process, but you can’t plan ahead and model the exact activity sequence (“A” will happen after “B”).

To handle this type of less structured processes (I don’t like the term “Unstructured”, because they have a structure), there’s a discipline called “Case Management” (CM). CM handles the choreography of this type of processes, called Cases, guaranteeing that the activities that are part of the process are executed at the right time and when conditions permit it.

For the remainder of the article, please consider the terms “Case” and “Process” as interchangeable, the term “Less structured Process” as equivalent to Case, and the term “Structured Process” as equivalent to a predefined flow-controlled Process (BPMN process or equivalent).

The main idea behind CM is that instead of the process model determining the next action to be taken, it’s the worker who, actually decides what should be the next best action to perform in each situation, using his experience.

This is not to say that the worker can just do any activity at any time. Typically, there are specific business rules that enable or disable a given activity based on the current data and events associated with a specific process. However, these rules can be as tight or as flexible as we may need.

Case Management Patterns

The idea of the article is to give you the tools you need to implement Case Management patterns using Oracle PCS. This is not to implement Case Management in PCS, but just some case management behavioral patterns. Parts of what is “Case Management” will not be addressed in any way, but things like Ad-hoc process/task calls will, and this is sufficient for most needs.

Short Summary of Case Management Modelling Notation (CMMN)

Just as we have BPMN as a standard way to model structured business processes, OMG (Object Management Group) also defined a standard to model Cases, called Case Management Modelling Notation, or CMMN.

In a short summary, the most meaningful objects are:

  • Case – It’s our main object process all other objects are inside this one.
  • Stages – You can see it as a group of activities that represent a business concept.
  • Tasks – represents work to be done. Can be Human tasks, Process Tasks (call a structured process) or Case Tasks (call other cases). These can be mandatory or optional.
  • Events – Represents something that happens that is significant for the case: e.g. a new file is added to the case, or someone who applied for a loan at the bank suddenly dies.
  • Sentries – Criteria that need to be verified in order to instantiate or complete a task.

As with BPMN, you combine these objects to model the case behavior graphically.

Complaint CMMN model

Complaint CMMN model

For an introduction to CMMN, I suggest the following references:

  • Case Management Modeling and Notation – Knut Hinkelmann

  • Introduction to the Case Management Model and Notation (CMMN) – Mike Marin

  • There’s an excellent book in the subject. You can find it in the link below.
    • Oracle Case Management Solutions – Léon Smiers, Manas Deb, Joop Koster, Prasen Palvankar

First Steps

The first rule is that we need to be able to start/invoke cases whenever we want, from whichever channel we want.

As we’re going to use PCS for this, we first need to create a new Application

Create New Application - Step II

Create New Application – Step II

Let’s call it “Complaint Case”.

Create New Application - Step II

Create New Application – Step II

Now, we create a new process in it. The process needs to start and end with a message event. This is what will allow us to reuse this when we want. Please, do not use None or Form events to start it.

Create New Application - Step III

Create New Application – Step III

Create New Application - Step IV

Create New Application – Step IV

In the next article

In the next article, we’ll address specific implementation patterns in Process Cloud Service and the setup of the data structure that facilitates Case behavior.

Until then, have a great week!

Maverick (José Rodrigues)

This is a cross post with LinkConsulting. For more Oracle Middleware related posts, please visit

Post Header photo by doug rattray

To break the rules you must first master them

ADF Namings Conventions – Part II

Hi all,

In my previous post ADF Namings Conventions – Part I I have focused my attention on:

  • Application & Project Namings
  • Packages Namings
  • Business Components Namings

Today I will start to talk about Model & View Controller Project namings.


Model Namings

For new ADF applications we are requested to set the names for Model and ViewController projects. In what concerns the Model it should following naming:


Example: RMKMyAdfLibModel


For the package structure it should be configured as follows:

<DOMAIN_NAME> + . + <PROJECT_NAME> + . + <MODULE_NAME> + . + model



As you can see, package structure follows the same structure defined in my previous post plus “model“.

View Controller Namings

In ViewController projects we have a wide range of namings we can follow since we have multiple features we can take advantage of. For that reason we divided it in sub topics. .


Project Name


The name for the project should be defined as follows:


Example: RMKMyAdflibController

By using “Controller” prefix we are able to automatically identify projects type and purpose.


Project Default Package Structure


Package structure for View Controller project should be defined as follows:

<DOMAIN_NAME> + . + <PROJECT_NAME> + . + <MODULE_NAME> + . + view


As you can see, package structure follows the same structure defined in my previous post plus “view“.


Images, CSS and JavaScript Directories


Images, CSS and JavaScript directories should be defined right under “Web Content” folder. The folders should have the following names:


Folder Type Folder Path
 To contain images  resources/images
 To contain CSS files  resources/css
 To contain javascript files  resources/js





Inside “web.xml” file in ViewController project set the following mappings:



Bounded Task Flows, JSFF, JSPX Directories


Reusable bounded task flows can be published in ADF Libraries and consumed by other ADF applications. For this use case is important, and a must, that all bound task flows have a unique name. If this isn’t accomplished ADF has no way to distinguish between task flows with the same name.

Before creating bounded task flows you should set a folder structure under “WEB-INF” folder. After this folder structure is created you can start creating your bounded task flows.

Folder structure should be created according to the following convention:





JSF, JSFF and JSPX files must be saved on the same folder of the task flow.

Page definitions will be automatically generated with same package structure under Application Sources folder. Example: or

Managed Beans for Task Flows should be created under Application Sources folder with the following package structure:





We decided to create Managed Beans outside “view” package in order to not have a mixture between page definitions and java classes.


In my next post I will focus my attention on:

  • Task flows as well as Templates and some more regarding View Controller Projects
  • JAR, WAR, EAR files


Don’t miss my next post 🙂


Pedro Gabriel



This is a cross post with LinkConsulting. For more Oracle Middleware related posts, please visit

Post Header photo by Lefteris Heretakis