Skip to main content

Posts

Showing posts from June, 2014

Reading Dynamically Added Attributes from a View Object

You can use the the PDefViewObject::getAttributeDefs2()to read the dynamically added attributes (attributes added by calling ViewObject::addDynamicAttribute or using PDefViewObject )  from  a view object. The relevant code snippet is shown here:

PDefViewObject pDef =(PDefViewObject)((ViewDefImpl) getDepartmentsVO().getDef()).getPersDef();if(pDef !=null){ AttributeDef[] attributes = pDef.getAttributeDefs2();for(AttributeDef acttrib : attributes){ System.out.println(acttrib.getName());}}

Cannot find module 'mongodb'

This time, it is not an ADF topic, sorry ;)
While trying out some samples on MongoDB and Node.JS, I ran in to a very basic error

Error: Cannot find module 'mongodb'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)

The solution has been discussed in this thread http://stackoverflow.com/questions/14226410/node-js-noob-cannot-fine-module-mongodb
To summarize solution from the above thread, you may want to do the following:
npm install mongodb -gcd /path/to/app/foldernpm link mongodb

Transaction handling in Application Module when used in JTA context

When Application Module is used inside the JTA transaction enabled  method( i.e when  AM method is exposed as web service or called inside a WebService or EJB with declarative transaction), framework takes a different execution path for the 'post-commit' activities such as entity cache clean up. In such case, framework use ServiceJTATxnHandlerImpl for handling the transaction and  the entity cache clean will happen only after finishing the transaction that is initiated by the calling  method(when the call returns from the wrapping service method), not right after the commit call on DBTransaction. If you want immediate clean up and does not need a global transaction management, then mark  the service method with no transaction as: @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) . This will make AM to use DefaultJTATxnHandlerImpl (as you see in normal scenario).

Using shared transaction options for nested taskflows even when they use different data sources

Sharing a tip that I learned a couple of days back. Thanks to John Smiljanic for detailing the secret of the magical property that I'm going to talk in this post, also thanks to  Ricky Frost who mentioned about this property in one of the discussion.

Use cases here is not something new, rather an age old requirement only: There are two task flows, both use ADF BC,  one talks to database-1 and this calls another task flow that talks to database-2. Now the developer wants to leverage the declarative transaction mechanism offered by task flow, that is, a commit call on the task flow return should commit changes in both the flows. Wondering what is big the deal here? Well, here is the short answer. The default task flow implementation assumes that when one a task flow shares transaction with another, both uses same data source. In other words, if the AM used in second task flow(callee) uses  different data source, framework will not bother to look up this data source , rather it will…