Monday, September 10, 2012

ADF & Event driven Integration with a BPMN process


The usecase for my sample application is:
A standalone application exists to create/update 'Departments'. Originally, it was not intended to be part of an automated process (BPEL or BPMN) but now business decided that their process for the creation of a department is actually more than just data entry in the standalone application. It also now involves an approval. 


Background:
1. Every interaction with a software application in a business environment is part of some process - the process may or may not have been analysed, modelled in a standard notation or automated, but it's a process nonetheless.
2. When we interact with software applications, we generate 'events' (Order fulfilled event, Loan approved event, etc.). 
3. The sample applications for this post can be downloaded from here and consist of: 
                  a) The SOA/BPM composite application - event listener 
                  b) The standalone ADF web application - event producer
 (Instructions to setup and run the sample are towards the end of this post)


From a technical standpoint:
Before BPM was implemented, the DepartmentCreated event used to be a simple insertion of a new row in a table. Now, it will lead to a longer process involving an approval (and possibly other human/automated tasks). From a technical standpoint, we are really not looking to change an existing application such that it becomes tied up to specific API's. 
With an event driven architecture, the SOA/BPM infrastructure listens to things that happen around your enterprise landscape and take appropriate action when required (in this case, it needs to start a process when a Department is created). 

My simple Process model:

1. Process roles
 I have created three abstract roles for the process - the 'ADF application user' always existed, because, people were always creating new rows in a table called 'Departments'. 
We now have a new 'Approver' role. (For convenience, I have mapped the default 'weblogic' user to 'Approver')
The third is the automated handler for automated tasks.  

2. The activity 'Create a department' is meant to represent from the perspective of the business process. The thing to note is it's represented as a manual task and not as a (initiator) human task
As I mentioned before, it is JUST a standalone web application with a facility to create/update Departments and from a technical standpoint, it is not even 'aware' that it is a participant in a business process

3. Structure of the composite 
My process does not expose any SOAP endpoint (as it's 'Start' event is not a 'message' but a 'signal'). 




4. The start signal. 
It's 'implementation type' is 'Signal' (not 'message', which is the default) and note the Event that it listens to.

Something interesting to note here is that my process data object is based on the same model as the domain objects (Entities) I created for the UI application i.e. we do not need to create our domain model twice - we levarage the one we have. 

We can also reuse the definitions from ADFbc SDO's if we chose, to avoid duplication. 

5.  Raising the event. 
All I had to do was to configure the Entity to raise events I was interested in and the payload I wanted to pack into the event. In my example, I chose to send the department ID and name. 
We can easily expose a getByID web service so that the process can query up the whole department object when it needs to. Until then, we avoid the overhead of lugging huge DOM payloads around and the associated overhead of transformations, marshalling/unmarshalling etc. 
End result: good performance. (or at least you avoid performance problems specifically due to unnecessarily large payloads later on - provided other aspects of the code+configuration are right)



All SCA components (Mediator, BPMN and BPEL process engines) can similarly listen to events. 
The component that raises the events is just going about its business and doesn't know or care about who or what might be interested in these events. i.e. an existing application doesn't have to call specific API's or service end-points and is immune to changes in other components that listen to its events.
This allows a great deal of decoupling between applications to be integrated.


Concepts covered:
1. Manual activity
2. Business events
3. BPM Process data objects based on the existing domain model - I used the same XSD for my PDO as the one for my DepartmentCreated event.

When we talk Integration, SOA mostly involves SOAP web services - but just as in real life, a 'business process' doesn't necessarily need to be 'invoked' (via a web service or API call) to get initiated. We just model and implement processes to reflect real business scenarios.  

Where appropriate, an 'Initiator' human task could also initiate a process - i.e. when the first activity in a business process is a human task - although, in my example, I purposely have not implemented a  initiator human workflow task.

Sample Application
1. My development environment is a SOA/BPM suite 11.1.1.6 installation on a single server instance with no managed server. The SOA and BPM domain was created in 'developer' mode. Both my SOA/BPM suite and the standalone UI application are deployed on the same server (but this can be configured to be on different servers)
2. Create a data source jdbc/hrDS pointing to the sample HR schema.
3. Deploy the EmpDeptADFApplication and access it via http://your_server:your_port/adfedl/faces/home
4. Deploy the EmpBusinessProcess composite
5. When you create a new department (manually enter a unique departmentId) and commit it, an instance of the EmpBusinessProcess composite is created. For the approval human task, login to the BPM workspace as weblogic and just Approve or Reject the item in the worklist. 

References:
1. https://blogs.oracle.com/soabpm/entry/event_delivery_network_chapter 
(An old post that introduces the EDN but that was before the BPM suite and BPMN processes became 'SCA-fied')
2. Start Events for a business process (Implementation type='Message' is just the default !! Just like in real life, every process does not logically start with a web service or an API call! ): 
http://docs.oracle.com/cd/E25178_01/doc.1111/e15176/model_bus_procs_bpmpd.htm#CJAEJEFD

Saturday, August 25, 2012

Brief note on ADF 11gR2 installation

The certified application server and ADF combinations for ADF 11.1.2.x.x are available here.

We need to follow the 

I'm of course only going to list a helpful link and not actually post the contents of that document as it is secure, but briefly:
1. On your standalone weblogic server, Install ADF 11.1.1.6 runtime first 
ADF Runtime is available from the usual ADF downloads page. 

2. Then install the two patches for both ADF 11.1.2.1 and ADF 11.1.2.2 available from Oracle support and mentioned in the support document. 

It's important to read the patch README files, set the ORACLE_HOME environment variable correctly and use the correct OPatch version... (latest usually works) to avoid any gotchas. 

Friday, August 24, 2012

Drilldown on ADF DVT graphs

The sample workspace  (JDev/ADF 11.1.2.1) for this post is available here.
Just run adfc-config from the ViewController project. 

One form of drilldown is where you provide an 'action' that can be a control flow case in the taskflow and which leads the user to another view/page, but that's not what I'm writing about. 

The drilldown i'm referring to is for the following usecase (based on the HR schema):

A graph displays Departments and total salaries of all the employees in that department. 
When you click on one of the departments (represented as a bar graph), you see the same bar graph with employees in that department. 
(You can extend this approach indefinitely but can get complex after a couple of levels of drilldown). 

My approach uses plain ADF DVT components and not BI data controls**.
It also relies on the underlying view objects to provide the aggregate data (sum of salaries in this example) and doesn't use any of the aggregation functions of the DVT components. 
You might also want to consider the approach mentioned here to see what works best for your usecase: https://forums.oracle.com/forums/thread.jspa?messageID=10527052#10527052

Master Graph:




And when you click on one of the above bars, you get to this (employees under the department you clicked.)
Also note a 'Drill Up' button or icon can be provided to go back up one level... 

As of this writing, I didn't know of a declarative approach to achieve this, so the core of this functionality is the GraphHandler class (available in the attached sample application).

**I just read about another approach that might work on this forum thread and this developer guide link but I haven't tried that and I'm not sure it would work for multiple levels of drilldown or drill-up. 

My approach relies on programmatically replacing the binding of the dvt:graph component (screenshot of the code below):



Tuesday, August 21, 2012

ADF and Coloured tooltips - 2 [and its limitations]

Reference: I have simply incorporated the approach presented here in my ADF application and the solution involves a bit of JQuery
http://tutorialzine.com/2010/07/colortips-jquery-tooltip-plugin/

This post follows on my earlier sneak peek but as I eventually learnt, this is quite limited in use and you might need to find specific uses for this. Still, here's my 11.1.2.1.0 workspace that uses this in case someone can share other ideas...

Does look nice where it works though... 


In general, styling of ADF components should be accomplished using skins and one shouldn't rely on  the "generated output" (html) as this can change across ADF releases.
For more on the correct approach to skinning, please refer: https://blogs.oracle.com/jdevotnharvest/entry/how_to_learn_adf_skinning

Also, coloured tooltips (and other similar styling) would only work for some components (outputText, goLink, commandLink) whose HTML output is generated with the 'text' attribute. 

More complex components appear like this in page source 
new AdfRichInputText('it1',{'shortDesc':'Green','maximumLength':6,'converter':new TrNumberConverter(null,'number',null,null,false,false,null,null,null,null,null,null)})

so that's probably why the complete tooltip style never gets applied. 
Now, back to coloured (or colored) tooltips. 

The solution involves:
A 'base' tooltip style (defined in colortip-1.0-jquery.css) that is meant to get applied to every tooltip (unless you override it by supplying another tooltip styleclass)
I haven't made any changes to the one I downloaded, except for referencing it in the home.jspx page. 


Saturday, August 18, 2012

ADF unbound - multi coloured tooltips anyone?

Please read through part 2 as well as this has some limitations.

This was a client request (can we make it prettier please?) that I originally thought wasn't worth pursuing as it wasn't 'out of the box' and couldn't think of an elegant way.

But then after a beer on a sunny Saturday afternoon, one does start to "think outside the box" !

So, inspired by a recent "Beautiful ADF sites discussion" here are some screenshots to feast your eyes. (This is just my demo app based on the emp-dept schema so I know everything is ugly, so no judgements on the actual content, please. I just use it for proofs of concept). 




Tuesday, August 14, 2012

A very important read for ADF/Fusion application design


I think Fusion applications design patterns (i.e. 'FUNCTIONAL' design patterns) are one of the most important resource to become publicly available as a result of Fusion apps development - 
https://blogs.oracle.com/soacommunity/entry/oracle_fusion_applications_design_patterns

(They have been available in beta form for a while now and I made it a point to share with clients to help them create functional specificatinons) 

New applications - even standalone plain ADF ones should especially leverage a lot of the learning and research that went into Fusion apps all these years.

As a former Fusion apps developer, it was only natural that I applied a lot of this learning in applications I developed elsewhere - but I had to be constantly mindful of not sharing any info that wasn't publicly available. 

The "Is it quick?" methodololgy. Worth it?

The biggest lesson I learnt on Oracle Fusion applications development was the importance of a well engineered product (no-brainer, isn't it?) 

This post recaps why you need a system that is well designed rather than just 'quick' - 
http://thinkoracle.blogspot.co.uk/2012/08/the-two-ways-of-doing-job.html

Working with different kinds of IT requirements, one often needs quick solutions in these scenarios:
- tactical fixes 
- prototypes or proofs of concept
- examples

Sometimes, quick is often the side effect of knowing the technology well and knowing how to get the most out of it. 

ADF is the perfect technology to showcase a lot of business value quickly (vis a vis comparable web technologies) - but it's easy for new practitioners to get overconfident with it and ignore some basics, to the long term detriment or even failure of the project. 


Fusion applications (check out the videos if you haven't already) illustrates power of well thought out, well designed, well engineered systems. 
Design = Functional and Technical (Two different things) 


On a related note, I have started to have mixed feelings about the agile approach, and I have come to suspect it promotes the above three over and above a well thought out design. 

Pros:
- It keeps a team focussed on the "most important tasks that need to be done based on the state of the product now".
- Helps keep track of the big picture with a prioritised backlog. 
- Promotes test driven development 

Cons:
- A team inexperienced with both the technology and the agile methodology can get short-sighted and only focus on immediate 'quick' fixes.

- Sometimes old habits just die hard: if you don't invest in automated testing, at least create well documented acceptance criteria in your stories or test plans to avoid regression. 
"Doesn't look pretty" is NOT a valid or helpful test result. 

Even an internal system, expected to be used by a few hundred concurrent users deserves more than that. You might get by with the old ways until you can't - that is usually a stage where things can't be salvaged any more. 

Sunday, April 15, 2012

How to show/hide operators in adf:query advanced mode

In this post, I will provide a way to modify the operators list in the ADF query panel (af:query component) - i.e. to remove and add operators to the list. 
 (at the time of writing this post I didn't realise it was already documented here: http://docs.oracle.com/cd/E14571_01/web.1111/b31974/web_search_bc.htm#ADFFD2457)




The ADF Faces af:query component is a handy tool that neatly binds to an ADF bc View criteria defined in the model. 


In the default advanced mode, the query panel allows end users to select a suitable operator to apply to the query fields. The default list of these operators (of type JboCompOper) is populated based on the field's data type and ADF is rather intelligent with this feature - for example:
a) for an LOV based field, it displays an LOV if you select the Equals operator but changes to a text field when you choose the Starts-with operator...
b) It shows you two fields if you select the between operator. 


In my sample project based on the usual emp-dept schema, I have JobId as one of the search fields. In the advanced mode, by default, JobId is shown with the following default operators:


Sometimes you would want to hide some of these. The trick is to use the CompOper tag inside the View object's XML definition. 
The CompOper tag can be nested under either ViewAttribute or ViewCriteriaItem. 
So, to hide the Equals operator, you would use the following:
After adding some more tags under my JobId ViewAttribute, my operators list now looks like this:
Assumptions/Pre requisites:
The reader is familiar with what the Employee-Department schema is, basics of ADF like View object, view criteria etc. 


References:
The list of all possible fields is available here:
http://docs.oracle.com/cd/E15051_01/apirefs.1111/e10653/constant-values.html#oracle.jbo.common.JboCompOper

Saturday, February 25, 2012

Simplified J2EE view

Entity objects = business domain objects: data + validations - we would traditionally implement these using entity EJB's, hibernate objects etc. 
View Objects = Not exactly J2EE TO's - I find this an abstraction unique to ADF encapsulating the POJO and a query.
Application Module = the API interface / 'business service'. You write your logic and expose it using any convenient interface - java client, SOAP client, EJB interface etc. 

MVC (DataBindings - ADFm, the model; Pages - jsff or jspx, the view ; TaskFlows ADFc*, the controller) then resides on top of these in your ADF UI project and consumes these business services (or ones from a non ADFbc source). 



*These names are reflected in the packaging structure of Oracle's java libraries that implement these.


Anyway, that's my brief take on things, originally posted as a response here.
https://forums.oracle.com/forums/message.jspa?messageID=10161611#10161611


Here's the official patterns catalog page.
(I need to follow up on one of their definitions if purely for pedantic reasons)