How can JApex enhance my APEX applications?

Like many software development projects especially in the business area, we; develpers; find ourselves repeating certain tasks over and over. examples of tasks JApex targets include Declarative Blob Handling, generic reporting amongst other similar tasks.

JApex aims to provide a drop in solution to such recurrent requirements. When you find yourself trying to save the time rewriting that code that simply loads an image from a database, or display a stored pdf to the end user. Similarly when you need a mature RESTful generic report integration component. that is ready to go and serve reports to clients as soon as you configure it with (almost) zero coding on your side.

Such additions deliver instant value to almost any APEX project. They were born out of real requirements in real applications and I believe they will prove valuable to you as much as they are to me.

So Why is it called JApex?

JApex is based on JAVA and is built primarily to compliment the mentioned functions in Oracle APEX (Application Express). in my humble opinion APEX is a great product that goes a huge distance in meta-data driven programming. and if you haven't seen it or used it yet. and you're like me building Data-centric Applications for your every day job; APEX is nothing short of a life saver.

So JAPEX is an Oracle Product (APEX) extension?

Well, Yes and no. as much as it's built to compliment few extra features often required by applications I built that use APEX, it is still database agnostic.

Nothing is Tied to Oracle Database in specific. if you've done your fair share of JDBC programming against several database, it's quite noticeable oracle requires special handling especially when it comes to Blobs , still the code written in JApEx cuts no corners to support the standard Blob handling in every major DBMS. testing and verification is underway to ensure its compatibility with other major Databases like DB2, MySql, PostgreSql, MSSql etc.

So what is in the Box? JApex Box..

JApex currently functions in to distinctive areas. generic blob handling and, high quality RESTful reporting.

What is Generic blob handling and what features are included?

Blobs (Binary Large Objects) are becoming increasingly common in all scales of databases. from simple POS's to store product images in the database, to HR applications storing employee photos, to document storage and retrieval. the list just goes on and on.

Blobs, regardless of their contents, share common requirements in most modern web applications. such as:

• Most web based applications built today require some way of serving blobs on the fly from the database, e.g. when you display an employee record, it's always nice to avoid a name confusion by displaying the employee photo next to the personal details. another example include showing a db-stored pdfs to the end user that was either uploaded earlier or generated by and application.
• However, in HTML up to version 4.x support for convenient customizable method to upload files is severely lagging. that's why Flash uploaders are gaining momentum as elegant customizable front end components to fill in this gap. however to fully implement an upload solution in your application its usually time consuming and error prone.

  What is not readily visible until you have your fair share of applications, is that despite what a particular Blob represents, all handling of all blobs can be generalized as

  • Downloading: getting a blob from a field in a dataset (table / view) and HTTP serve it along with its metadata, such as MIME Type or optionally file name.
  • Uploading: receive the contents of blob as sent by a client and storing its content in a database. this in turn can be
    • Updating of an existing record blob field content with a new image or.
    • Initializing a record in the database with some relevant data alongside a blob field.

  Also, several interface methods are commonly required, such as:

  • Standard HTTP GET method for retrieval, POST with multipart form data for submission and
  • An invokable service like interface for situations where a wider gap is to be filled, common examples as Twain source image acquisition from sources such as cameras and scanners. Also, when a data services is required to supply and/or store blob objects in system integration scenarios

  Of course there are numerous work-arounds to have the database instance does that for you without ever needing JAPEX. several approaches are documented. however, in my experience, such task is better suited for Java based component. if for no better reason may be you can consider to offload your database engine, allow for blob storage in a secondary database. share the logic and the experience in providing such features at relatively no cost, both development and runtime.

Ok, so What about "RESTful" reports?

APEX uses the term "reports" quite confusingly, APEX used the term reports for any tabular listing of resultset data, while APEX in consistent in this regards with support for both simple tables and a highly customizable interactive tables, it doesn't fulfill what we usually refer to as Reports in common business applications.

Think of cross-tabs, sub reports, background images and advanced formatting, multipage printouts on media with various form factors, not to mention advanced exporting to high quality sharable documents.

In JApex sense, reports are read only, dynamic, high precision, print oriented artifacts. Once your application users have one of these, it's quite difficult to convince them to settle for something simplistic as simple HTML with tables.

As a Java developer, I'm constantly blessed with an amazing library and/or its toolset for generation of reports in JAPEX sense. this library is JasperReports. JasperReports not only competes with high end commerical reporting tools, IMHO it can easily be considered to exceed them in terms of functionality robustness, performance and overall quality. not to mention all this is absolutely free and open source.

So for the RESTful part, simply it means that every thing you need to run an arbitrary report ( that is available to JApEx Of course) can be passed in a simple URL. That's right, you select which report, pass it all its parameters and even specify which format you want it to be produced in along with an optional file name is specified by a simple URL.

YES, PDF is supported out of the box, YES printable XLS also is, as part of our coming features, we will be simply surfacing more and more output formats as time permits. We say surface as the grunt work of actual production of target formats is totally provided by JasperReports.

All the credit for the quality of reports to JasperReports team. JAPEX RESTful reports simply surface that in simple URLs.

So How Do I Start with JApEx?

• Download your latest version of JAPEX here
• Ensure you've visited and configured the needed pre-requisites.
• Extract JAPEX WAR file (WebArchive) and deployed (AKA installed) it properly.
• configure how JAPEX connects to the database.
• configure as many blob configurations you need.
• configure Report stores as needed.

How does JAPEX relate to APEX Listener

JAPEX merely adds a couple of features here and there, APEX listener is production quality replacement for mod_plsql. I would like to think of JAPEX as a component that aims to make your life easier, by off loading all the effort of blob handling and high quality printing to JAPEX you can concentrate on what matters most; that is business functions to add to your applications.

Also, JAPEX and APEX listener are neighbors. if you choose to use Apex listener, it's quite logical that you would be hosting JAPEX onto the same application server such as tomcat, glassfish and the likes. With that in mind, it's important to note that both projects; Listener and JAPEX, have nothing in common and share nothing between their configurations and thus you can use either, at any point in time in your project without ever needing the other.