Category Archives: Blog

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:

if (HEIGHT.PERSON < 0)

HEIGHT.PERSON = 0

endif

 

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:

BMI.PERSON = WEIGHT.PERSON/$sqrt(HEIGHT.PERSON)

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"

   TOTAL.ORDER += PRIZE.ORDERLINE * NUMBERITEMS.ORDERLINE

endfor

 

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 

endif 

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.

Uniface

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.

IMG_1190
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

PR

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.

Cognac

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.

When thinking Desktop “first” still matters (Part 2)

By Clive Howard, Principal AnalystCreative Intellect Consulting

Read Part 1 Here

Great experiences are not just for mobile

In an era of high user expectation and the demand for great user engagement, Application User Interface (UI) design has never been so important. We’ve heard this message before of course, when the virtues of Web 2.0 and Rich Internet Application were espoused in the mid 2000’s and browser based applications along with the proliferation of smartphones, tablets and mobile apps cemented that reality.  Many organisations have now caught up and are starting to realise that users demand more usable experiences and providing them can have productivity benefits. The results can often be seen on a business’s bottom line or through competitive advantage. I worked on a call centre application where improvements to the User Experience (UX) dramatically reduced call times and improved the quality of data collected. This led to efficiency within the call centre and improved outcomes for both the business and the customer. Costs were reduced and customer satisfaction rose.

In a desktop first world designers will still need to provide users with great UX. At the same time they need to appreciate the potential for different end user form factors. Application interfaces will need to adapt to alternate screen sizes. The modern desktop could be a traditional 20 inch monitor or a 10 inch touch screen. Where the desktop application spawns mobile apps they will need to have consistency with the desktop experience. A user should be able to move from desktop to tablet to mobile very easily because the app experience is familiar to them. This is best achieved if the original design considers the possibility of mobile from the beginning.

Plan for a “multi endpoint first” future

For all of those development professionals out there who have spent their careers building desktop applications their future should be secure. But they will need to adapt their skills, thinking,  tools and possibly their processes to a new world in which mobile may not always be first but will be relevant. Many desktop applications will remain installs but many others will be delivered via a web browser. Equally for the IT decision makers they need to think about investments that are not just about mobile. It is very easy in the current climate to think that the future is mobile and therefore investing in mobile only platforms is the way to go.

Instead they need to consider that the desktop is going to be around for a while and they need to invest in platforms, tools and skills that will support a broad portfolio of applications. Essentially this comes down to being efficient with the code base. Not replicating code should always be a core aim. Creating code that can be tested at all levels of the stack should be a further key ambition; making the functions of that code base available through services to multiple end points should be another. With a services based architecture, the application may be spread across both the company data centre and public cloud environments.

Where development moves to being Agile, development will need to work with Operations in order to speed application changes into production. This will most likely mean embracing a DevOps culture, processes and tools. The modern desktop app will require more regular updates than the old fashioned quarterly release.

There will certainly be many situations where a mobile first approach will make sense in future. Studies show that people are accessing the internet more from mobile than desktop and so for websites mobile first will probably be a good idea in the majority of cases. However, the future will be a combination of mobile, tablet and desktop experiences. Developers and organisations will therefore need to consider each application and in some cases it will make sense to go desktop first.