Category Archives: Blog

Experimenting with the AWS S3 API

Last month I uploaded a community sample that showed how to call an Amazon Web Services RESTful API, in particular for their S3 storage service.  That sample is contained within a single form, and is accompanied by some simple instructions and notes on assumptions made etc.  I used a form component type, and constructed it to use operations for the actual API calls, so that it would be easy to understand, and easy to modify to a service component, for wider usage.

The next thing I wanted to try was to provide the same functionality from a DSP.  Initially this could have meant replacing the Windows GUI layer with a HTML5 based layer in a DSP.  However, DSPs make the Uniface JavaScript API available, and thus there is an opportunity to try out the AWS SDK for JavaScript (in the Browser).  Information is available at http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-intro.html .

The main advantage of using this SDK is that becomes possible to avoid a lot of low level coding with the RESTful API.  If you study the form sample I mentioned earlier, you will see a lot of code to build canonical requests, and then to sign them securely.  This is all buried inside the various SDKs that AWS provides.  This was worth a try!

As it turned out, coding the JavaScript to list the bucket contents, download and upload files, was relatively easy.  In particular, the feature to generate signed URLs for downloading files is very handy.  In fact most of the buttons on the sample DSP have browser side JavaScript which calls the AWS SDK without much reference to the Uniface JavaScript API.  This just means that in some circumstances you might not need to use DSPs at all, but if your use case does involve exchanging information with back-end processes, then this sample should be of interest.  One such use-case is to save S3 files on the back-end server, and so a JavaScript activate is done to send the signed URL to a DSP operation, to complete the download.  In any case, it is tidy to keep the JavaScript code in the Uniface repository as much as possible.

So … although the JavaScript coding turned out easy enough, the challenge turned out to be how to authenticate the SDK calls.  In the form sample I used the AWS Access Key ID and a Secret Access Key to sign requests.  These were quarantined from the form source code, and the runtime user (who shouldn’t have access to the Uniface debugger), by storing the sensitive data in assignment file logicals.  Not the ultimate form of protection, but adequate for my sample.  The JavaScript SDK requires access to these artifacts, and since this runs in the browser, it exposes them to all users.  To slightly obscure these private values, I placed them in a separate JavaScript file, which is not referred to in the HTML, but dynamically loaded by Uniface with this statement:  $webinfo(“JAVASCRIPT”) = “../js/aws_config.js” .  Of course you can read the variable contents with any browser debugger.  So this DSP sample comes with a similar caveat to the AWS recommendations.

The options for supplying credentials to the AWS JavaScript API are described here:   http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html .  So for my sample I did effectively supply hard-coded credentials for an IAM user that has read-only permissions.  Real applications will want a more secure method.  I was going to evaluate AWS Cognito, but it is not yet available in my region.  Another option to investigate is to use Temporary Security Credentials, via the AWS Security Token Service.  Further discussion on authenticating credentials is beyond the scope of this blog / sample.

One final security configuration had to be made, because the sample is running within a browser, which is likely to be enforcing CORS.  This is best explained in the documentation at http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html#Cross-Origin_Resource_Sharing__CORS_ .

To summarise, Uniface developers have a choice when integrating with AWS.  They can choose the RESTful APIs for lower level control, in a wider set of situations, or they can use the JavaScript SDK for easier integration when using the Uniface JavaScript API.

Windows XP – another nail in the Coffin

I recently read this article about Chrome 50 stopping support for some older operating systems, and the mention of Windows XP caught my eye. 

From a Uniface perspective, we stopped supporting Windows XP in May 2014. Purely from a technology perspective, it freed us up in regards to choices on MS Visual Studio and even how to implement certain functionality. I’m sure in the Uniface source code there is still code that states ‘if Windows XP’…! 

Getting out and about, talking to customers, I’ve had a few conversations about Windows XP, mainly in the context of browser support and Internet Explorer 7, as in the big WWW, it’s pretty well out of control what OS, and what browser an end user can use. (Although I do remember this article about an Australian online retailer who was going to add an IE tax for their transactions.) 

Something that has come up during conversations has been customers who are doing business in China, where there is still a significant amount of Windows XP use. I’m assuming that this is related to how easy it was to bypass the MS licensing model and the availability of older specification hardware which might struggle to run a new version of Windows. 

I’m expecting that with Chrome soon to stop supporting IE, that will start to accelerate the move away from Windows XP, and I’m guessing some of the hardware manufacturers will be rubbing their hands with the anticipation of a peak in new hardware sales, and the recyclers are preparing for more obsolete hardware to be stripped for precious metals. 

And on a personal note, it appears I need to buy a new Mac for use at home, as I’m also impacted by Chrome 50 not supporting my version of Mac OSX! 

Uniface 64 bit deployment for Windows

During the deployment session from the Uniface Lectures, we covered Uniface 64 bit deployment for Windows in the morning session (not in the afternoon because it took to much time, the videos are available to watch on our YouTube channel though). 

We had a few really interesting questions, I’ve worked the answers into the text below and I dug up an old posting from the old Frontline site, and used that as the basis. 

The oldest Uniface PAM (Product Availability Matrix) I could find was from Uniface 6.1, and with that old version we  delivered 64 bit support on DEC Alpha hardware with Uniface 6.1. OpenVMS, and DEC Unix ports of Uniface. I remember seeing one of the DEC Unix workstations here in the Amsterdam Lab, running the Motif GUI and thinking how advanced it was, how fast it was and I wanted one. Always dangerous to wish for more, I ended up with a Mac on my desk a week later. 

For a number of releases we focused on Uniface server versions for 64 bit, think IBM AIX, HP-UX, Intel Titanium hardware and so forth.  

It was in 2012 that we delivered a 64 bit Windows server version, delivering it in Uniface 9.5.  

It took us a long time, and to be honest, I recall have a few conversations on the topic over the years, and from an out and out technical perspective, the view was that there were few perceived benefits when compared to the 32 bit version to justify the investment to make it happen. I should mention that we had done some clever things with compiler switches to enable memory addressing for a number of releases. 

A Windows 64 bit Uniface client was a different story, and was quite a significant project.  Clearly there were overlaps with the Windows Server (technically they share a lot of common source), but the GUI layer needed a lot of work. We had to refactor a lot of code, as we had a lot of legacy (technical debt) from older versions of Uniface. The name Uniface originated from Universal Interface, and it was possible to develop one Uniface app and deploy it on those old GUI platforms which we used to support thanks to the Uniface specific widgets such as the unifield.  (I’m sure some of us who have been around Uniface for a long time remembers Uniface on Mac, Motif, OS/2 and Windows 3.x.)  There was a lot of old code to clean up and/or remove, and we also have to keep those legacy widgets operational. 

A few additional challenges included our use of automated test tools which didn’t support 64 bit platforms, which also forced our journey to replace them and use Ranorex for our testing. (I’ve covered this in the forums and talked at a few user groups on this topic.)  

We delivered a Windows 64 bit client with Uniface 9.6 in December 2012. We’ve had some good feedback, I recall talking to a customer in the UK, and their comment was that it just seems more ‘fluid’. I talked about this with one of the architects, and the view is that this is probably as a result of the refactoring, possible the additional memory capabilities, but it’s great to get positive feedback. 

It’s available for deployment rather than development, as we have a few external pieces of functionality in the developer, for example the DSP Editor which are not available as a 64 bit product. 

The HTML control we delivered in Uniface 9.6 is also currently restricted to 32 bit. But this will change, it’s based on Chromium (sometimes know as CEF) from Google, and the sources were (finally) updated to 64 bit and we have been working on getting that into Uniface 9.7, and will be part of the Uniface 9.7.02 update which we are finalising. That was a challenge to get working, changes to threading models and API’s meant some rework and lots of testing, but it’s pretty well code complete. 

The Uniface 10 IDE uses that same HTML control extensively, so the move to CEF3, now opens the way to deliver a 64 bit developer. There will be a significant Uniface 10 release in September, but this is something for another posting next month.    

 

Uniface Modernization: Modern buttons are flat

New button properties are welcome

During the modernization of IDF 9.7 it became clear that 3D buttons could not be used anymore. Windows has gone flat and all the office applications as well. So we needed to address this with some simple properties on the command button widget. The defaults stay untouched even though the new properties make the button more appealing. So we don’t break the look and feel of the existing applications but open the possibilities to a modern user interface.

Properties explained

These new properties make the difference and allow the UNIFACE developer to change the looks of the entire application in a wink. You need to set the button representation to “UNIFACE” is you want to make use of the new properties.

Uniface

With the new properties we were able to completely mimic the Windows 8 tiles as well as the common flat buttons.

Some examples

In the following example the “Transparent” property is set while the button is placed on a form with a very colorful image. Not very user friendly, since it looks like a label, but it shows the possibilities.

A button with transparency set to TRUE.

Uniface

The following table shows a button with an image which is styled in different ways:

Uniface

New property value

Unifac

During the modernization of IDF we missed the option to create big buttons with an image big enough to fill up the button. The “imgsize” property has a new value to accommodate the workspace buttons in IDF.

Uniface

Example the UNIFACE Journey planner

If we start making changes to GUI widgets or the GUI driver, we always look to other applications and try to make the user interface in UNIFACE. For the buttons I took the Android application made by the Dutch national railway company NS. With the new button properties we could mimic the user interface completely. Following picture shows the UNIFACE Journey planner which uses flat buttons.

Uniface

To make designing the application more easy, I created logical widgets with the necessary properties, so I was able to paint the Journey planner very quickly. Creating the logical widgets was some work but after this you can develop an application following a certain theme. You can paste the following buttons into you usys.ini to get the looks as shown in the sample.

pltimebutton=ucmdbutton(representation=uniface;transparency=true;forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=2;font=SansLarge)

plheadbutton=ucmdbutton(representation=uniface;backcolor=#ffcc33;transparency=false;forecolor=black;frametype=bottom;framecolor
=#dcab1e;framewidth=5;font=SansHuge)

plplanbutton=ucmdbutton(representation=uniface;backcolor=#3395e4;transparency=false;forecolor=white;frametype=bottom;framecolor
=#1762cc;framewidth=5;font=SansHuge)

pldepariv=ucmdbutton(representation=uniface;backcolor=#1b8ee1;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=4;font=SansHuge)

pldfromto=ucmdbutton(representation=uniface;backcolor=white;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=#272775;frametype=off;framecolor=;framewidth=1;font=SansHuge;imgsize=img_xlarge;halign=left)

I hope this helps you in creating modern looking UNIFACE applications and modernizing existing applications.

Uniface Training Modules offer more Flexibility

With the development of faster and even better Uniface software there was clearly a need for better and more flexible and efficient Uniface education and training. With the release of Uniface 9.7 the training materials were revisited, redesigned and partly redeveloped. The input from many Uniface consultants during and after the train-the-trainer session, conducted in October last year, seemed invaluable.

The training materials have been developed in a more modular way to even more meet the needs of our customers and enable a more flexible delivery. Three tracks have been defined. The courses can be delivered as classroom training or over Web, using the CloudShare® platform.

This blog briefly describes the available tracks and modules for these trainings.

After having successfully completed the two days Uniface Essentials, there are three options. Each option takes three days to be completed.

Uniface Training Modules

  • The Uniface Essentials training focusses on the model-driven and component-based development and will equip students, new with Uniface, with the necessary basic skills to develop software applications with Uniface. Students will be prepared for the next module. The Uniface Essentials module is a prerequisite for the Uniface Mobile, Uniface Web, and Uniface Client Server training.
  • With Uniface Mobile students will learn to develop responsive applications that can be deployed on mobile devices and tablet computers. Attention will be paid to some supportive frameworks for building responsive applications.
  • In the Uniface Web development class students are taught how to develop Uniface applications by building Dynamic Server Pages for the Web. All aspects of stateless software development are covered in this course. Some attention will be given to HTML5, and CSS3.
  • Uniface Windows Client means building application for the Windows platform.

For each module students are encouraged to make a number of exercises to become more acquainted with the specific topics covered in the training modules. There will be enough time to ask questions, for discussion, and the exchange of ideas and information to optimize the learning process.

Besides these trainings, where students will learn the basic skills, more advanced topics and techniques can be covered in custom made trainings. These customized training are delivered on customer demands only, and can be geared toward specific customer situations.

For questions, comments or remarks about Uniface training please contact uniface.training@uniface.com, or download this fact sheet with more information.