Montag, 9. Dezember 2013

Rapid Response UI with WebSockets Example

In my earlier post Rapid Response UI with WebSockets, I described a way to make your UI respond very quickly to events created by the server. Last friday I showed an example to the german ADF community. This example can be downloaded here

It is a very simple messaging application. Very straight forward without any validations or clever process handling. But you can easily send messages. When you start the application you can name yourself and receive messages from there on.
To run the example you need a table called messages. There is a Scripts folder with a create script for this table.

Have fun.


Message when connected to the WebSocket Endpoint


WebSocket message sent by the server and get request send by the client upon message receive from the server. See the badge turned from 0 to 1.

Rapid Response UI with WebSockets

If you take a close look at rich internet applications, there is no real server sided event producing. The server is always only responding to requests. This is natural since it is a problem of the HTTP protocol everything depends on. If it looks like you receive a server side message just in time, it is only because you send a request earlier in the background. This requests are causing a lot of network traffic. Since most of the time it is like a client asks "is there something new on your side" and the server only response with something like "no, ask me later again". This mechanism is called polling and is way off age. The smart new solution is called WebSockets. It's part of the HTML5 standard and specially designed to allow a bidirectional communication between server and client in a web environment.

WebSocket communication is initiated with a HTTP Request. If the server is able to communicate with the WebSocket protocol the connection gets upgraded. Now the connection does not close after every request and the server is able to send messages to the client.

Right now there is no native WebSocket support within any ADF components. But I am sure there is new stuff up ahead. I expect at least the active data sync service to be upgraded to support WebSocket connections. Right now it relies on polling and streaming.

What if I have the need to refresh the clients UI by a server event? Can I make use of this cool new WebSocket protocol, to make my ADF UI respond very quickly? Yes you can. And it is far more easy than I expected. Let's try something with a JavaScript WebSocket connection and a simply bean.

Before you start you need a Weblogic 12c or a Glasfish 4 as application server because those support the new protocol. On Glasfish you have to turn it on. On Weblogic 12c you can just start.

This is what we are going to build. A ADF Application that informs it's page about something new. Without any polling or something like that.


When you created your ADF WebApplication you need to add the Weblogic 12c API library to the ViewController project.


The next thing we create is the websocket endpoint connection. We only need a small Java class for our purpose. There we add an annotation @WebSocket and define a path for our connections.


This class does nothing very special. Most interesting is the static queue which contains all the websocket connections. This can later be used by our bean to send messages to one or all the connected clients.
The next thing we should do, is connecting to our new created WebSocket endpoint. Since we don't have any smooth af:websocketconnection component, we need to do this stuff by ourselves. Create a JavaScript file and add it to an ADF page with the af:resource component directly under the af:document tag. For Example:

<af:resource type="javascript" source="/resources/js/wsClient.js"></af:resource>

Within this JavaScript file, create method to connect to our new WebSocket endpoint. 


The shown method will show us a alert window on a successful connection. So, when we start our page now, we should get a nice alert window. You have to be careful that the defined wsUri variable matches the context root you defined for your ADF Webapplication. The added "/ws" comes from the path we created by our annotation in the endpoint class.
Next we should initiate a server side message to our client. Therefore we create a bean that sends a message to all our connected clients. And to call this method as ADF ActionEvent we also need a method that has a ActionEvent parameter.

Now we are able to connect to as client with JavaScript to our WebSocket endpoint and to send a message from within out application to all connected clients. So now we are close to the final. All we need now, is to refresh our UI on this server side event. If you search for solutions to run some Java from JavaScript in an ADF Application, you get really fast to the need of the af:serverlistener component. This can run a defined Java method from JavaScript. If you define it like this

<af:serverListener type="CallJava" method="#{sender.refresh}"/>

You need a bean called sender with a refresh method. Within JavaScript you call this serverlistener like this. 


The use of this component is already well documented so I won't go into detail with this one. Now the last thing we need, is to refresh our UI within this refresh method with a partial page rendering. Therefor we use the addPartialTarget method. 


This method executes some stuff in the bindings and adds the component that is bound to our af:serverlistener. You can also add some other components to be refreshed. 

Be careful! This is only a Proof Of Concept. Because in production this can cause your server to be very slow. Just imagine you have 1000 connected clients. In the moment you call the broadcast method, there are 1000 clients, making a request to your server in the same moment. So we created our very own DOS attack :)
If you want to use this, you have to track session information and add them to the queue so you can send a message to only one client.



Freitag, 27. September 2013

Easy reuse of database functions for attribute validation in ADF Business Components

A lot of developers are struggling with check functions stored in their database. This post will show a very easy and declarative way to reuse your existing database functions.

Lets assume we have a check function that returns a simple character as Y oder N based on it's validation outcome. 


This function will guarantee that the parameter string will start with a Sir. This way we can create a validation that will only allow noble employees in our company ;)

The example is based on the HR schema and has only a EO for the Employees table, a VO based on this EO which has one instance in our EmployeesService AM. 
To create our validation we need to get our hands on this DB function. Of course we can start to write our own prepared statement in EmployeesEOImpl.class. But we want to work more declarative and move more pixels. Easiest way to get the return value of our function is to create a SQL query with calls it.


Don't forget to add the named parameter at the query section of our VO.



This new VO can be access by our EO with an simple ViewAccessor. We don't fill the parameter of our checkNameVO within the accessor. This way the accessor can be reused by other attributes.


Now our setup is complete and we can create our groovy script based attribute validation. First we fill the parameter of our where clause and execute the query. We know that our statement will definitely return at most one row, but JDeveloper doesn't. So we have to get the Result attribute of the first element of our rowset.  



To verify our success we can start the application module and test to change the first name of an employee to something without a Sir in the beginning.


This is a very easy way to reuse existing database functions for validating our entity object attributes. Be careful with this type of validation. This way we create a logical dependency between the result of an VO and an EO attribute. So you should consider where to place this type of VOs within your application structure. 

Freitag, 12. Juli 2013

Install JDeveloper 12c on Mac OS X Mountain Lion

To install JDeveloper on Mac OS you need to get the generic installer first. Go to the official Oracle Download page and select generic. http://www.oracle.com/technetwork/developer-tools/jdev/downloads/index.html


I started the installer by invoking my standard Java version by starting > java -jar jdev_suite_121200.jar
And there you go, just go through the installer step by step. Don't be afraid of creating a new oraInventory anywhere and at the question about the user permission, I just allowed everyone to make changes to my new installation since its only to play around.


After the installation I was very exited to get my hands on the new Version and started directly. Unfortunately I only got the message that we need Java 7 now. (Sorry for the German stuff in the pictures)


Looks like we need to get JDK 7 first. This should be downloaded here: https://jdk7.java.net/download.html

After installation we need to change jdev.conf, otherwise JDeveloper still won't start. It's located in your installation directory under /jdeveloper/jdev/bin/jdev.conf 
Open it and find the line where JAVA_HOME is defined and change it to the following path:

SetJavaHome /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home

Should look like this in the end:

 Ok, now you can start your JDeveloper 12c experience ;)

Additional Tip:
Because I have to switch between different JDeveloper Versions, I make use of the -J-Dide.user.dir start parameter. On Mac I create a simple Alias for the JDeveloper.app thats located in the <install home>/jdeveloper directory. Just open it with a good text editor like TextWrangler and add the start parameter to point to your desired USER_DIR for this installation. You even can use different USER_DIR for the same installation this way.




Montag, 28. Januar 2013

ADF Hackers Event Review

Last Friday I went to the ADF Fitness Center aka ADF Hackers Event in Munich, organized by the German ADF Community. It was a impressive and well coordinated event. I was astound about the number of attendants. Nearly 60 people with distinct ADF knowledge who shared their experience. In small sessions about architecture, test driven development and mobile, people where able to ask a lot of questions and open up their horizon. I hope to participate at more events like this.


ADF Mobile Impressions at the OOP 2013

There was an Oracle Developer Day on 24.01.2013 at the OOP in Munich. I went there to tell interested people about the advantages and obstacles of ADF mobile. Most of them were fascinated about the smooth and easy way to develop cross plattform apps with this framework.  Especially in the hands on session. While there is still a lot of room for improvements, this framework is already a real pro for ADF as a whole. 

Thanks to everyone who attended at the OOP.

Unfortunately the slides are in German. Maybe I'm going to post a English version too.

Dienstag, 22. Januar 2013

Create your own ADF Mobile Twitter App with a RESTful Webservice and JSON (Part 1)

When I was at the DOAG conference in Nürnberg, at the end of november, Volker Linz and I were showing a presentation about our practical ADF Mobile experience. Therefore we had a little sample application with some of the more interesting features. Like showing your geo location on a map.
One feature you couldn't miss out, was a twitter integration - why? - because everybody had one in their sample applications. So Volker and I coded at the "hackers lounge" with a few energy drinks. In this post I want to show you, how easy it is to integrate a RESTful Webservice with JSON in an ADF Mobile application.

Let's assume we have a plain little ADF Mobile application with one feature based on a task flow which consists of a single AMX-View. The first thing we need is the connection to the webservice we want to use. In our example we are going to use the twitter GET search API from here https://dev.twitter.com/docs/api/1/get/search.

So create a URL connection and let it reference to http://search.twitter.com.


 Your connections.xml should now look like this.


When you want to see the structure of the JSON String we are going to receive, you can use the HTTP-Analyzer from JDeveloper. See at Tools->HTTP Analyzer and create a new Request. Make sure to make a HTTP Request (tab at the bottom) and choose GET request. For example we are going to get a tweet from OC_WIRE - the OPITZ CONSULTING twitter account. Therefore we have to add a /search.json?q=OC_WIRE at the end of the URL.


Now we have all we need to get this String. Let's create a bean to call our service. We name it Tweets and get the response in the constructor for debugging. 


This should call our service when the bean gets instanced. Therefor we have to add it to our task flow.


To make our task flow useable we have to add a feature in the adfmf-feature.xml and use the task flow as content. 


Now we are nearly ready to test our service call. All thats left is to create some interaction with our bean so it get initiated. Therefore let's create a button that calls some method on the page. I'll use our Button in the second facet and map it to a new method in the bean.


Now we can start out App, push the button an stop the debugger when we receive the response.


And there it is. A response String with JSON formatted Data. In a next step we will parse this string and create a beautiful ListView based on this JSON Data. But that's something for PART II.