Category Archives: Blog

The Future of Programming May Not Involve Coding

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 1 in a 2 part series

It is perhaps ironic that we live in a time when governments and many others are calling for young people to be better educated with regards to writing code, yet at the same time the software development industry is requiring developers to write less code. Microsoft’s Azure App Service or’s Lightning are recent examples of new tools that aim to eliminate code writing from the process of developing an application (desktop or mobile).

The principle of this approach is not new and tools such as Uniface have long aimed to increase developer productivity and application quality by reducing the number of lines of code that need to be written. The terminology, approach and experiences have evolved and differ but the aim has remained the same.

Even in the world of code writing the popularity and growth in frameworks from .NET to JQuery have sought to reduce the amount of code written. As has tooling like Integrated Development Environments such as Visual Studio and Eclipse. For example, tools provide drag and drop controls with properties windows that mean a developer can add a control to a screen or web page without writing the underlying code. We saw this in Visual Studio, Adobe FlexBuilder and others. Perhaps the question is why it has taken so long for low-code development environments to see wider adoption?

Making the complex simple is a challenge for tooling

Part of the reason may be technology. It is inherently difficult to make the complex process of writing applications into something that can be done in a way that involves no or little code. Modern applications are incredibly complex, often using multi-tier architectures and integrated with other applications. Creating a visual development experience that can work with these complexities and provide the myriad possibilities that the modern developer requires is inherently challenging. Changes in technology have made it easier in recent years.

The wide spread adoption of the API economy and the proliferation of micro-services has changed application architectures and exposed capabilities in more simplistic and easy to consume ways. Let’s take a rather modern concept such as mobile Push notifications. Each mobile platform (iOS, Android and Windows Phone) implements this capability differently and it involves a degree of complexity and quite a bit of code to manually create. Instead there are a number of services exposed as APIs (Web Services) that abstract all of this complexity and allow developers access to the capability via a few simple calls.

By basing these APIs on common programming concepts such as RESTful Web Services and JSON formatted data it allows development tools to more easily create a further level of abstraction that means developers do not need to write the few lines of code required to work with them. SOAP made consuming any service from within a development tool even easier as the WSDL allowed tooling to auto introspect and understand any service. REST is not as simple but is now widely accepted as the way to build modern services. Modern tools are finding ways to make working with RESTful services very simple.

Part 2 (coming soon):  Developers: I’m better than you and I need my code

Where to put your code

As a Uniface developer, I’ve seen a lot of Uniface applications first hand. On more than one occasion I encountered a situation where developers put all their code in the component. This happened for a number of reasons—access to the model or the library was constricted, there wasn’t enough time in the project to do it correctly, or just unfamiliarity with Uniface. I cannot speak on behalf of project managers or architects, but I can tell you how I code my projects.

The first rule of Uniface is that you do not copy and paste! (Very obvious movie reference!) If you find yourself in a situation that you think you need to copy code: stop! You are probably better off removing the code from its original source, putting it in either the application model or the library, and then reusing it in both the original component and the component where you wanted to paste it.

Single field implementation

Consider the following:





A person can never have a height that is smaller than 0 meters. Maybe there are people with a negative size, but I have never seen one. So if someone enters a negative value we reset the value to 0. If you were to put this in a component, than you need to copy and paste it the next time you need it. Remember the first rule? So where would you put it? The most logical place would be in the trigger of the modeled field HEIGHT in the PERSON entity. Creating an entry on entity level and then calling it from the leave field trigger would score equally well. This way the inheritance in Uniface will provide this piece of code in every component you use the field on.

Multiple field implementation

On record level

But what about two fields in the same entity? The formula for the Body Mass Index of a person would be:


The content of BMI is calculated by dividing the WEIGHT by the square root of a person’s HEIGHT. In order to calculate the BMI we need the value of two different fields in the entity PERSON.

If you thought about putting it in the modelled entity you’d be correct. I would create an entry that can be reused in (for instance) the value changed triggers of the WEIGHT and HEIGHT field or call it from a collection operation if you wanted to update all the BMI’s in some type of batch.

Between entities

Here is a classic. The total amount of an order is calculated by multiplying the price by the number of items in an order line, and then adding that to the total of the order. :

forentity "ORDERLINE"




The second rule of Uniface (you can actually here the voice of Brad Pitt, can’t you?) is that you never make a reference to another entity from a modelled entity. If you do, you need to include the referenced entity on every component you use the modeled entity on or the compiler will keep wagging its finger at you.

So we can’t reference the TOTAL.ORDER field in the trigger of the ORDERLINES entity. The only logical place is to put it in in a component. In this case, I would put it in a service that can be called from other locations as well. I can even activate that service in the modelled trigger of the ORDER entity.

What if it is a non-database entity?

Non-database entities come in two distinct flavors. The modelled ones and the non-modelled ones. An example of a modelled non-database entity is the entity containing a list of buttons containing default behavior that you can reuse when creating components. With these particular non-database entities the same rules apply as for the modelled database entities.

Non-modelled entities are created on the fly on a component. In this case there is only one place to put your code. The component level.

And non-database fields?

Non-database fields, have the same distinct flavors. They are either modelled (for instance a button that shows detailed information about a certain record of a modelled entity) or the non-modelled ones. If the non-database field is in the application model, code it there, otherwise code it in the component.

When I mention the component, there are actually three levels where to place your code. In the triggers of the component, in the triggers of the non-database entity, or in the triggers of the non-database field. Based on the previous rules you should be able to determine the correct position.

There is no entity or field reference

Once more for good measure:


if ($status < 0)

   return $status 


This code contains no field references and is of a more technical nature. This is an example of the smallest form of error handling in Uniface. If you intend to use it only once, the component is the best place to put it. If you need it in other places, you should move the code to the library and include it where required.

Can I use A Global Proc, instead of an Include Proc?

I have not used a Global Proc since the introduction of Include Procs. In my mind it is a deprecated feature of Uniface. From a component based development perspective Include Procs are better (but that is for another story). Besides using Global Procs for error handling purposes has one drawback. What happens when your Global Proc fails? Where are you going to catch that?

Let’s Summarize

Description Logical place
Code references exactly one field in one modeled entity Trigger level of the modelled field
Code references more than one field in one modeled entity Trigger level of the modelled entity
Code references more than one modeled entity In the component, preferably a service.
Code references a non-modeled entity If a non-modeled entity is used more than once, it should be defined as a modeled non-database entity. If it is a very specific non-modeled entity, it can be only in the component.
Code does not reference a field or an entity. Include proc. Never in a global proc. Component only, when it is really specific.



Using Agile Beyond Development

Those who follow me on Facebook or Twitter will know that I recently traveled to Brazil on what turned out to be one of the busiest trips I think I’ve even done, but it was also one of the most inspirational for a couple of reasons. The most pertinent being a trip to see Bravi in a city called Florianopolis in the south of Brazil. Bravi currently provides outsourced Uniface services, but the thing that really struck me wasn’t anything related to Uniface, it was their use of the Agile methodology throughout their entire company. We have used agile for a number of years to develop and maintain Uniface, we’ve presented it both at Uniface and (non-Uniface) industry events, and as a product manager I’m really a fan of what it brings.


I’d never contemplated using it elsewhere, but I can really see the value it brings from a flexibility (agility?) perspective, and also the visibility it brings within the organization to help make sure people are aware and informed. I really like that it means information, status, etc, are available and those that are interested have the information available.

Bravi’s kanban board they use for HR

Next steps, we’re going to start using it in a couple of departments, we’ll start by keeping it quite simple, using kanban boards, probably one financial year will be a sprint, and a whole lot more to think about yet. We’re planning on changing our internal systems this year, and once done, a phase two could be to move to online systems. Some interesting times ahead.

Uniface gets to work in the Martell cellars

Pernod Ricard


A world leader in Wines and Spirits, Pernod Ricard have 90 subsidiaries and 100 production sites in 80 countries. The company was founded in 1975 and has 40 years of innovation, excellence and a portfolio of prestigious products. The group’s strategy currently focuses on the “Top 14” premium brands including Chivas Regal, Jameson, and Absolut.

The Challenge

The challenge for Pernod Ricard was to develop a mobile application, available offline, intended to manage and inventory all spirit barrel movement by scanning their barcodes, then synchronizing post-clearance data stored in SQLite embedded database with the Central Oracle database.

Digitalizing the processes

In 2012 the group’s IT systems were to be digitalized and Pernod Ricard looked to develop mobile functionality for the management of their cellars.

The cellars are considered having an “explosive atmosphere” (ATEX regulations) and may not be equipped with either Internet or Wi-Fi. It is, therefore, essential that the mobile devices work offline on an embedded database and then synchronize that database afterwards with the central system.


Uniface: Technological expertise serving mobility

Equipped with Uniface for over 20 years, we continue to help Pernod Ricard meet their needs when business or technical issues require their intervention.

“Implementing the offline scans, for example, required a very sharp and pointed expertise for which we preferred to turn to Uniface,” Jean Jacques Delavaud, Head of Competency Center.

Working with Pernod Ricard, we developed an embedded SQLite database solution and our team developed a specific driver enabling the two systems to integrate.In May 2015, both the driver and the new version of Uniface were delivered and the Pernod Ricard teams are in the process of creating a prototype.

Supplier Relationship Management tool

A Supplier Relationship Management tool is already under development. Which allows providers follow their delivery status, billing information or even trace their last sample.

Pernod Ricard can then use this to gather information on projects, activities, provider issues, and better target projects to attract customers and build loyal relationships. Such successful solutions will give the group a significant competitive advantage in an increasingly complex and volatile economic environment.

By Fall 2015 the mobile application should be fully operational in two of the group’s companies for the management of more than 6.2 million barrels.

You can find out more about how Uniface helped Pernod Ricard here.

10 things you need to know about Uniface 10

Working on a product like Uniface 10 feels a bit like the movie Oceans Eleven. A team of highly skilled professionals get together to pull off a feat that is considered undoable, or at least quite difficult to achieve. In fact there are quite a few similarities between the teams working in Amsterdam and the guys in the movie (Although me being Brad Pitt isn’t one of them, apparently). For instance the team working on Uniface 10 consists of people, each with his or her own unique skill set, working towards a common goal. There are lead-characters and supporting cast and everything.

But enough about us, what about Uniface 10? The first thing you will probably notice, besides the fresh white paint instead of the dull gray, is the UBAR, an explorer-type address bar that lets you open your editors. The other thing that jumps from the screen is the tabstrip. A horizontal ribbon bar showing all the open editors, allowing you to switch easily between entity, component, and other UDO’s.

A UDO, short for Uniface Development Object, is something we use in the lab to indicate a Uniface element (entity, field, component, library, and so on). These UDO’s come in two distinct flavors – UDO’s and main UDO’s. The difference? Main UDO’s have their own editor.

Before you can start creating these UDO objects you need to create a project (also a UDO). In my mind one of the better features of Uniface 10 is the ability to organize your work in… well projects. Something I really hated doing was having to verify that all my changes were compiled. Sometimes I would just compile all from the command line (not an option if the application contains over a 1000 components). Just put everything in a project and hit compile. It is even possible to export the entire project and share it.

The Integrated Development Environment or IDE for friends (we dropped the term IDF) also allows you to use snippets in your code. Put your favorite piece of code (HTML, CSS, JavaScript or Uniface code) in a snippet and copy and paste into the wee hours of the night. We will provide you with some of our snippets but feel free to create your own.

Just as in any other film there are some characters that will not make it to the end of the movie. For instance the (pirate voice) URR file is no longer part of Uniface. I have always had great difficulty understanding the Uniface Runtime Repository and am glad to see it go. Seeing it off with a bonfire made from my URR notes and the documentation. The UAR deployment option is the way to go from now on.

The removal of the application model entity from the meta dictionary hit me a little harder. In Uniface 10 the application model is just a namespace. Need to move an entity from one model to another? Just rename the model part of the entity name. So be careful, especially with typos.

We pulled all the triggers. And replaced them with script containers. From now we will supply you have with a Declaration container and a Script container to write your ProcScript in. Just for good measure we will give you three containers in the entity editor (Declarations, Collection and Occurrence). But that’s it. Want to create a trigger? Just use the keyword trigger in the same fashion you define an operation or an entry. Just to raise the stakes a little we have renamed the trigger names to make them more uniform.

What else do you need to know? Well the first version is an early adopter version. We are still working on a lot of stuff, that will be made available in future release. For instance there are no library elements yet. So you have to do without include procs, messages and such. But we just couldn’t wait to show you what we have done so far.