It’s documented as a best practice to create reusable Query and Display templates and Business Logic Transactions for an xMII application. This of course reduces the number of files, development work, and programming errors while providing a more consistent overall application. But, in my experience, that has been the scope of reusability in xMII application development.
Let’s look at a portion of a simple MES-type application to use as an example. This example application stores data about production orders in a single table.
The Orders table can be populated with data from an automated process (i.e., IDOC download) or from a user interface. But, more importantly, for this discussion, the data in the table can be manipulated (i.e., inserted, updated, deleted) from multiple user interfaces. For example, the Scheduler may need to assign a production line, shift and sequence to an order or a Line Operator may need to confirm the order has started.
In this example, one would probably identify that the query templates for this application can be reused by creating a template to delete an order, a template to insert an order, and one (or many) to update an order. That is a great start.
Let’s now take a look at an object-focused approach. In this example, an Order is an object. It has a number, a material, a line, etc. If we want our application to insert an order, we need a query template that allows us to do so. The query template will be a simple INSERT SQL statement that takes one Param for each column except for the primary key as this is handled by the database. Now, if there are two (or more) pages in the application that insert Orders to the database, an applet that includes the insert query template needs to be included on each page, right? Well, yes and no. In order to access a query template, the applet containing the query template must be accessible by each page. That, however, does not mean that you must actually type or include the applet manually. I’ll explain how to go about this in a moment.
We’ve already discussed that an Order is an object. So, let’s create a kind of Orders class file. We know that Orders can be Updated, Deleted, and Inserted. And in the xMII world, to do that, we need to use applets. The Orders class file might be called something like orders.js. This file will include the necessary accessor and mutator functions and the applet definitions for the query templates. The order class file might look something like this:
Lines 5, 7, and 9 show the code to include applets to Insert, Update, and Delete. A simple addition to the head section of pages that interact with Orders will provide access to the orders class file. This can be done by using the following syntax.
In this example, an order only has an order number and a material number to keep the demonstration simple. By creating the mutator and accessor Order object functions to accept order objects as arguments where possible, you gain even more control over coding errors. Using these techniques, an function on an irpt page to add an order to the database might look like this:
I leave it up to you to figure out how to detect errors and handle them. I would imagine that you could do some in the Object class file as well as the local irpt pages. In the example above, the variable result will hold true if the insert was successful. If it was not, result will hold an error message created in the Orders class file, which just happens to be the returned message from the getLastError() method.
The purpose of this discussion was to take a different approach to common xMII practices where development efforts are page-focused. By creating some Objects around datasources and APIs to interact with the data sources, application development time should be reduced and result in less errors. In addition, making changes to applications should be much easier because changes need to be made only to the API functions. These techniques do require more thought and effort up front to define the application’s objects, but will almost certainly yield less rework and an overall more robust and stable application.