Tag Archives: development

Triggers’ default behavior in Uniface 10

With the release of patch F205 for Uniface 10.2.02,  the Uniface 10 compiler has changed to ensure compatibility with Uniface 9 for triggers having default behavior. This blog explains when and how Uniface handles ‘empty’ triggers and invokes default behavior.

A small subset of the triggers in the Uniface model (*) falls back on default behavior if these triggers do not contain executable code. A typical example is the On Error trigger for a field or entity. If you do not define the trigger, the Uniface run time engine will still invoke default handling for error situations. If the trigger has been defined with executable code, only that code is executed, and the default behavior is suppressed.

(*) see the Uniface documentation, section “Triggers with Default Behavior” for the complete list of applicable triggers.

When does a trigger *not* have executable code and revert to default behavior?

In Uniface 10, default behavior is invoked if any of the following conditions is true:

  • the trigger is not declared at all
  • the trigger declaration contains no executable code
  • the trigger declaration only contains one or more pre-compiler directives that do not result in executable code
  • the trigger is undeclared.

Some examples:

Uniface Trigger

Uniface Trigger

Uniface Trigger

Uniface Trigger

What is the impact of the Uniface Inheritance model, how to restore default behavior?

Behavior defined in code containers is inherited at ‘lower’ or ‘derived’ levels. Examples:

  • a modeled entity subtype and its fields inherit from a supertype and its fields
  • a component can inherit from a modeled component (called component template in Uniface 9)
  • an entity or a field in a component’s data structure inherits from the modeled entity or field.

Inheritance can take place over multiple levels, but that’s beyond the scope of this blog.

In Uniface 10, inheritance of code in containers is module-based. Code is contained in explicitly-declared triggers, entries and operations.  If a trigger is declared again on the inheriting level, that definition takes preference and replaces the definition that was inherited from the higher level.

To suppress an inherited trigger in Uniface 10, use any of the options described above: declare an empty trigger, declare a trigger with comment only, or undeclare the trigger on the lower level. An ‘empty’ trigger or undeclared trigger will fall back on default behavior if that is applicable for that trigger.

The following table shows some examples:

Modeled Field trigger error Component field trigger error Result
not declared not declared Default error handling
trigger error
end
not declared Default error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
not declared User defined error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
trigger error
end
Default error handling
trigger error
if ($error = 0105)
… some code
return -1
endif
undeclare trigger error
end
Default error handling

What has changed since patch F205?

With the solution for Issue # 31689 in patch F205 (Uniface 10.2.02), explicitly-declared triggers that are effectively empty now fall back on default behavior, if that is applicable for that trigger.

Before this patch, an explicitly declared trigger in Uniface 10 without executable code or with comment only would not only break inheritance, but also suppress its default behavior. Prior to F205, the only way to ensure that default behavior was invoked was to not declare the trigger or to undeclare the trigger. In case of inheritance of a trigger from a higher level, the only way to restore default behavior on the lower level was to undeclare the trigger.

What has changed since patch F206?

In patch F206 the automatic migration logic in Uniface 10 was changed to benefit from the modifications in patch F205.

Before patch F206, the migration would attempt to assess whether a trigger container coming from Uniface 9 with potential default behavior contained comment or entry declarations only. If so, the trigger would be commented out or undeclared. This approach was not watertight and had a few disadvantages, like adding code during the migration (‘code pollution’) and causing additional compiler warnings compared to Uniface 9.

When migrating a Uniface 9.6 or 9.7 export file into Uniface 10 after installing patch F206, all triggers, including those with potential default behavior, are migrated ‘as is’.

Patch F205 is compatible with code migrated into a Uniface 10 using a patch prior to F206, i.e. there is no need to redo the migration. However, if you want to benefit from the changes in the migration, you should migrate after installing patch F206 or higher.

Uniface Mobile Supporting Latest Operating Systems

Last month, the Uniface mobile team added support for the latest mobile operating systems (OSs) available in the market. Since both Apple and Google have released new versions of their latest OS, we wanted to make sure that Uniface mobile apps can be run and deployed on them.

So from now on, Uniface customers can run and deploy their mobile apps on Android OS versions from 4.4 up to Android 8.0 Oreo and on iOS from iOS 8.0.0 to iOS 11.0.0. To take advantage of the support for the new versions, all that customers will need to do is recompile their apps using Uniface and Buildozer.

For us, adding support for the latest mobile OS means making sure that a Uniface mobile app successfully runs on all these above-mentioned OSs and a Uniface mobile app can be deployed on these OSs. If a mobile app is not compatible with a mobile device’s OS then Google Play or the App Store would filter the app from the ‘app to install list’ making it difficult to deploy on that device. To verify these scenarios, we developed our own mobile app and tested it on all the platforms in the product availability matrix.

The Uniface previewer app’s latest release is an example of a Uniface mobile app which can be run and deployed on iOS 11 and Android 8.0.

Uniface Previewer app
Uniface Previewer app

I would also like to mention that now we have made our apps forward compatible for both Android and iOS. To illustrate, here is an example:

  • a Uniface app is built and deployed on O.S ‘x’
  • a user device goes for a system update
  • this results in upgrading the OS to ‘x+1’
  • the Uniface app would continue to work on the later OS.

Personally, I really enjoyed working in this project. This gave us a better insight of a mobile app development and deployment cycle. We hope our customers find this as useful as we do.

SCRUM to strategically win from the competition as pit stops do in F1

Congratulations to Max Verstappen on winning the Malaysian Grand Prix last weekend. You see, strategy pays out when everything falls into place.

Uniface Formula 1

So, my drive 😉 is to apply scrum in your business strategy to win the race too.

So in F1 the pit stop, besides being a masterly synchronized ballet of disciplined execution and expertise, the pit stop is used strategically by the team to win the race. How? The amount of pit stops depends on the desired lap time while gauging fuel consumption, tire wearing out, undercutting (taking over a car while making the pit stop or leaving one). With the above in mind the team determines to use certain amount of pit stops, or to add one more in order to win.

In SCRUM terms, the sprints are the perfectly synchronized production of software which can be strategically used to deliver value to our customers. Whether we deliver features gradually or change the order of delivery as to meet business value.

Here at Uniface, we are busy trying to get SCRUM to the next level where alignment between business and IT are essential to make a difference. We must be aligned to adapt to change and therefore better serve our customers. In that context, we already have a track record as we have been using SCRUM for more than 9 years and have done the necessary improvements to the processes ourselves.

As an example, we have even invented our own ceremony to facilitate the alignment among teams called  a Sprint Pitch (an already 3-year-old ceremony for us).

To stress why aligning the business with IT is important, I want to emphasize the analogy from the F1 championships; I was inspired to use it when watching a Red Bull documentary about “The history of the pit stop” during my last flight.

You know the thrill of changing tires and refueling the car in the shortest amount of time possible?

In the early days, the pit stop was just a pause that took up to a minute, there was no changing of tires. That came in the 1970’s when an unplanned pit stop to change tires would take 3 to 5 minutes. In the early 1980’s Gordon Murray turned them into the strategic pit stops, considering the car weight, the tire degradation and saw a relation on how all that influenced lap times. At that moment another race began, the one to bring the pit stop’s time down to the minimum. In order, to use the pit stop more strategically and make the time necessary for a pit stop negligible.

Well, it is no surprise that to reach the shortest time, it took analysis, collaboration, improvements to get to the changing of the tires or better even the entire wheel set and refueling the car, cooling the car’s engine in just under 2 seconds. Bear in mind that actually it takes a crew of 18 to 20 highly skilled individuals to handle a pit stop.

You may wonder how do we do that in SCRUM at Uniface, but first time for a pit stop … (to be continued)!

Uniface’s use of Authenticode

In this blog post I discuss how Uniface uses Authenticode for signing Uniface executables on the Windows platform. A word on the merits of signing your executables. Code signing is nothing more than taking an executable and calculating a checksum, attaching that checksum in a cryptographically secure way to the executable. This way any customer can be assured of the integrity of the code they download from Uniface’s download server: it has not been tampered with nor was it altered while in transit. The use of a public-private key certificate from a reputable vendor adds the advantage that you can rest assured the code you downloaded really originated from Uniface.

Designing code signing requires you to take a step back revisiting your existing processes to identify potential issues. Any statements on the integrity of the code can only be satisfied if you manage your code signing keys in a defined way. We have a defined process of managing where keys reside, who has access to them and what people having access can do. Keys reside in a physically secured location, with access being controlled and limited to a small group of people in the company. Only these people can get their hands on the Uniface code signing keys for a limited set of defined purposes. Strict logging is in place so that key usage can be reviewed from audit logs.

The Uniface build factory consists of machines, that take source code from a version control system and run the build scripts to produce signed executables. The code signing is run directly from our makefiles. We use a set of ‘internal’ certificates when building Uniface. Machines that are part of the Uniface build factory have access to the ‘internal’ certificate and physical access to the build machine is limited. Only Windows executables that were produced in an official build can thus be signed using this ‘internal’ certificate. The certificate is only valid within the Uniface development lab. Outside the Uniface development lab a machine with Windows installed would lack the Uniface development lab ‘root’ certificate, which is needed to build a trust chain required to validate executables signed with the ‘internal’ certificate. Once we package a Uniface q-patch, patch, service pack or distribution, we also sign these deliverables. This effectively seals the package and protects its contents from unauthorized modifications.

We also timestamp all files, which means all signed files also carry an official counter signature with a timestamp. Should there be an irregularity, forcing us to withdraw our software, we can do this by revoking our certificate. This comes in two flavours: Either we fully revoke a certificate, or we revoke the certificate from a certain cut off timestamp. When the certificate is fully revoked, all files signed with this certificate become invalid and hence cannot be trusted anymore. If the exact moment in time when the irregularity occurred is known, we can revoke the certificate from this moment in time. This results in all files signed after this moment to become invalid. Files signed before this moment in time remain valid.

When we decide that a package is ready for shipping to our customers, we go through a process of re-signing such a package with our ‘external’ certificate.  This is done as part of the publication process. What we do is check every file in the package to see if it was signed using the Uniface ‘internal’ certificate. If a file was signed with the ‘internal’ certificate, it is resigned using our ‘external’ certificate. This ‘external’ certificate was obtained from a reputable vendor and the public key of the root certificate from that vendor is present in every Windows distribution. Hence using public-private key encryption, your Windows distribution can check that files that we have signed in our Uniface distribution have not been modified since we signed them and that the software is actually from us. So the next time you install Uniface, you can be sure the software is fine.

Technology Highlights Google Cloud Next 2017

Google cloud next-2017 The largest Google developer and IT gathering in Amsterdam to explore the latest developments in cloud technology. A chance to engage with the foremost minds leading the cloud revolution and learn how the modern enterprise is benefiting from the latest in cloud technology in unprecedented ways. As usual for us one more way to keep up with technology.

We saw some very interesting new innovations (spanner and app maker to name two) and how they relate to application development in the cloud.

Given below are the other highlights of the technologies talked about during the event:

1) Microservices & Kubernetes:

Microservices – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. It enables the continuous delivery/deployment of large, complex applications and enables an organization to evolve its technology stack and can develop and deploy faster. It’s an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components.

The emerging combination of micro-service architectures, Docker containers, programmable infrastructure, cloud, and modern Continuous Delivery (CD) techniques have enabled a true paradigm shift for delivering business value through software development.

The combination of microservices and containers promotes a totally different vision of how services change application development.

Kubernetes – is an open-source system for automating deployment, scaling and management of containerized applications that was originally designed by Google and donated to the cloud native computing foundation. It aims to provide a “platform for automating deployment, scaling, and operations of application containers across clusters of hosts”. It supports a range of container tools, including Docker.

Technology Highlights in Google Cloud Next 2017

2) Choosing the right compute option in a cloud project: a decision tree

To understand the trade-offs and decide which models are the best fit for your systems as well as how the models map to Cloud services —Compute Engine, Container Engine, App Engine, cloud functions.

Compute Engine is an Infrastructure-as-a-Service. The developer has to create and configure their own virtual machine instances. It gives them more flexibility and generally costs much less than App Engine. The drawback is that the developer has to manage their app and virtual machines yourself.

Container Engine is another level above Compute Engine, i.e. it’s cluster of several Compute Engine instances which can be centrally managed.

App Engine is a Platform-as-a-Service. It means that the developer can simply deploy their code, and the platform does everything else for them.

Cloud Functions is a serverless computing service, the next level up from App Engine in terms of abstraction. It allows developers to deploy bite-size pieces of code that execute in response to different events, which may include HTTP requests, changes in Cloud Storage, etc.

Technology Highlights in Google Cloud Next 2017

3) Big data – Big data refers to data that would typically be too expensive to store, manage, and analyse using traditional (relational and/or monolithic) database systems. Usually, such systems are cost-inefficient because of their inflexibility for storing unstructured data (such as images, text, and video), accommodating “high-velocity” (real-time) data, or scaling to support very large (petabyte-scale) data volumes. There are new approaches to managing and processing big data, including Apache Hadoop and NoSQL database systems. However, those options often prove to be complex to deploy, manage, and use in an on-premise situation.

Cloud computing offers access to data storage, processing, and analytics on a more scalable, flexible, cost-effective, and even secure basis than can be achieved with an on-premise deployment.