This is an occasional blog about IET's use of CA Gen for internal development as well as thoughts, tips and techniques on using CA Gen for application development. It is aimed at the CA Gen development professional, so please excuse the jargon and assumed level of knowledge about CA Gen. Reference will also be made to our products to put the development into context, so if you are not familiar with these, please visit the IET web site by clicking on the company logo.
Gen GUI logic allows you to invoke an event handler via a USE of a dummy action block called TIREVENT. For example, to invoke the event handler called "CLICK_LOGIC" you could define an event called "CLICK" in the window and then invoke it as follows:
SET temp_tirevent.ief_supplied.command TO "CLICK" USE tirevent WHICH IMPORTS: temp_tirevent.ief_supplied TO Work View in.ief_supplied
This use of a dummy action block TIREVENT has always seemed a bit strange and unnecessary, so for a Rapide application, you can now invoke the event via an API call:
A new feature in Rapide allows you to define an auto-suggest field.
In the example below, the entry field for a country is supported by an auto-suggest list that shows the list of countries that start with the current value of the field.
Unlike a drop-down selection which has to contain a fixed set of data and which, if triggered by a keypress event, would slow down typing in the field, the population of the auto-suggest can be handled by an asynchronous thread in the client p-step and hence the data could be retrieved from a much larger dataset (for example from a database table via a server or web service) without affecting the user's ability to continue to type in the desired value.
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.
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.
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.
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
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.
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.
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.
We have recently been working on a project to convert a Windows GUI application to a browser. The application allows the user to open multiple instances of the same window to detail a customer record.
Viewing multiple windows on a desktop application is common design approach, but this does not translate well to a browser or mobile application because a browser does not have the same window switching facilities of the Windows desktop and mobile interfaces do not support multiple mode-less windows.
A new feature in Rapide called Multiple Instance Tabs provides the solution. They allow multiple instances of the same window or dialog box to be opened at the same time in separate tabs. An example from the Rapide Controls Demo is shown below. Each tab is an instance of the same detail procedure step but instead of appearing as separate windows, they are displayed within a tab control.
Converting a multiple detail window design to a multiple instance tab is quick and easy and requires very few changes to the model.