Monday 28 July 2008

Advert: AUSOUG JDev masterclass - last chance!

The last leg of the Australian AUSOUG JDeveloper masterclass is coming up at the AUSOUG conference on the Gold Coast, 13th-15th of October. Check out what the attendees at the last 2 legs of the JDeveloper masterclass had to say about this 1 day course:
  • Excellent course without the Oracle marketing spin!
  • Awesome! better, quicker than a drawn out 5 day bore.
  • Perfect for Forms to JDeveloper presentation overview. Pretty impressive stuff.
  • Enjoyable & informative. Good overview and reasonable overview of the tool.
  • Great overview of new features.
  • Yes it was a good overview to what JDeveloper/ADF Faces combination can do.
  • The course satisfied my requirements: spot on!
  • Chris Muir was excellent, thoughtful and knowledgeable.
  • Very good overall overview of Oracle JDeveloper 11g. Enjoyed the workshop today.
This series, sponsored by the Oracle Technology Network, and presented by myself from SAGE Computing Services, will introduce you to simplicity of web development with the latest 11g release of JDeveloper, without writing a single line of Java!"

The course agenda and full details can be found here. Check the AUSOUG conference webpages for more information on registering.

Hope to see you there.

Tuesday 22 July 2008

ADF BC: EO/VO create() state + JBO-25030 revisited

Recently I blogged about why you might receive JBO-25030: Failed to find or invalidate owning entity in ADF BC, a follow up to a further description by Steve Muench.

I'd like to blog about another reason you'll receive JBO-25030 and is related to my recent post on ADF BC: EO/VO initial state post create() explained.

In that blog post it details that an EO/VO that is instantiated and attributes are defaulted via declarative default settings or your own programmatic code, the record's status is set to STATUS_NEW, but the ADFm binding layer overrides this with STATUS_INITIALIZED. This status implies the record is not a candidate to be inserted into the database until the user or calling program changes another value in the record or programmatically changes the status of the record to STATUS_NEW.

This behaviour has further implications for EOs involved in Associations, more commonly known as foreign key or master-detail relationships, and Composition Associations in particular.

In the case of a master-detail EO Association that is not marked as a Composition Association, on the programmer creating the master entity which has its values defaulted (status STATUS_INITIALIZED), and creating a child entity which the user then sets some of the attributes manually (status STATUS_NEW), on pressing commit the programmer may be surprised to receive a foreign-key constraint error returned from the database. This occurs because the master EO status STATUS_INITIALIZED marks it not as a candidate to insert into the database, but the user setting the child EOs attributes does mark it as a candidate for the database with status STATUS_NEW. As such at commit time, the ADF BC mid-tier searches the EO cache looking for records with status STATUS_NEW (and STATUS_MODIFIED to be strictly true, but not considered here), discards the parent record because it has the wrong status, but sends the insert DML to the database for the child record, raising the FK error.

In the case of a master-detail EO Composition Association, on the programmer creating the defaulted parent EO, creating the child EO and manually setting values, and finally pressing commit, this time the programmer will hit "JBO-25030: Failed to find or invalidate owning entity". Why? As you know a Composition Association says that a child can't exist without a parent. So in this case the ADF BC mid-tier is enforcing that the child cannot be inserted into the database with a parent whose status is STATUS_INITIALIZED, because the parent is not a candidate for the database. In other words the mid-tier is enforcing a mandatory FK relationship, with unfortunately a some-what obscure error message.

As detailed in my previous post, you can override the default behaviour of the parent VO such that it's defaulted state will mark it as a candidate to insert into the database.

I'd like to thank Steve Muench for his assistance on the issues behind this blog post.

This post along with other posts describing common JDeveloper error messages are indexed on the Oracle Wiki.

Wednesday 16 July 2008

R.I.P. Oracle Reports?

While the Apex vs Forms vs JDeveloper wars rage on (no casualties so far, just bruised egos), there has been another much more silent war where there has been another casuality, though whether the victim is just wounded or dead is uncertain.

Good ol' Oracle Reports has been for a long time brother-at-arms with Oracle Forms. In my opinion Reports is still one of the most sophisticated reporting tools available, purely through its support for matrix reports. It was also an incredibly successful tool in the fact that I'd say nearly all of the Oracle sites I've supported in the last 10 years had Oracle Reports as its main reporting tool. Yet with its antiquated interface, complicated (though sophisticated) layout manager, and dying skill set, it appears Reports as a tool of choice for new developments is definitely over and it's now pushing up the poppies on the IT battlegrounds. When was the last time you saw Oracle Reports at a user group event?

Don't get me wrong, many organisations out there are still using Oracle Reports for legacy systems. Yet it's my belief that for new development organisations are looking (or should be) elsewhere.

Now there are obvious Mark III tanks on the battlefield trundling up (I might as well wear this war metaphor out), such as XML/BI Publisher. XML/BI Publisher has certainly taken a lot of the reporting publicity focus in the last couple of years. However like a tank, the price of XML/BI Publisher seems to put it out of range (get it? ;) of most development teams. Why Oracle has yet made it competitively priced I'm not sure (and by this I mean people don't suck in their breath when they hear the price). Oracle could easily make it cheaper, flood Oracle customers with it, then start to raise the prices and have it as the next Oracle Reports of 2020 (and the associated revenue stream which I'm sure Oracle doesn't care about ;).

Keeping this last point in mind, there are of course other third party tools such as Jasper Reports which many have (reportedly) moved to. It seems to me Oracle is failing to think long term enough here because as customers move off Reports to third party (cheaper?) tools, they're one step closer to not buying Oracle software altogether.

What's your opinion? Is Oracle Reports dead for new development (and even old)? Is XML/BI Publisher a real contender as replacement for Oracle Reports given Publisher's price? What other reporting tools has your organisation adopted in replacement for Oracle Reports?

Friday 11 July 2008

Desupported Oracle Forms vs JInitiator vs Sun JVMs and browsers

(Please note as it's been pointed out to me that some of the following post was confusing, this post has been edited from the original to make it more clear. One of these days I've got to get myself an editor ;)

For whatever reasons unfortunately some sites don't have the ability to keep their Oracle Forms within the Oracle officially supported versions. As an example you might be a site still running under Forms 10gR1 (9.0.4), a desupported version of Forms (1ogR2 being the most recent supported version when this post was written).

While the recommended approach is to keep up with supported versions, this isn't always achievable in a timely manner, or at all at your organiation.

This presents a number of catch 22s for organisations, one of which I'd like to highlight.

One such catch is where organisations would like to move to the latest browsers on their common desktop emvironments. For example many organisations are pushing to IE7 over IE6 for the perceived security benefits and user preferences of the new browser version. However the last documentation coming out of Oracle for the organisation's specific version of Forms (say 10gR1) only lists certification for older JInitiator or JVM versions, and older browsers (such as IE6 or FF1.2).

What to do? Does this mean you can't upgrade to IE7 or the Sun JVM? Are you stuck with IE6 and an earlier JInitiator version because the documentation says so?

I posted just such a question on the OTN Forms forums the other day and there were a number of useful replies that readers might be interested in, particular from Wilfred van der Deijl and Grant Ronald. Wilfred's reply is well worth the read. Grant also linked back to an earlier blog post of his where Oracle is going with JInitiator and the Sun JVM. Oracle is making no secret of their future choice of JVMs and it's nice to see we're moving to one standarized JVM.

This also brings up another issue, that sites should be careful to base their decisions on outdated Oracle documentation. When Oracle has desupported 10gR1 and are no longer updating the Client Platform Support docs, this means you're likely to get yourself into trouble basing your decisions on such out-of-date documentation. You could mistakenly conclude from the 10gR1 documentation that you must remain on IE6 because Oracle never certified 10gR1 against IE7 and the relating later JInitiator and Sun JVM versions. Yet there's nothing to stop you attempting to upgrade to the latest browsers/JInitiator/Sun JVM, just make sure you test it! Just because Oracle didn't certify it, doesn't mean it doesn't work! Obviously you're already running desupported Oracle Forms versions, so you don't care if Oracle certifies against a specific future browser/Jinitiator/JVM. You just care that it works..... (though be mindful that if you do intend to one day upgrade Forms, try and pick certified browsers/JVMs for future Forms versions to save you unnecessary headaches later).

(To reiterate, I hope readers understand the emphasis here, I'm not saying that the certifications listed in the existing 10gR1 doc are wrong, that's what Oracle did indeed certify against. What I'm saying is as Oracle never certified later versions, assuming therefore Oracle Forms wont work with later browsers/JInitiator/Sun JVMs, is basing your decision on a poor assumption. Basing any decision on a poor assumption is going to give you the wrong outcome to your own detriment. QED)

I can even see in the future this becoming a bigger bind for organisations that want to upgrade to the latest version of Oracle Apps, browsers, the Sun JVM etc, but then discovering they have internal custom Forms systems that haven't been upgraded. Again the assumption you'd need to stay back on IE6 and JInitiator would mean you couldn't move forward elsewhere. Realising you can update JInitiator or to the Sun JVM, and browsers, as long as you test, can be the liberation that your organisations needs.

And personally because I'm interested in JDeveloper, if you remain on older browsers, this brings up a problem for the JDeveloper camp, as Oracle JDeveloper 11g want IE7 or Firefox 2 or above. Imagine having your organisation telling you can't use JDev 11g and all its fantastic AJAX/RIA features because they're running IE6 to support a desupported versions of Forms! I'm sure there is irony in there somewhere!

Of course this could all be fixed by organisations keeping on the supported upgrade path from Oracle, something which Grant Ronald and others have previously emphasised strongly. Hopefully the above helps managers and technical leads understand why letting your organisation lag in supported versions can be such a hindrance elsewhere to the organisation in the future and present, besides just the perceived need to stay with the supported versions. Its not really just about keeping up with support, its about the decisions on the information at hand you make around the software you have at hand, and how up to date that information is.

Tuesday 8 July 2008

ADF BC: EO/VO initial state post create() explained

Thanks to Steve Muench, Olivier and Rob on the JDev OTN Forums, I learnt some valuable lessons about the state of ADF Business Component (ADF BC) Entity Objects (EOs) after the create() method is called. I thought I'd share this new knowledge for others to benefit.

In JDeveloper's ADF BC Entity Objects (EOs) and View Objects (VOs), on instantiating an EO/VO, it's possible to set the default value for the EO/VO attributes declaratively or programmatically through code. The declarative fashion is done by setting the Default property to simple literals for the individual EO/VO attributes in the associated EO/VO editor. Within JDev 11g this has been expanded to support Groovy expressions.

Alternatively both the EntityImpl and ViewRowImpl that represent the EO/VOs in code, the programmer can override the create() method to programmatically set the EO/VO attributes. For example you may wish to set an attribute to the next sequence number from a sequence in the Oracle database, and some other attribute to a static value:

public MyEntityImpl extends EntityImpl {

  public void create(AttributeList attributeList) {
    super.create(attributeList);
    SequenceImpl seq = new SequenceImpl("my_db_seq", getDBTransaction());
    setSomeId(seq.getSequenceNumber());
    setSomeField("some value");
  }
  .. and so on ..
}


Thus in the Business Components Browser if you open the associated VO, and create a record, you'll see the defaulted attributes set to the values above.

As per section "9.2.5 Understanding Entity Object Row States" in the 10g JDev guide for Forms/4GL Programmers (this also exists in the 11g guide, but at the time of writing this article the 11g guide is still in draft), on creating a new record the EO's state should be set to STATUS_NEW. STATUS_NEW says that at least 1 of the attributes of the EO has been updated, and thus the record is a candidate to be inserted to the database.

There are other alternative statuses for an EO, including STATUS_INITIALIZED. This status indicates a new record that is not yet a candidate to insert into the database as no changes have yet occurred to its attributes, it's basically just empty. Again to be clear, ADF BC will only mark the record to be a candidate to insert into the database (STATUS_NEW) when either the user sets a value, or programmatically overrides the status of the new row. (The user in this case means the consumer, or the program that is interfacing to the ADF BC project; this won't be a real human user directly, at the very least an UI will sit in front and provide access to the user)

So from our example above, given that we've programmatically updated attributes, is it reasonable to assume the EO's status will be STATUS_NEW once the user has created the record and we've programmatically defaulted the values?

If we consider the Business Components Browser (the Tester), and we consider JDev 10.1.3 the answer is Yes. However if we consider JDev 11g the answer is No. (Groan I hear you say ;)

Why? The key is the statement above:

"ADF BC will only mark the record to be a candidate to insert into the database (STATUS_NEW) when either the user sets a value manually, or programmatically overrides the status of the new row. (The user in this case means the consumer, or the program that is interfacing to the ADF BC project; this won't be a real human user directly, at the very least an UI will sit in front and provide access to the user)"

Note my emphasis, that the calling program can override the EO state if desired.

In JDev 10.1.3 the Business Components Browser (known as the Tester), as confirmed by Steve Muench is a "cheater" and doesn't actually implement a full blown ADFm binding layer, acting like a true ViewController to the ADF BC Model project. Instead it directly invoked the ADF BC project with its own functionality.

In JDev 11g the Business Components Browser sits on a real ADFm binding layer and as such acts like any ADF Faces/RC page.

The ADFm binding layer being the calling program to the ADF BC layer in this case, actually has code in it to override the status of an EO record if it can't detect any attribute changes by the real "human" user, regardless of the programmatic defaultedv values in the code above. And it sets the EO status back to STATUS_INITIALIZED, marking the record as a non-candidate for database inserts.

Conversely the 10.1.3 Business Components Browser because of its own custom functionality didn't.

This means in 10.1.3 when you commit the new-programmatically-defaulted but not user changed EO record, it will be inserted into the database. Conversely in 11g even though you commit the new record, unless you as the user make a change to one or more of the attributes, the 11g ADFm binding layer will override the status of the EO and it won't be written to the database.

Obviously this functionality isn't always desired. To override this default behaviour such that the record is inserted into the database regardless, you can override the ViewRowImpl's setNewRowState() method as follows:

@Override
public void setNewRowState(byte b) {
  if (b != Row.STATUS_INITIALIZED || getNewRowState() != Row.STATUS_NEW) {
  super.setNewRowState(b);
  }
}


It's this method that's called by the ADFm binding layer, so effectively you're intercepting the status set.

Ideally I'd like to see this as a property on the EO/VO editor, but at the very least ADF BC gives us the ability to override the default functionality by code.

Please note for the simplification of the discussion above, when I say that the ADFm binding layer sets the EO status, it can't actually do this directly. It needs to interface with the parent Application Module, then the View Object that represents the EO. Thus why we override the setNewRowState() method in the VO rather than the EO.

Thanks to Steve, Olivier and Rob for their assistance with this post.

This post was written against JDev 10.1.3 and JDev 11gTP4. As usual check everything under your specific version as your mileage may vary.

Friday 4 July 2008

Should ADFUtils and JSFUtils be included in the JDev base release?

I raised the following question on the OTN JDev 11gTP4 forums today:

"A question came up from a client the other day, is how come ADFUtils and JSFUtils that appear in many of the Oracle JDev demos aren't included in the base JDev release? They seem like such obvious things to include in a base ADF Faces/RC project and for Oracle to expand upon, yet we currently have to "steal" the code for our own projects and include them."

We've already had some interesting replies from Timo, Kuba and Simon. We'd love to hear your opinion too. Please head over to the JDev 11gTP4 forum and add your thoughts to the post.

Wednesday 2 July 2008

You're not famous until you're on the cover of an international magazine

Many a budding fashion model becomes world famous when they're first printed on the cover of an international magazine like Vogue. Obviously the same rules (must) apply to the IT market. I'm betting your fame also soars if you make it onto the front of Oracle Magazine, which apparently has over 100,000 subscribers around the world!

As you would have noticed (of course you did), I managed to make the front cover of the May/June 08 edition of Oracle Mag.

What, you can't see me?

I'm row 15, picture 23.

Or is that row 23, picture 15?

Or is it..... oh, never mind, the important part is:

See. Me. Front page. Instant Oracle celebrity. In all my black and white 0.5cm x 0.5cm glory. My Mum is going to be so proud.

For any future photo ops, please contact my agent.

(Normal JDeveloper transmissions will resume on my return from teaching an Advanced Oracle Developer course ..... hey, if Richard Foote can have an ego, so can I ;)