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.
A common adaptation of xMII development, specifically with applets and JavaScript, is to think about functionality at the page level (.irpt or .htm). What is the purpose of a specific page? What data is being viewed or maintained on a specific page? Well, what if we took a step back and instead of focusing at the page level, thought more about the objects that an application uses. This short blog will present some ideas around creating reusable JavaScript objects and functions to facilitate quicker development of data source activities including inserts, updates, and deletes. The concepts are not meant to be an absolute method of development, but rather an idea that might have a place in your environment.
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.
The scheduler’s page will need an iCommand applet to update the line, shift, or sequence of the orders. And, the operator’s page will also need an iCommand applet to update the start time of an order among others. Depending on the situation, it might be possible that the iCommand applet on both pages uses the same query template. To interact with the iCommand applet, JavaScript is used to pass HTML form field information form the web page to the applet and ultimately into the database. In my experience, continuing with the page-focused development, one would create (sometimes identical) JavaScript functions on each page to handle the update of data. So best case, the application already has two identical applets with two different JavaScript functions. Do all of the functions handle errors the same way? Are there any business rules being enforced in the functions? Are they enforced the same way? Imagine how many applets and functions will be in the completed product continuing with the page-focused development effort.
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.
By including the orders.js class file on each page that interacts with orders, you now have access to the same functions and applets and queries throughout your application. No longer will you need to write redundant JavaScript functions on multiple page.
In addition to this technique, JavaScript also supports user-defined objects. We have already created an Orders class file, but we can go one step further and create an actual Orders JavaScript object. The Orders class file will be a good spot to place the Orders object constructor. 
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.
2 Comments
