Inline Code Example

In CA Gen the in-line code statement allows you to enter native code without needing to create an external action block. 

In genIE we have a requirement to create a UUID which for the C clients was implemented in an external action block.

The equivalent implemented for Java using in-line code was very simple and only took a few seconds to code.

Managing Web Services

CA Gen Studio provides an option to define custom web service interfaces to server procedure steps. You can then use Gen Studio to generate the WSDL and XSL files for the web service and then assemble these into a WAR file for deployment to an application server.

We were recently asked by a GuardIEn customer whether they could use our XOS (External Object Support) add-on to manage the generated WSDL/XSL files so that as they promoted a change through the life-cycle, these files could be 'migrated' to the next environment along with the object migration of the procedure steps.

Whilst this would have been possible, it raised an interesting point about whether generated code should be copied between environments or re-generated from the model in the next environment,

I don't think it is a good idea to copy the generated source code from an uncontrolled environment like the first development model. The reason for this is that the state of the model and in particular the synchronisation between the model and the generated code is difficult to establish. This is especially true for code generated from the toolset, since it could be generated without uploading the changes to the encyclopaedia, or the model could be changed without re-generating the code.

At IET we recommend that the Gen objects are migrated to the next environment's model(s) as part of a controlled 'system update'. When using GuardIEn, the automated impact analysis will ensure that all of the code affected by the migrated objects is regenerated and installed. Generating direct from the encyclopaedia ensures that the model and generated code are synchronised.

A further complication arises because the web service definition can contain interfaces to multiple procedure steps. The wsdl and xsl files are tied to the import and export views for the procedure step and need to be regenerated when the procedure step's interface changes. What happens if you have a web service for multiple procedure steps, change the interface to two or more of them and then only migrate one of the changed procedure steps to the next environment? If you copy the entire web service, the result is that interface definitions in the web service do not match the view structure for the procedure steps in the next environment.

It therefore seemed a bad idea to copy the generated wsdl/xsl files from the toolset and the same principle of re-generating code from a stable model should be adopted. The problem though was that the web service generation feature of CA Gen was only available from Gen Studio and not the encyclopaedia generation.

In consultation with the customer, we decided that the best approach would be to develop a new web service generation feature in GuardIEn so that the web services could be properly managed via re-generation from the model as part of a GuardIEn system update. This new feature is now available in the latest service packs released yesterday.

Updating Mobile Apps

Whilst we would hope to never have any serious errors in our applications, it is a fact that no matter how much testing is done, there will be some bugs in an application, especially for complex business systems.

Having fixed the bug you will naturally want to release it to the end users as soon as possible, especially for high priority issues that might stop the app working or even cause data corruption.

For web based applications this involves a refresh on the application server. GUI clients can also be quickly updated using a variety of methods. But what about mobile apps that are distributed via a public app store and where the updates need to be approved by the app store vendor before they are released? This can take some time - for example over a week is common.

If you develop your mobile apps using Rapide, because the client logic and UI definition resides on the application server and not the device, a refresh of the app is as simple as deploying an update to the app server.

As long as you do not change the app branding (name, icon, splash screen or app server URL), the application can be updated without needing any refresh on the mobile device.

More choices for using CA Gen to develop your UIs

I was invited to present Rapide at the recent COOLUp event in the Netherlands. Whilst the audience seemed very impressed by the product, one of the questions asked why we had decided to make a considerable investment in developing a new front end capability for CA Gen. 

What lay behind this question was an assumption that most CA Gen sites are no longer considering using CA Gen to develop new applications and some are considering moving out of Gen. 

What followed was an interesting discussion about the use and position of CA Gen within many organisations. The reality is that most sites that still use Gen have a considerable investment in applications that are still meeting the business needs, are very stable and are usually maintained by a small team of people. 

The result of this stability and low staffing levels is that often management are unaware of the scale and complexity of the Gen systems and the good value that these systems provide. It is only when they accurately estimate the cost of replacing the systems that the true value is understood, at which point the sensible business decision is to stay with Gen. This is why many sites are still using it today.

The problem that can result from this is that Gen remains in a state of suspended animation - the applications remain and are maintained, but Gen is still not viewed as a strategic or even tactical development tool. The development organisation then does not make sufficient investment in the tool to maximise the benefits that they could derive from their considerable investment in the technology, skill sets and the models that have been developed over the years.

Coming back to the original question as to why we have developed Rapide, the answer is that we wanted to provide Gen users with greater choice and more reasons to stay in Gen.

Whilst Gen is incredibly strong in the development of back-end server and batch systems with industry leading capabilities for developing robust, scalable, platform independent applications, it is generally acknowledged that the front end capabilities of Gen are not as capable, which had lead some sites to use other options for developing the user interface.

At IET we feel strongly that the best way of developing applications is to use Gen for developing both the user interface and servers. It is much more productive and maintainable, but in the past has required you to accept the limitations of Gen's user interface capabilities.

We wanted to give Gen users an option to use Gen to develop robust, multi-platform UIs with Gen including mobile and web, and this was the main reason for developing Rapide.

You can now use Rapide to easily migrate existing Gen block-mode, GUI and web applications to a more modern and responsive user interface for a fraction of the cost, effort and risk compared with re-writing the application in another technology.

Drag and Drop

Many users will be familiar with the operation of drag and drop between controls or between applications.  

Rapide now provides drag and drop support for controls within the application as well as full text transfer between applications on desktop applications.  For browser applications, Rapide also provides support from dragging files from the native OS (such as via Windows Explorer) into a Rapide control, automatically transferring the dragged files to the AppServer.

The Rapide Designer is used to define whether a control can act as a Drop Source or Drop Target, or indeed both for the same control.  The Designer also allows you to specify whether to support Copy and/or Move operations.

Various events are triggered during the course of a drag and drop operation, for example when the object is dropped onto the target and at the end of the drag operation.

The Rapide Controls Demo has an example of using Drag and Drop.

Rapide App Server Console

When we recently started a series of web seminars we wanted a system to allow attendees to register for the seminars, receive a calendar reminder and also be able to view recordings of past events.

Since the first four events were on Rapide, we decided to create a new event management system using Rapide. Whilst this is a simple application, it demonstrates some of the powerful capabilities of the product, including frames, row templates and placing images into listbox rows.

Instead of running the application in a traditional application server like JBoss or WebSphere, we decided to use the in-built OSGi server that comes with Rapide. However one issue that cropped up with running a production application was the ability to see who was currently using the system. We wanted to know this so that if we decided to deploy a new version of the application, we could do so without disrupting any users who were currently logged on.

This have rise to a new feature in Rapide called the Application Server System Console. The console lists all of the sessions currently active, when the session was started and last accessed as well as the current p-step name, platform and browser/mobile device version.

The console is available for use with both the OSGi server and also if a Rapide application is deployed using a traditional application server.

It also allows the administrator to prevent new users logging on and also to send messages to currently active users, for example to inform them that the system is about to be updated.

READ Cursor Properties

One of the properties of a READ statement is the control of cursor generation:

When set to the default value of Both select and cursor, the generated code will first perform a SELECT statement, and if the sqlcode indicates that this resulted in multiple rows, it will then fetch the first row using a cursor.

In the situation where it is likely that more than one row will be returned, this will result in a wasted initial SELECT, so the code will be more efficient if the property is changed to Cursor only and thus avoid the expense of the SELECT.

Similarly, in the case where there can only be one row returned, for example when qualifying on the identifier or a cardinality one relationship, the generation of the cursor results in a larger memory requirement, code size and additional processing for compile and bind steps. In this situation, the code will be more efficient if the property is set to Select only.

For example, using this example data model:

The statement below should have the property set to Select only since a CHILD can only have one parent.

Whereas the statement below which checks to see if a parent has at least one child should have the property set to Cursor only since they can have many children. 

A refinement to the check would be to leave the property as Both select and cursor in this situation of a parent has a average of one child.

IET have developed a check in VerifIEr which will validate the correct and optimum setting of this property. The initial version of this check is for a READ statement that qualifies using a single relationship. In the future we may extend this to cover more complex READ statements. The VerifIEr check also contains a genIE 'Fix' that enables the property to be reset to the optimum value.