text:
|Publication number
|Publication type
|Application number
|Publication date
|11 Jun 2013
|Filing date
|29 Dec 2009
|Priority date
|29 Dec 2009
|Fee status
|Also published as
|Publication number
|Neil Thomson, Grzegorz Roman Pusz
|Original Assignee
|Microgen Aptitude Limited
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (37), Non-Patent Citations (13), Referenced by (5), Classifications (7), Legal Events (4)
|External Links: USPTO, USPTO Assignment, Espacenet
The invention relates to form-based applications and related areas.
The present specification describes features of a new product known as Microgen Aptitude V3.00. This product is a development of Microgen's earlier Aptitude product which is described in U.S. patent application Ser. No. 11/341,156 (publication no US-2006-0247805-A1) and corresponding European Patent Application No 06100913.0 (publication no 1,686,466), the contents of which are incorporated herein by reference.
Aptitude is a program with a graphical interface which allows users to create complex applications without knowledge of traditional programming languages.
The invention provides a method of creating a form-based application using a computing device having at least a processor, a memory, a display device and an input device, the method comprising:
The invention also provides a computer programmed to perform a corresponding method, and a computer readable medium containing computer-readable instructions for performing a corresponding method.
The invention also provides method of deploying a form-based application to a web server comprising:
The invention further provides a method of creating a form for a form-based application using a computing device having at least a processor, a memory, a display device and an input device, the method comprising:
In order to provide the reader with a full understanding of the context of the invention we have included here a description of many different features of Microgen Aptitude. However, we direct the reader particularly to
An Aptitude Project (a single development and deployment unit) is created by a user of the Aptitude software (hereinafter also referred to as a developer), in order to define a final Aptitude Application which is then used by an end user. The Aptitude Project contains the following elements designed as application building blocks:
1) An Application Diagram, which is a diagram describing the navigation of an end user through the final Aptitude Application, in a modeless manner;
2) One or more Application Forms—each form comprising one or more User Interface Pages containing the pages' layouts and a tree-like diagram defining modal navigation between the pages;
3) One or more Application Form Templates, each Template being a definition of a part of a User Interface Page; and
4) User Interface (UI) Preferences, which define a set of CSS (Cascading Style Sheets) classes customizing the look and feel of a web page and its elements.
The Application Generator allows a user of Aptitude (ie a developer, as defined above) to create applications in which an end user can navigate between a number of forms and services, as illustrated in the example of
We refer to "modeless" navigation between forms, which allows the user to go from one form to any of a number of other forms. We also refer to "modal" navigation in which a form has one or more child pages, each of which opens on top of its parent. Any changes made by the user on a child page are not accepted until the user confirms the changes on a parent page. In the Application Diagram such child pages are not forms, but instead each form may represent a hierarchy or collection of (modal) pages, all of which can be used to modify a single data object. Thus the Application Diagram does not become cluttered by the child pages of modal forms, but remains clear and simple for the developer to use. Indeed to keep the Application Diagram even simpler, some services are not shown in the diagram, for example if the service has no input or output or just processes form data.
The forms and services are themselves built by the developer by manipulating icons and links within Aptitude. The links between the form and service icons represent both the navigation path of the end user and the flow of data between the forms and services. The Application Diagram defines an application which will ultimately reside, together with the forms, on a web server, whereas the services ultimately reside on an Aptitude server, as will be described below.
The following Aptitude Project elements are shared with the Services implementation:
The Application Diagram 2 is a crucial element of the Application Generator. Its general function is to define the navigation between forms (eg. 4, 6, 8) and services (eg. 10, 12, 14) in the front-end application (which resides on a web server). To understand how it works one has to look at it from the deployed application user's perspective. When a user types a web address into an internet browser he/she enters the application. This moment is represented by the Enter block 16 in the Application Diagram 2. From that moment the user navigates through the application along the links (eg 18) between the icons. Two important blocks on the diagram are:
Each form icon or block (eg 4, 6, 8) is associated with only one data object relating to all data associated with that form. We could say that navigating along the diagram links means displaying the pages in a modeless way, in that the pages are displayed one after another and all changes made by a user in one of them are committed before the next page is displayed.
Here we describe a second feature of the diagram 2—it also represents the transition of the state of the user session. For every end user that enters the Application a user session is created to store his application state. The user session (or application session) contains:
1. an instance of the application diagram (or actually a place in the diagram where the user currently is);
2. a Data Object representing the last known state of the last page the user has visited, the Data Object being stored in the user session; and
3. user security: name and roles (in cached mode)
The state of a user session is initialized in the Enter block 16 and includes an instance of the Data Object assigned to that block. Then the Data Object instance is passed to the next block along the link. Each block in the diagram can be treated as a routine modifying that instance or converting it to the instance of a different Data Object. We could easily imagine that the diagram depicts a flow of data representing the state of a single user session. Each user session relates to exactly one point of the diagram. There are as many instances of the application diagram as the number of users who have entered the application.
Other Blocks of the Application Diagram include:
The Application Diagram allows a developer to generate both web and desktop applications. The Application Diagram defines not only the user navigation between Forms but also the transition of the data introduced/modified by the user and the services (user session state).
We next describe features of the application forms.
An Application Form can be a simple Page or a hierarchy of Pages comprising a Root Page, such as that shown in
An Application Form (even if it contains a whole hierarchy of Pages) stores and/or displays its data in and/or from one Data Object instance.
The hierarchy of Pages are called in a modal way (one page is displayed on top of another). Such a hierarchy modifies the common Data Object instance in a transactional way (in that either all changes to all pages are committed or none are). All the Pages modify the same Data Object instance but only the Modifying Output of the root Page commits the changes in a permanent way.
The buttons, links or menu commands in the form are represented as outputs of the Form Block (eg 4, 6, 8) in the Application Diagram 2.
A single Page includes the layout of the form controls, as illustrated by the "Person List" form shown in
An Aptitude Form has the following features:
a) It defines the user interface page layout;
b) It defines which handlers (i.e. services) are called in response to actions of the user (such as pressing buttons on the page). Some Form Blocks (eg Form Block 4 in
c) The form may consist of a hierarchy of modally called pages constituting a single user transaction on the Application Diagram.
We have described two different navigation types, namely modeless and modal navigation, which are now further explained. The more natural is modeless navigation, typical for web pages. The user displays one page after another but never two at the same time. However there are cases when while displaying one page he wants to see another one at the top of the previous. Typical examples are details pop-up dialogs (in desktop applications) or user messages dialogs (e.g. with "yes/no" question). Such modal dialogs usually modify the data displayed on their parent form and in this way they constitute a user interaction transaction because the data changes are committed when the parent form is submitted. From such a form the user cannot easily navigate to another form. He may pop-up another modal dialog creating a whole stack of opened dialogs, or he has to close the dialog coming back to the form underneath.
Considering these two different display strategies and data modification approaches Aptitude splits the navigation into two different diagrams. The Application Diagram 2 represents all the modeless navigation between the Forms. Modeless navigation between pages may be described by a graph so a diagram is the best choice. On the other hand the modal calls create stacks so the description of all possible modal calls between the pages always shape into a tree like graph. Moreover from the data modification perspective all modally called dialogs modify the same set of data before committing the data to storage. Such a stack of modally called pages looks like one block called from the Application Diagram describing a modeless navigation between forms. For this reason an Aptitude Form is not just a single Page but it describes a tree-like graph of a set of pages which are being called modally.
Aptitude also provides Application Form Templates, which define the layout of controls on a page. A control is something which can be reused, such as a button or a header.
An Application Form Template looks similar to a Form's Page and defines the layout of the form controls. It is not assigned to any Data Object and does not contain the data binding and events' handlers assignments. The data binding and event handlers assignment is done when the developer edits the Page. All properties of controls in a Form Template (except the size and position of the controls) may be changed by the developer on a particular Page which uses the Template. Changes made to a Form Template's controls can be automatically propagated to all Pages which make use of that form template if the developer so chooses. The user has two options (which are available in a menu in Aptitude):
1. From an opened Form Template he can amend the Form Template and then update all the Forms containing the Form Template; or
2. From an opened Form he can amend the Form and then update the Form Template on which the Form is based with any or all of the changes to the Form.
Such a Form Template may be used to implement the common layout of particular parts of all forms.
An Application Form Template contains a partial definition of a user interface layout that, rather than being traditional controls on a form, defines the set of controls without data binding and user interactions' handlers. Such a template must be attached by the developer to the data specific for the particular Form it is used with, and may be additionally customized from the Page it lays in.
We next describe security features of Aptitude. Aptitude provides declarative role based security in which roles are declared in the Aptitude Project.
The Security in the Project is completely abstract and thus is easy to use by business users. The binding between the declared Roles and physical roles is done during the application deployment.
Using the menu items "Project Property-Application Definitions" available within the Aptitude Studio software, the user can set the Security technical binding. Currently Aptitude supports three technologies: LDAP; Out-of-the-box database solution; and Custom Library
LDAP is a centralised security system used by Microsoft and others, which allows different security levels to be given to different people across a number of applications. Aptitude can take the security information from LDAP in order to match the security levels in LDAP with the Roles in Aptitude. More generally, the Roles in Aptitude can be mapped to different security levels in another application; thus allowing users of the other application having different security levels to be automatically allocated corresponding Roles in Aptitude, or vice versa.
The Role Based Security is independent from any particular technology giving Aptitude the ability to integrate with any existing solution.
We next describe deployment of the application. The Application Deployment is based on the fact that the front-end Application is implemented without using any particular programming language or technology. Referring to
The deployment is done in two steps:
The deployment can be done in two ways:
We could say that the deployment package is just the intermediate language serialized to the files. So we always first generate the intermediate language and then from the intermediate language we generate the application. The intermediate language can be serialized to the file and distributed in this form to the client site and then picked up using AptCmd to generate the application. The intermediate language is a technology independent description of the application graph plus the description of the forms and all other application elements.
Aptitude is able to generate either or both of the following two parts of the system:
The Front-End Application is deployed to a Web Server such as a Microsoft IIS web server 42 (which uses C#) or a Java Tomcat web server 40 (which uses Java). The Services 44 are deployed to the Aptitude Application Server 46. As shown in
The Intermediate Language as a deployment intermediate product gives Aptitude the ability to deploy the front-end Application using any User Interface technology. Currently, two web technologies are supported: ASP.NET (IIS) and JSP/JSF (Tomcat, JBoss). No traditional programming languages are required by the developer, as all the programming can be done using Aptitude.
We next describe a functionality of Aptitude which we refer to as Transaction Regions.
Sometimes it is important to exert transactional control over a number of operations, so that either all of the operations are completed successfully or none of the operations are completed. In such cases the transactional control ensures that it is impossible for only some of the operations to be completed successfully and for others to fail.
Aptitude uses a collection of icons or blocks, each representing an operation or "node", to define the processing of data for a process in Microgen Aptitude. The process may relate to any field, including engineering or business. As an example our discussion focuses on business processes, although the concepts are equally applicable to engineering processes. In Aptitude a Business Process is a segmentation, or division, of a process flow consisting of Nodes; it may consist of the complete flow or, more usually, is divided into a set of nested business processes. The latter is preferable as it adds little or no additional performance overhead and can make the diagrams much easier to understand. Aptitude delivers a complete Business Process Management layer allowing nested business processes and rules. The same Business Process may be used as a standalone process and as a part of other processes.
The Nodes in the Business Process represent different stages where various operations and/or transformations can be performed on data. These nodes are connected using links to create a diagram that represents the complete business process. Using the Business Process toolbox, the developer can drag-and-drop the nodes onto the editor screen.
The links represent the flow of data and are added by the developer; each link has its corresponding Data Object.
Within business processes, Microgen Aptitude has a concept of transaction regions that can be used to position "roll back" points within a business process.
A "Transaction" in Microgen Aptitude is a set of operations which must all be conducted successfully by a group of nodes as a result of the processing of one or more messages. An Aptitude Transaction is atomic i.e. all operations of the transaction have to be executed successfully in order for their results to be permanently stored (ie committed). Aptitude Transactions provide the complete set of generally used properties, guaranteeing reliable transaction processing, called ACID for atomicity, consistency, isolation, durability. We define a group of nodes that define a Transaction as a "Transaction Region". When processing a message (or record), if any of the operations within the Transaction Region fails, then all operations belonging to the transaction may be rolled back (ie the operations are undone and/or their results are not stored) and the whole Transaction fails, at least for that message or record.
We pause for a moment to discuss terminology. The term "record" usually relates to databases and to flat data, while a "message" can be hierarchical. "Record" should be used when talking about flat data (ie a one-dimensional array of attributes or columns) e.g. when talking about data to be written to a single table. Records are therefore appropriate for Aptitude Rules where data is flat within a particular rule. Data processed in Aptitude Microflows (which are graphical flow charts, which may be business processes) is usually hierarchical. The correct term for "message" would be "Data Object instance" or "Data Format instance" but these terms are quite long so we sometimes use just "Data Object" or "message" for short.
As will be explained later, Aptitude can process data messages individually (Straight Through Processing (STP) Mode) or in batches. Such batches of messages can be either Logical Batches (eg all messages relating to one division) or Transactional Batches in which the user decides that a certain number of messages will be grouped to form a Transactional Batch which a Transaction Region then treats as a single Transaction. It is possible for the developer or user to set the "Execution Error Handling" mode of each Transaction Region, and this mode determines what happens in the event that an error occurs in the processing of a Batch (as will be described much later in connection with
Aptitude provides a graphical representation of such Transaction Regions which makes the Transaction Regions easy to identify and manipulate by the developer. Aptitude also introduces the concept of transaction initiating nodes and transaction boundary nodes. An Aptitude Transaction Region is defined as all nodes that receive directly or indirectly the messages from a transaction initiating node up to the transaction boundary nodes. A transaction initiating node is either:
A transaction boundary node is any one of the following three types of node:
For each of these three types of nodes the developer can check (ie tick) or uncheck (ie untick) a Transaction Boundary Node option, which is made available for example when the developer double-clicks on the node. This option controls whether or not the node functions as a transaction boundary node. No other nodes have this option, and so no other nodes may be set as transaction boundary nodes. (A final Target node, such as those shown at the end of
Each transaction boundary node starts another Transaction Region. In Aptitude a Business Process can consist of many Transaction Regions.
Transaction Regions are displayed to the developer in the diagram of nodes/icons and links on the computer screen during Business Process development. The scope, ie area, of each Transaction Region is generated automatically by Aptitude, based on the presence of the transaction initiating and boundary nodes mentioned above. However the developer can also merge or split Transaction Regions.
Data within a single transaction region is processed without any storage or roll back points allowing for optimum throughput and performance (ETL-like very high speed). This is because storing the results of operations takes time, and therefore by not storing the results as data passes through the Transaction Region time is saved, and processing is speeded up. In the event of the failure of an operation during processing within a single transaction region the processing may roll back to the start of that region in order to reprocess the data. (Not all Execution Error Handling modes involve rollback—for example the "Continue Processing" mode discussed later).
The Business Process of
The Business Process of
Note that the Match & Merge node 210 lies in both the first and second Transaction Regions 200 and 202. This is because the Match & Merge node 210 is both a transaction boundary node and (therefore) also a transaction initiating node.
Aptitude selects different colours for the different Transaction Regions in order to graphically represent each Transaction Region to the developer in the most clear manner. Furthermore this graphical representation occurs automatically, without the developer having to think about where Transaction Regions begin and end. The developer simply creates the process by arranging the icons/nodes and links, and the Aptitude software takes care of indicating the Transaction Regions in a graphical manner.
By specifying a number of transaction regions within a Business Process the developer defines a number of storage points. The act of specifying a node as a transaction boundary automatically create a storage point at that node, even if the node itself is not a storage node. Data is stored automatically at the final node (ie the transaction boundary node) of each transaction region (regardless of whether that node is a storage node) so that it can act as a roll back point in the event of processing failure within the next transaction region. That is, if there is a processing failure within the next transaction region it is possible to use the data stored at the storage point to reprocess at least the data which has failed to process properly. Once all of the data in a transaction region has been processed it is no longer necessary for the data to continue to be stored at the storage point at the beginning of the transaction region, and the processing can move on to the next transaction region. This provides the user with quick error and problem resolution.
Every Transaction Boundary Node, for which the "Transaction Boundary Node" option is checked, is a storage point in a Business Process, i.e. the entry or exit node within the Transaction Region. Every Transaction Boundary Node starts a new Transaction Region by default.
Two Transaction Regions can be merged by the developer to form one single transaction region that contains all nodes that previously belonged to the two transaction regions. To merge two Transaction Regions the developer simply unchecks a Transaction Boundary Node option for a particular node contained within the two Regions. If the developer unchecks the Transaction Boundary Node option for a storage node then the storage node simply transmits the data without storing it. This possibility has been left mainly for consistency, so that the developer can check or uncheck the Transaction Boundary Node option for any of the three types of node which may act as a Transaction Boundary Node.
Similarly a single Transaction Region can be divided into two Transaction Regions by creating a new Transaction Boundary Node somewhere within the original single Transaction Region. This could be done for example by checking the Transaction Boundary Node option of a node in the original single Transaction Region, or by adding a Transaction Boundary Node, for example a Storage Node.
As described, nodes in the Business Process can be defined as transaction boundary nodes—storage points used for roll back in the event of processing failure. Storage nodes are one example of transaction boundary nodes and indicate points in the Business Process where data should be stored internally.
Internal data can be stored in two places:
Using a storage node automatically creates a transaction region (if the Transaction Boundary Node option for the storage node is checked).
Only Grouping Nodes, Storage Nodes and embedded Business Process Nodes can be set (by the developer) as Transaction Boundary Nodes.
In case of execution errors the records are rolled back to a Transaction Boundary Node and kept in internal Berkeley Db storage (or an external database).
The data stored internally can be viewed using an Internal Data interface provided in Aptitude Studio for a deployed Project (the end user simply right clicks on a deployed Project and selects Internal Data). A "deployed Project" here means a project which has been compiled and deployed to Aptitude Server. Business Processes defined in Aptitude project are executed within Aptitude Executors, started by Engines and controlled by Aptitude Server. In contrast, the Aptitude project part defining a web application (containing forms/screens) is compiled into ASP.NET or Java (JSP/JSF) code and deployed into the web server.
The Internal Data Interface is a part of Aptitude's failover and recovery functionality. We next describe Aptitude's failover and recovery functionality in more detail.
The failover functionality implemented in Aptitude consists of three layers:
The Data Recovery mechanism allows recovering data of the broken Business Process execution. Data recovery can be carried out only when the project stores node internal data permanently. Data recovery usage can be switched on or off by the end user in the project configuration. During the project startup, no matter if the startup is a result of a restart after a failure, depending on the configuration settings, the internal data can be removed from the internal storage, can be processed or can be omitted in processing.
During processing of a batch, the internal storage initially contains the whole batch and then the messages are removed when they are processed successfully. If there are no errors in the whole batch, it is completely removed from the internal storage when the batch processing is finished. In case of error, the message remains in the internal storage with the "error" status.
If the processing stops as a result of a power failure for example, the project may be restarted automatically by Aptitude Server. This is controlled by the "Automatic restart after failure" execution property visible in
When the whole project (including all its Microflows/Business Processes) (we note that in Aptitude V3 the term "Microflow" replaced "Business Process", but both terms are used to refer to a diagram representing a message processing, with a set of nodes representing operations) is restarted either manually or automatically (the latter if the "Automatic restart after failure is set"), then there are three options concerning how the internal data is handled:
If an error happens because of some external reason e.g. there is no corresponding account number in some table, then the error will need to be fixed outside of the Aptitude project. However the automatic restart and recovery options are intended to be used for the situation when the execution breaks because of a power down, machine failure or fatal program error for example. In such cases, the important thing is to process the unprocessed messages from the internal storage, as otherwise some of the messages would be lost. Any messages in error will then be handled by users as usual when the processing is resumed. The whole project execution stops only in the case of power/fatal errors or when the "Execution error handling" setting for a Transaction Region is set to "Stop microflow execution". The user can then examine the internal data (using the Internal Data Interface) before the project is re-started. The user can correct the internal data contents if this is needed (e.g. for the failed data). After examining or correcting the internal data contents with the Internal Data Interface, the user can re-start the project manually.
If the Business Process configuration requires data recovery (ie. if "Internal data handling" is set to "Recovery" as discussed above) all Transaction Boundary Nodes in each Transaction Region read the unprocessed data from the internal permanent storage. This unprocessed data is used for the state initialization of these nodes. After that phase, the Executor executes all unprocessed data.
The developer is able to set some execution parameters for every transaction region. In the Aptitude Project this is possible on a Business Process Properties/Execution Properties screen. Even after deployment the user can change them in a Configuration Settings file. The following example parameters are available:
For the convenience of the developer all of these parameters and some more can be modified globally for the whole project (also available in the project and in the configuration settings).
The Transaction Regions in Aptitude provide the following features and advantages:
We now describe functionality of Aptitude which we refer to as Hierarchy Transformation. Many data objects have a hierarchical structure. A simple example is a family, where a parent may have several children who each have several children, and so on. There may be many such families, each representing an "instance" of such a family data object. Such a hierarchical data object has a structure which is a "weakly connected directed graph" and which we may refer to as a "tree graph". This is because a tree is a structure which may have several branches, each of which has several branches, and so on. We refer to each branch of such a tree graph as a "segment" or "node". Typically we have a root segment which has one or more subordinate segments, each of which may have subordinate segments, and so on. In general there may be zero, one or more instances of each segment. To return to our example of a family, we may have a family called "Smith" which is an instance of our family data object. An instance of the root segment may be, say, John Smith. There may be, for example, three instance of the next (child) segment, say Tom, Alice and Jim. Each child may have zero, one or more instances of the next (grandchild) segment, and so on.
Hierarchy Transformation in Aptitude is a graphical means of transforming one tree graph into another tree graph, without the developer needing knowledge of any programming language. (We refer to "developer" in this description of Hierarchy Transformation, as distinct from the end user, because the Hierarchy Transformation produced by a developer can be compiled into executable code for use by an end user.) Hierarchy Transformation exploits concepts which will now be defined. These concepts are easier to understand when considering the example of
We first introduce the concept of a Data Format.
A Data Format is a directed graph, which can be a tree graph, the nodes of which are called Segments, where one (ie the uppermost) Segment is distinguished as the Root Segment.
A Segment represents a node in a Data Format tree graph.
We next introduce the concept of a Data Format Instance.
A Data Format Instance is an instance of data which has the same format as the Data Format. A Data Format Instance is a tree graph that is compliant with a Data Format. By "compliant" we mean that each route in the Data Format Instance starting from the root node of that tree can be walked-through in the tree graph of the Data Format Instance starting from its Root Segment. The nodes of a Data Format Instance are called Segment Instances.
A Segment Instance represents a node in a Data Format Instance.
Hierarchy Transformation is a concept that facilitates transformation of one Data Format Instance into another Data Format Instance. Hierarchy Transformation involves the following components:
1. An Inbound Data Format (as mentioned above).
2. An Outbound Data Format (as mentioned above).
3. Segment Links.
The example of
4. A Segment Links Tree.
Referring again to the example of
A Segment Links Tree is therefore a directed tree graph the nodes of which are Segment Links. The Segment Links Tree defines the Hierarchy Transformation. This tree graph is defined by the developer, but by default its structure is determined by the structure of Inbound Data Format. The transformation is performed by executing the Segment Links in accordance with the Hierarchy Transformation algorithm of
Although the Segment Links Tree is illustrated in
5. Segment Processor (SP)
Each Segment Link is provided with a Segment Processor, which for a single inbound Segment Instance (i.e. an instance that matches the Segment Link's Inbound Segment Path) in the current Input Context (the concept of Input Context will be defined later) produces zero, one or more temporary outbound Segment Instances (i.e. temporary instances that match the Segment at the end of the Link's Outbound Segment Path). These Instances are also referred to as "SP production" in the discussion which follows and, after creation by the Segment Processor, these temporary instances (SP Production) are used by the Segment Link during its execution according to the Link's Operation Mode (see below).
These concepts will become more clear when the example of
6. Operation Mode of the Segment Link
Each Segment Link has an Operation Mode, which can be one of the following:
a) Insert Mode
In this mode the SP production (ie the temporary outbound instances created by the SP) is/are inserted under the current Output Context (the concept of Output Context will be defined later).
b) Update Mode
in this mode the developer can specify a Matching Key, by means of which the SP production is matched against already existing outbound Segment Instances under the current Output Context—if such Instances exist, they are updated with the values in the SP production.
c) Insert/Update Mode
This mode is the same as "Update", except that those temporary outbound segment instances (SP Production) for which no matching (existing, ie not temporary) outbound Segment Instances were found are simply inserted under the current Output Context.
d) Delete Mode
This mode is the same as "Update Mode", except that the matching outbound Segment Instances are deleted (together with their subtree) from the current Output Context.
e) Select Mode
This mode is the same as "Update Mode", except that the matching outbound Segment Instances are not updated but just selected in order to position the Output Context for the Segment Links that are subordinate to the one that is currently being executed.
f) Replace Mode
This mode deletes all the outbound Segment Instances (and their subtrees) under the current Output Context, then inserts the SP production under the current Output Context.
Two further options available within a Segment Link are:
1. Input Filter:
This allows optional filtering out some of the inbound Segment Instances fed into the Segment Link (in the current Input Context) before they reach the Link's Segment Processor.
2. "Take Children" flag:
If the graph under the inbound Segment is identical to the graph under the outbound Segment, the developer can set this flag on, in which case—during transformation execution—all the Segment Instances under the Input Context will be copied to every outbound Segment Instance affected by SP production (under the current Output Context).
The "Family" structure is to be transformed by the Hierarchy Transformation into a "Nationality" structure that groups products—i.e. toys and books owned by individual children—into "Gender" categories, and "Gender" categories are grouped under "Nationality" categories.
The transformation execution algorithm is a recursive algorithm which starts at a root Segment Link in a Segment Links Tree. Among other things, the algorithm determines the processing path which is taken through the Segment Links Tree.
We now include some further explanation of the term "perform the operation" used in block 305 (
In block 305 in the flowchart of
Given the current temporary outbound Segment Instance within the current SP production,
IF the current SL's Operation Mode is:
Referring to
Each of the steps/boxes in
We next move to box 302, which has no effect as we are still at the first instance in the root SL.
In box 303 the algorithm executes the current Segment Link's Segment Processor (SP), and this produces the temporary outbound segment instance 340, ie "British", shown in
We next move to box 304, which has no effect as we are already at the first temporary outbound segment instance "British". However, it is worth noting that, although in this example the SP has produced only one temporary outbound segment instance (British), in general the SP may produce any number of temporary outbound segment instances, which is why box 304 refers to moving to the first or next temporary outbound segment instance. The temporary outbound segment instances therefore act as a sort of "pattern" which is can be viewed as being "placed over" any real (ie already existing) outbound segment instances, after which the effect on the outbound segment instances (eg insert, update, delete etc) is determined by the operation mode of the relevant Segment Link.
In box 305 the "Insert/Update" operation of the Segment Link is performed, so now the temporary "British" segment becomes a "real" British segment, because the temporary British segment is inserted into the Outbound Data Format Instance.
From box 306 we pass down to box 307 because the operation was not a deletion or replacement.
The effect of boxes 307 and 308 is to move the Output Context 337 onto the British segment (ie the segment instance affected by the Insert/Update operation).
In box 309 we move down to the next Segment Link (326 in
We next enter box 310 which is the recursion box. Box 310 requires that we execute the "single link execution algorithm" again, but this time the current subordinate SL (ie 326 in
As an alternative to following the flow chart shown in
Step 1. For each inbound segment instance that feeds a Segment Link (starting with the root Segment Link), run that Link's Segment Processor to produce zero, one or more temporary outbound segment instances.
Step 2. Then for each such temporary outbound segment instance perform the operation defined by the Link's Operation Mode (eg. insert, update, delete, select, replace).
Step 3. Then for each outbound segment instance affected by execution of the operation, for each Segment Link directly subordinate to the current Segment Link repeat these steps by returning to Step 1.
In Step 3, the expression "each outbound segment instance affected . . . ", this can be explained as follows: the "single temporary Instance" (i.e. the one that loop 304 is positioned on upon its single iteration) feeds and triggers the Link's operation—the result of this operation can be zero, one or more outbound Instances affected by the operation.
See below for how the term "affected Instances" should be understood for particular Operation Modes:
In the case of the "insert" operation, the affected instances can be identified with the temporary Instances, as they are grabbed by the operation and glued under the Instance pointed to by the Output Context—as in the example. Thus in the case of "insert" the number of outbound Instances is equal to the number of temporary Instances.
In the case of the "update" or "select" operations though, the affected instances would be those existing outbound Instances under the Output Context that match this particular "single temporary Instance" (in terms of Matching Key). The number of such matching outbound Instances—i.e. Instances affected by the operation—can be zero, one or more.
A Project Element is a portion of the Aptitude software which is available to a developer. The concept of HT is implemented in the following Microgen Aptitude Project Elements:
1. Hierarchy Transformation Project Element. The concept of the Segment Processor is implemented by a Complex Rule or Attribute Mapping.
2. EDF Mappings Project Elements, e.g. XML File EDF Mapping.
The Hierarchy Transformation Project Element (HT PE) implements a subset of HT concept functionality. The view of the HT that is presented to the developer in the HT PE editor is different from the purely abstract diagram of HT shown in
The Aptitude Studio screenshots shown in
In the HT PE editor (see the screenshots in
When "Attribute mapping" is chosen, the lower panel 352 of the HT PE editor is automatically displayed to the developer for defining the Attribute mapping, which in this case is an implementation of the HT's Segment Processor abstract concept. In this case note that the "Complex Rule name" edit box 356 is inaccessible to the developer.
In the very same modal window 353, the developer can set the Segment Link Operation Type 355—in this case "Insert/Update".
In the Attribute mapping panel 352 each segment can be expanded to show the attributes of each segment, or collapsed, by clicking on a + or − sign beside the segment name. For example the Family (root) segment has two attributes, which are "Surname" and "Nationality". The developer is able to create and change the mappings between the inbound and outbound attributes. When the developer double-clicks on an outbound Segment attribute, an "Attribute mapping Properties" modal window 357 is displayed. In this window, the developer can specify if the attribute is to be a Matching key 358. Matching keys are discussed later.
Edit-boxes 359 and 360 specify the inbound Data Format and outbound Data Format respectively, where in the case of HT PE the inbound Data Format can be of one of the two classes: Data Object or Enrichment schema. The Outbound Data Format must be a Data Object in the case of HT PE.
The screenshots that follow in
In the case of the "Book to Product" Segment Link (328 in
Sample Transformations
The linked outbound and inbound structures are actually the same (in the sense of their graph/tree structures).
The linked outbound structure (on the right) has one or more Segments skipped when compared to the inbound structure.
The picture shows Segment Links only.
Two segments (Employee and Competition) of the inbound structure are linked to two sibling segments (Player and Tournament) of the output structure. By "sibling segments" we mean that the segments are both subordinate segments of the same parent segment, in this case the Team segment.
In the example of
The Inbound structure is split into two parts in the outbound structure.
The 'Account' Segment's attributes and its ancestors' attributes are mapped to the 'Account-Bank-Company' segment.
In this example the inbound structure on the left is efficient in terms of storage space. The outbound structure contains a separate record for each bank account which includes all of the company and bank details, and such a structure may be needed for certain purposes.
This example uses Matching Keys, which are represented in
In the Structure Promoting example of
The "Extract & Merge" application employs the Segment Link's "Select" Operation Mode. It usually applies where the outbound Data Format Instance is partially constructed beforehand and the transformation is to modify or add some data to the existing one where required (as determined by the Matching Keys), rather than create the whole outbound Instance from scratch.
Hierarchy Transformation in Aptitude includes the following features and benefits:
1. A graphical notation in which the developer models transformation of one tree graph into another.
2. A process of validation and compilation of such a graphical prescription of a transformation:
3. A simple definition of a transformation—including the fact that Segment Links form the Segment Links Tree.
4. Execution of the transformation in runtime—i.e. the fact that the algorithm described in the "Execution Algorithm" chapter executes the transformation when applied to the compiled Segment Links Tree defined by the developer.
5. A wizard builds a default Segment Links Tree based on the Inbound Data Format—that means that the developer must only draw the Segment Links, but doesn't have to set up the relations between them (i.e. set up the Segment Links Tree)—this default tree generation covers a wide variety of HT applications.
6. Segment Link's features:
Currently, two link processors are available in Aptitude: Attribute Mapping; and Rule Mapping, which allows rules to be embedded into the Hierarchy Transformation.
We next describe a functionality in Aptitude which we refer to as Traversal Transformation, or simply TT. Traversal Transformation allows a developer to create a Microflow (being a flow diagram within Aptitude comprising Aptitude icons and links), such as that shown in the example of
Traversal Transformation (TT) involves breaking down the programming paradigm of iteration across a collection of items into a handful of abstract component concepts. These component concepts, when named, specialized and combined together, can cover a wide range of data processing issues.
We next summarise the following Traversal Transformation component concepts, some of which are declared (ie specified) by the developer when defining a Traversal Transformation node, such as the nodes 402 and 404 of
Item: This is declared (ie specified) by the developer (ie the user of the Aptitude graphical interface). It is an item of any collection, for example:
Such a tree graph is in this case (ie in the context of Traversal Transformations) a data object which has recursive segments. The example of
Collection: This is declared by the user. It is a collection of Items, for example:
Cursor: This is not visible to the user or developer. It is an auxiliary runtime concept, which can be thought of as an entity that visits Collection Items in the order specified by the Algorithm (see below).
Algorithm: This is declared by the developer. It can for example be a known algorithm (suitable for the type of the Collection) according to which the Cursor traverses the Collection, e.g.
The developer may be presented with a number of different algorithms to choose from, and simply has to choose one from a list in a window. This makes the process straightforward for the developer as he/she does not have to devise the algorithm from scratch.
"On Enter" Event Handler and "On Leave" Event Handler: These are declared (ie specified) by the developer, and represent the actions that are performed when the Cursor enters or leaves an Item respectively.
The Handler can modify everything provided by the Context (Context is defined below). A Handler can also embed and execute another Traversal Transformation. The Event Handler may also be defined by a (graphical) Aptitude Rule, which may make use of data from the tree node itself, its parent(s) and/or its child(ren).
Filter or Selector: This is declared (ie specified) by the developer. It is an entity (in software) that evaluates conditions (specified by the developer) that must be met by an Item to fire the Event Handlers on this Item. If the conditions are not met the Cursor simply moves to the next item.
The Filter (also referred to as a Selector) can modify everything provided by the Context (Context is defined below) except the current Item (defined below). This is because modification of the current item is done only by the Handlers (referred to above). However, the Filter is not prevented from modifying other things, such as the Context's Memory for example. The logic of the Filter can be quite complex—for example it may require caching some results calculated in one iteration to perform filtering in another iteration.
The Filter can embed and execute another Traversal Transformation, but the Event Handlers of this embedded Traversal Transformation cannot modify any Item in the Collection. The logic of the Filter can be quite complex—for example, prior to the decision whether the current Item is to be processed or not, the Filter may require iteration across a collection other than the one the Traversal Transformation is currently dealing with. To do this, it is possible to use another Traversal Transformation that runs across the other collection and that shares the Memory with the current Traversal Transformation.
Aptitude's Traversal Transformations can be recursive and reusable. Recursion and reusability is also applicable in Hierarchy Transformations (described earlier). For example, a Segment Processor could embed another Hierarchy Transformation, or event Traversal Transformation—and vice versa—a Traversal Transformation could employ a Hierarchy Transformation.
Context: The Context contains the following two items, ie Memory and current Item. It is important to understand that "Context" here (ie in relation to Traversal Transformations) is not related to the "Input Context" and "Output Context" described above in relation to Hierarchical Transformations. The word "Context" here has a completely separate and different meaning.
Memory: This is declared (ie specified by the developer), and is memory storage where Handlers and Selector can store some results they calculated during the current iteration for later use (i.e. in the subsequent iterations of the algorithm).
current Item: This is not something which is declared by the developer, but is instead an auxiliary runtime concept which represents the Item that the Cursor is currently on during the process of the algorithm.
We next describe, with reference to
Problem: given an input tree graph where only leaf nodes have values assigned—say this value is Weight (e.g. in kilograms)—we want to:
Solution: Two Traversal Transformations will be required. We name these TT1, which is executed first and TT2 which is executed second.
TT1 should be defined by the developer as follows:
Collection: tree
Item: a node defined as follows:
Weight: numeric
Participation: numeric
Algorithm: Depth-First-Search
Context Memory: NONE
"On Enter" Handler: NONE
"On Leave" Handler:
(for the Item the Cursor is currently on) sum the Weights of the
(if there are any) and assign the sum to the Item's Weight
Selector: NONE
TT2 should be defined by the developer as follows:
Collection: same as TT1
Item: same as TT1
Algorithm: same as TT1
Context Memory: defined as follows:
TotalWeight: numeric
"On Enter" Handler:
IF there is nothing in the Context's Memory yet, that means the
Cursor is on the root node, which holds the Weight of the whole tree
(calculated by TT1) - store this value in the Context's Memory;
OTHERWISE divide the current Item's Weight by the TotalWeight
stored in the Context's Memory and assign the result to the
Item's Participation.
"On Leave" Handler: NONE
Selector: NONE
Note that the Participation in the root node is not set, but that is irrelevant since the sub-tree the root of which is the root of the whole tree is simply that very tree—so Participation in the root node always equals 1—no matter what.
Traversal Transformation in Aptitude allows the approach that many programmers employ intuitively when processing collections of data to be made more abstract (i.e. to apply to any collection and any algorithm), and to be broken down into simple, well-formed and named abstract components, thus allowing the developer in Aptitude to achieve complex processing of potentially complex data collections, via Aptitude's graphical interface, without the need for computer programming knowledge. The process is simpler for the developer, who does not need to worry about the structure of the tree, but only needs to define the on-enter and on-leave actions together with the type of algorithm used to traverse the tree. In this way a complex problem can be decomposed into a handful of simpler concepts.
Turning now to rule templates, one of the tools used to implement hierarchy transformations in Aptitude are Complex Rules. They operate on hierarchical structures of any fixed format (referred to herein as a Data Object). However, there are some circumstances in which it would be advantageous to process different structures using the same logic, allowing the developer to re-use a rule.
A rule template allows a developer to operate on abstract structures, which may later be instantiated with one or more of a variety of different specific structures (Data Objects). Rule templates have a similar purpose to class templates in the generic programming paradigm.
A rule template refers to the segments and attributes of a Data Object using their names or paths, but it does not refer to the Data Object itself. The rule template is therefore not bound to a fixed data structure.
A rule template input is not defined by a Data Object, but instead is defined only by defining input attributes, which in turn are defined as "name, type" pairs. There is no need to refer to a Data Object or segment path, as is the case for regular rules.
A rule template output is also defined only by defining output attributes, which in turn are defined as "name, type" pairs. Again, there is no need to refer to a Data Object or segment path, as is the case for complex rules.
A rule template may invoke another (or the same) rule template. If a rule template invokes another (or the same) rule template, then two paths are specified in a rule template block (call to another rule template). The first is a segment path for input (relative or absolute), and the second is a segment path for output (relative or absolute).
To illustrate the invention,
In order to apply the rule template to a specific calculation, it must be linked to a Data Object, as shown in
To invoke the rule template 500 it is instantiated. In other words, its input is bound to Data Object "MyPortfolio" and subsegment "Assets", and its output is bound to Data Object "MyCalculations", segment "Root".
In order for the rule template to be compiled successfully, the input and output Data Objects and segments must conform to the requirements specified in the rule template. In this example, the segment "Assets" must have two numeric attributes called "Return" and "Weight" in order for rule template 500 to be used with the segment.
In some cases, the rule template may be used for more than one calculation in a data flow. For example, and referring to
In this example, the input is root/customer/portfolio 518, and the rule template "Calculate Portfolio Return" is invoked twice 520, 522. The rule template is invoked once for bonds 520, and once for shares 522. The returns are then summed and stored as a total return 524 for a customer portfolio in calculations/customer/return 526. Again, it is only required that the Bonds and Shares segments have both "Return" and "Weight" numeric attributes.
A rule template 528 calls another rule template 530, termed "calculate sector return". The calculate sector return template 530 can process the recursive structure that arises from a recursive Data Object The calculate sector return template 530 invokes itself for all the child sectors, and invokes a rule template 532 as described with respect to
A rule template may be instantiated with different specific structures (Data Objects), and may process either flat or hierarchical structures. It may also process structures that are defined in a recursive way (such as a Data Object referring to itself, or a segment referring to itself), and makes the fewest possible assumptions about the structures it is instantiated with, which allows the structure to be changed without having an impact on the processing definition. A rule template is also easily re-usable with other Data Objects.
A key issue with the use of rule templates is determining whether it is possible for a rule template to be instantiated with the given data structure (Data Object) and path. For example, the rule template 500 shown in
It is therefore necessary for the developer to have a tool which allows him to check whether instantiation of a rule template is possible. To this end, an algorithm is used when the Aptitude project is compiled to search for rules that are incompatible with data, and any invalid instantiations are discovered and reported to the user. As an additional effect, a tree of (instantiated) template rule calls is created by the algorithm.
The following description of the algorithm makes the following assumptions:
The following definitions are used in the description of the template instantiation algorithm:
A rule template recursive call is defined as a direct or indirect call from a rule template to itself (possibly in a different input context);
A recursion offset is the difference of input path lengths (expressed in the number of path segments) for two consecutive rule template recursive calls;
A rule context path is the longest common ancestor path (in a Data Object) for the rule input paths in a call sub-tree, starting from the given rule and cut where the recursive call is discovered; and
A rule context segment is the last segment of the rule context path.
The template instantiation algorithm requires an input of the following:
The algorithm outputs a TRUE result if the rule template can be instantiated for a given Data Object and absolute path within it (as a side-effect a non-empty call tree is produced), and a FALSE result if the rule template cannot be instantiated for the given Data Object.
The data structure required by the algorithm is that for a call tree C, every node is a pair consisting of a rule and an absolute path within the Data Object, and a set R of instantiated rules (rule is instantiated for a relative path starting from a rule context segment and ending with a segment the rule input is based on).
With reference to
532. Create a call tree C. The rule template is inserted having an absolute path as a root node. The tree is then expanded 534. Stop expanding at recursive calls. For any node, instantiate an absolute input path within the Data Object.
536. If the input path cannot be instantiated, then stop with result set to FALSE 558. Mark all the leaf nodes as non-visited.
538. Create an empty set R.
540. If there are any non-visited leaf nodes in the call tree C, do the following steps. Otherwise, finish with the result TRUE 560.
542. Select a leaf node CL that has not been visited yet and mark it as visited.
544. If the node is terminal (it corresponds to a rule that does not call any other rules), go to step 540.
546. Determine recursion offset. If it is negative (up the tree), then stop with result set to FALSE 558.
547. The rule context segment is calculated. If a rule is processed for the first time, a rule context segment for the ancestor node of CL corresponding to the previous call to the same rule is calculated. The rule instantiated for a relative path starting from a rule context segment is inserted 548 into the set R.
550. Calculate a rule context segment for CL and a determination is made whether an instantiated rule has already been processed in a given context, in which case an instantiated rule will already be populated in set R. If the rule has already been processed in a given context, go to step 540. Otherwise, insert 552 the descendent instantiated rule to the set R.
554. Expand the call tree starting from node CL. Stop expanding the nodes at recursive calls. For any node, instantiate 556 absolute input path within Data Object. If input path cannot be instantiated, then stop with result set to FALSE 558.
In order to better describe the operation of the template instantiation algorithm, the following example is provided:
Let us assume that the developer wishes to instantiate rule template R1, which calls itself and another rule template, R2. Moreover, rule template R2 in turn calls rule template R1. This may be depicted as a call tree, in which the parent-child relationship is a caller-callee relationship, as illustrated in
For the sake of simplicity, only input paths for the rules are considered, and they are shown in parentheses in the
The example assumes that the developer wishes to instantiate the rule template R1 for a Data Object DO1, and for the path /D/C, as illustrated in
Note that the DO1 is recursive, as the children of segment A are A itself and B. Similarly, the children of B are A and B. Actual data based on this Data Object may then have many more levels than shown in the picture. For example, there may be a segment instance for a path /D/C/A/B/A/A/A.
Table 1 below illustrates step by step the running of the template instantiation algorithm. Note that the in the call tree, rules instantiated for absolute paths (paths starting from a root segment) are shown, while in the set R, rules instantiated for relative paths (paths starting from a rule context segment) are contained.
Call tree
Initial call tree is shown. Non-
visited leaf nodes are in bold.
There are some non-visited
leaf nodes in the call tree.
Node /R1/R1 is picked for
examination. It is not a
terminal node.
Recursion offset is one level
down (ancestor call to R1 is
based on path /D/C, this call to
R1 is based on path /D/C/A,
the difference is one level
Rule R1 is processed for the
first time.
To calculate a rule context
path we consider the subtree
rooted in a previous call to R1,
which in this case is /R1 (the
whole call tree). For all the
instantiated paths (paths in
DO) in this subtree we find the
longest common ancestor
path. This is /D, which is one
level up from the rule input
Rule context segment is then
D, and the rule is instantiated
for the relative path starting
from this segment, i.e. D/C.
R1<D/C is inserted to the set
Knowing that rule context
segment for R1 is one level up,
we determine it for the second
call to R1, i.e. /R1/R1. As it is
based on /D/C/A, its rule
context path is /D/C, and
relative path is C/A.
The context has not been seen
yet for the rule R1, so
R1<C/A> is inserted in the set
The tree is shown after node
/R1/R1 has been expanded.
Leaf nodes are in bold.
We continue, as there are still
non-visited nodes in the call
Node /R1/R1/R1 is picked. It is
not a terminal node.
Recursion offset is one level
Rule has already been
processed, nothing is done.
Rule context segment is to be
found one level up, relative
path is A/A.
It has not been seen yet, so
the rule R1<A/A> is inserted to
set R.
The tree is shown after
/R1/R1/R1 has been
There are still non-visited
nodes in the call tree.
Node /R1/R1/R1/R1 is picked.
It is not terminal.
Recursion offset is again one
level down.
Rule has already been
processed, nothing is done.
Rule context segment is one
level up, which is segment A.
Rule R1 has already been
processed in the context of
A/A, so we can stop expanding
this branch and go to step 2.
There are still non-visited
Node /R1/R1/R1/R2/R1 is
picked for examination.
To calculate recursion offset
we consider two calls:
ancestor call /R1/R1/R1 and
the current call
/R1/R1/R1/R2/R1. From the
DO paths for these calls it can
be seen that recursion offset is
one level down (to obtain
/D/C/A/B/B from /D/C/A/A one
has to move one level up and
two levels down). That is OK.
Rule R1 has already been
processed, nothing is done
Rule context segment for R1 is
one level up, which is segment
Rule R1has not been seen in
the B/B context yet, so the
context is registered in set R.
The tree is shown after node
/R1/R1/R1/R2/R1 has been
Please note that this time the
node /R1/R1/R1/R2/R1/R2 did not
have to be expanded, as it is
the recursive call to R2.
There are still non-visited
nodes in the call tree.
Node /R1/R1/R1/R2/R1/R1 is
picked for examination.
Recursion offset is one level
down, which is OK.
Rule R1 has already been
processed, nothing to be done
Rule context segment for R1 is
one level up, which is segment
Rule R1has not been seen in
the context of B/A yet, so it is
inserted to set R.
/R1/R1/R1/R2/R1/R1 will be
There are still non-visited
Node /R1/R1/R1/R2/R1/R1/R1
is picked for examination.
Recursion offset is one level
down, which is OK.
Rule R1has already been
Rule context segment is to be
found one level up, so it is
segment A.
Rule R1 has already been
processed in the context of
A/A, so we can stop expanding
this branch and go to step 2.
There are still non-visited
nodes in the call tree.
Node /R1/R1/R1/R2/R1/R1/R2
is picked for examination
Recursion offset is two levels
down, which is OK.
Rule R2 is processed for the
first time.
Rule context segment is
calculated for the ancestor R2
call, i.e. /R1/R1/R1/R2.
Rule context path for the
subtree rooted in this node is
/D/C/A/B, which is just the the
rule input path. The relative
path consists only from
segment B.
A rule R2<B> is inserted to the
set R.
Rule context segment for
/R1/R1/R1/R2/R1/R1/R2 is
zero level up, which is
segment B. Rule R2 has
already been processed in the
context of B, so we go to step
There are still non-visited
nodes in the call tree.
Node R1/R1/R1/R2/R1/R2 is
picked for examination.
Recursion offset is one level
down, which is OK.
Rule R2 has already been
Rule context segment for
/R1/R1/R1/R2/R1/R2 is zero
level up, which is segment B.
Rule R2 has already been
processed in the context of B,
so we go to step 2.
There are still non-visited
nodes in the call tree.
Node /R1/R1/R2/R1 is picked
for examination.
Recursion offset is one level
down, which is OK.
Rule R1 has already been
processed, nothing to be done
Rule context segment is one
level up, which is segment B.
Rule R1 has already been
processed in the context of
B/B, so we go to step 2.
There are still non-visited
nodes in the call tree.
Node /R1/R2/R1 is picked for
Recursion offset is one level
down That is OK.
Rule R1 has already been
processed. Nothing to be done
Rule context segment is one
level up which is segment B.
Rule R1 has already been
processed in the context of
B/B, so we go to step 2.
All the leaf nodes in the call
tree have been visited.
The result is TRUE (rule
template R1 may be
instantiated with Data Object
DO1 and path /D/C).
The template instantiation algorithm is used to validate rule template instantiation within a context of a specific data structure and specific path. It is necessary for rule templates to be employed in practice, and not only handles recursive rule template calls but also provides a compile-time validation.
Turning now to
Aptitude introduces a concept of transactional variables. A transactional variable may contain a variety of information, which is structured in one of a number of ways. A transactional variable consists of two parts, a key and a value. The key is unique to a particular transactional variable and acts as an identifier for that transactional variable. The value contains information, which may be organised in a multi-level hierarchical tree.
By way of example, a transactional variable holding information of a certain employee consists of a key which uniquely identifies the employee, such as his social security number, and a value, which would be based on a Data Object describing that employee. An example of a Data Object, i.e. value type is shown in
A transactional variable may appear as illustrated in
Transactional variables can be used in an Aptitude process, which is performed by execution units called transaction regions, as described above. An example of transaction regions is shown in
A transactional variables editor is shown in
When data are processed, a transaction region is responsible for processing a single batch of data. A transaction region may be used concurrently by multiple threads, but every thread processes a batch unique to that thread, so there is no need to protect the access to the data being processed.
When a transactional variable is processed, on the other hand, it is desirable to protect access to the transactional variable in order to avoid multiple threads from editing the same transactional variable simultaneously. Transactional variables may be accessed concurrently by multiple threads of a single process. Those threads may be part of the same or different transaction regions. Access to the transactional variable may be subject to different isolation levels.
A transactional variable can be accessed using a variable access node. A variable access node 622 is shown in
The following policy is applied to implement the desired isolation levels when accessing a transactional variable: readers may always access the transaction variable; they are not blocked by other readers or writers and they can see the consistent, committed version of a transaction variable. The committed version of a transaction variable is the version that has been made permanent by writing it to the computer memory. Writers block each other until the end of a transaction, which ends either by committing to writing, or by rollback to the beginning of the transaction. A locking mechanism is employed to implement this policy.
Transactional variables have properties of atomicity, consistency, integrity and durability (termed ACID), and are persistent once a transaction writing operation has been committed.
The ACID properties of transactional variables are:
The American National Standards Institute (ANSI) and International Organization for Standardization (ISO) Structured Query Language (SQL) transaction isolation levels and their equivalents in Aptitude are:
In order to illustrate managing access to transactional variables, three exemplary scenarios are illustrated in
Ri reader operation that reads version i of a transactional variable,
Wi writer operation that writes version i of a transactional variable,
Tc transaction commit,
Tr transaction rollback,
* waiting for a lock to be released, to obtain access to the variable,
- normal activity (not waiting for a lock).
Scenario 1 in
Aptitude transaction reader 656 and writer 658 regions that may correspond to such a scenario are shown in
The upper transaction region 656 acts as a reader, which periodically checks if the variable has changed. If it is determined that the variable has changed, the current variable value is written to a target, for example a database. The lower transaction region 658 acts as a writer, which after some calculations saves the result to the variable, and then writes the result to an external target. If the write fails, then transaction rollback occurs, and the reader does not see any change to the variable.
Scenario 2 in
Scenario 3 in
Transactional variables are typically stored in a memory termed process private memory. Note that Hierarchy Transformation, described above, can be used to operate on hierarchical variables using a Variable Access Node.
Aptitude provides a data generation functionality that allows a developer to generate artificial data for an Aptitude project. Data generation together with monitoring allows developers to test the functionality of the Aptitude Projects, measure their performance, and identify possible bottlenecks. This can be achieved during the early development phase of an Aptitude Project, in which there is usually no real business data is available. When the Aptitude Project is being executed in a simulation phase using generated data, its data sources are populated with artificial data produced during the data generation phase. The settings provide full control over the simulation process as well as the generated data.
A further user interface 704 shown in
Source settings define general features of the generation of artificial data. In the example of
To better understand the correlation between the Generation Session Length defined using Generation settings and the Interval Length/Activity Period Length defined using the Source settings, consider the following example with reference to
A user interface allows the developer to describe detailed features of the generation of artificial data. Generation settings and Source settings define parameters influencing the generation process, whereas Data Object settings define parameters shaping the generated data itself. A Data Object is a dummy representation of the business data model, so its generation settings are crucial to the whole generation process. They are defined by:
Turning now to
Referring to
A probability distribution determines the generated value of the Data Object attribute. Available probability distributions depend on the required probability distribution type. Different probability distribution types can be chosen for Numeric, String and Date-Time Data Object attributes. For example, numeric data lends itself to uniform, normal, normal skew kurtotic, histogram and sequence probability distributions, as described below, whereas string data lends itself to uniform and histogram probability distributions. These are described in more detail below. The data generation function allows the developer to define probability distributions in two ways: Firstly, it provides the possibility to display a probability chart for supplied parameters and thus makes it easier for the developer to imagine what the generated values would be. Secondly it provides hints for the more complex probability distributions, i.e. Skew and Kurtosis properties where the values are constrained by the values of the lower level moments.
Exemplary probability distributions available for a numeric Data Object attribute are as follows:
Probability distributions can also be defined for string Data Object attributes (i.e. non-numerical Data Object attributes). The distribution may be uniform, defined by the minimum and maximum values for the string length, or defined using a histogram displaying a set of values, each with a given probability of being chosen. In this case, probabilities can be equal for each value or set manually by the developer.
Referring to
The data generation function provides the developer with the ability to generate artificial data for Aptitude Projects that simulates real business data. It also provides the ability to model dependences in the generated data reflecting dependences that usually occur in real business data. Full control is provided over the generation process as well as the generated data, and this gives the possibility of testing functionality of the Aptitude Projects during early development phase. As described above, a variety of different probability distributions can be used to model the generated data, and graphical representations of probability distributions make it easier for the developer to imagine what the generated data would be.
Note also that instead of using generated data, an Aptitude Project can use "recorded" data. This is real data that has been recorded from a previous execution of the Project. It can be played back in real time or in compressed time.
Monitoring allows developers to measure performance and identify possible bottlenecks in their Aptitude projects in an easy and convenient way before the project is released to the customer. The Aptitude Project is executed under monitoring conditions either normally or in a playback mode that utilizes data generated using the data generator function or data that has been "recorded" from a real-life execution of the program. When the Aptitude Project is being executed under monitoring conditions, the developer can select the nodes are to be monitored, and is presented with monitoring indicators concerning each of the nodes that have been selected to be monitored. The developer is provided with the ability to define his own monitoring indicators (Key Performance Indicators, KPIs) using the underlying business data. The KPIs are then accessible from within Aptitude Project interface and can be used, for example, to implement a Business Activity Monitor in a Web Application. The values of all above mentioned KPIs may be presented in a graphical form allowing the developer to easily visualise the status of the monitored nodes.
Referring to
When a developer selects monitoring settings 720, is opens up a new user interface 730 that allows the developer to set parameters concerning the monitoring process on the Aptitude server side as well as the storage of monitoring samples on the Aptitude client side. This interface is shown in
When the Aptitude Project is being executed under monitoring conditions, the developer is presented with a variety of monitoring indicators concerning each of the nodes that the developer has selected to be monitored. All nodes have a set of predefined performance indicators that are monitored. This set is identical for almost all the nodes available in the data Microflow and indicators selected from the following:
A Monitoring Node can be selected that has a developer-defined set of key performance indicators. In addition, a Manual Activity Node can be selected, which is provided with the following set of indicators:
The values of monitoring indicators can be presented to the developer as any of a call-out, a chart, and a grid. Call outs show real-time values of all monitoring indicators in a particular point in time of the monitoring process. Charts and Grids present all values of the chosen monitoring indicators collected during the whole monitoring process. In other words, a Call out shows data at the current point in time; a grid shows a collection of data at the current point in time and a chart shows changes in a data set over a period of time. All three kinds of monitoring indicator perspectives are refreshed according to the frequency defined in the Monitoring Settings.
Referring to
Monitoring results may also be displayed using one or more charts. Referring, to
Another way to display the results of monitoring is to use a grid, as shown in
A monitoring node 742, as shown in
Note that the Monitoring Node is a normal node that takes part in the execution of the Aptitude Project. In other words, it always evaluates the user defined monitoring indicators, even if the project is not executed under monitoring conditions. The monitoring indicators are then accessible from within the Aptitude Project and can be used, for example, to implement a Business Activity Monitor in a Web Application.
Monitoring can be used to assist the developer in determining Microflow nodes that have inadequate performance, and therefore have the most influence on the critical path of the Aptitude Project execution. In order to turn use this feature, the developer defines two parameters: Critical Path Blocks and Critical Path Indicator (see above). The Critical Path Block defines the percentage of the nodes that should be considered as belonging to the critical path. The Critical Path Indicator selects a monitoring indicator that is most pertinent to the critical path. The critical path for the chosen monitoring indicator is visually presented as a highlight to the nodes that have the highest values of the indicator. For example, if the value for Critical Path Blocks parameter is 50%, the selected monitoring indicator is "Processing Time" and six nodes from a particular Microflow are monitored, then the three nodes with the highest "Processing Time" would be highlighted as most critical to the critical path. In the example of
The monitoring function allows the developer to measure performance and identify possible bottlenecks in an Aptitude Project. A variety of predefined monitoring indicators are available, along with the possibility of allowing the developer to create user defined monitoring indicators. Multiple ways of presenting values of monitoring indicators are provided, and charts and Grids can be easily defined by utilizing "drag and drop" in the display. The monitoring function also gives the developer the ability to identify the critical path during execution of the Aptitude Project.
Referring to
Data can be handled and processed by Microgen Aptitude in two different ways, as individual data messages in a straight through processing (STP) mode, and as groups of data messages in a batch mode. The STP mode is the basic way of supplying data messages and the data messages are subsequently processed independently by Business Process Nodes, one by one, and immediately after their arrival. A more efficient way of processing large amounts of data messages is by using the batch mode of execution, in which many data messages are processed collectively. Microgen Aptitude has been designed to operate in both STP mode and batch mode as well as in combination of both modes simultaneously.
A Source Node can deliver data in STP mode or in batch mode, but the choice of mode strongly depends on the external system requirements. For example, a. database source may be able to deliver data in a batch mode, but a message queue source cannot.
The Business Process contains nodes that process data messages. There are two classes of nodes: STP mode nodes and Grouping nodes. The difference between these classes lies in the way of dealing with the data stream. The execution result of a single Grouping node depends on many data messages, but the execution result of an STP mode node depends on a single data message.
If data messages are grouped in batches, Grouping nodes functionality can be used. The following Grouping nodes are available: a Batch Merge node, a Batch Split node, a Reduction node, a Match & Merge node, a Sorting node and a Hierarchy Transformation node (as an option).
A Batch Merge node 800 is shown in
The Batch Split node 814, shown in
The Reduction Node 820, shown in
The Match and Merge node 822, shown in
The Sorting node 824, shown in
The Transformation node 826, shown in
Input data records can be grouped into logical batches or transactional batches by Microgen Aptitude. In logical batches, data messages are grouped together depending on their attributes and source. In transactional batches, data messages are grouped together depending on their presence in a user indicated region of the data flow diagram.
A logical batch is a set of messages that are grouped together because of business reasons, such as all messages from one division. A logical batch can be determined in several ways. For example, a logical batch may be determined by Aptitude Source (e.g. all data included in one file), by a Batch Split node 814 within the Business Process Diagram, or by a Batch Merge node 800 from an STP stream of data.
Aptitude Sources working with some external system types may not have the ability to determine a logical batch, depending on the properties of the external system. Data messages are grouped into logical batches using the Data Object attributes' values. For example, all records from one division, and settings in Source Objects, such as all records from a source file, could be treated as one logical batch.
A Data Object represents an internal data format visible to the developer, whereas the external data format may be different, for example a database table or an XML file. A Data Object is a logical format for an underlying Aptitude object i.e. source, target, or reference object within the business process. It is also used for input and output of most processing nodes within a Business Process. An example of a Data Object is shown in a tree-like structure in
An Aptitude Source node is the core node that specifies where an input message is taken from, and forms the input to a Business Process. The icon 828 corresponding to the Aptitude Source node is shown in
A Logical Batch Definition tab 830 in Aptitude Source, shown in the
To increase performance and to allow the developer greater control of product behaviour it is possible to group input messages coming to one transaction region into one bigger transaction. It is possible to group messages, creating sets which contain a certain number of messages. Such a set of input data is called a Transactional Batch. For example, if a transaction batch size for the source is set to ten then all operations conducted as a result of processing of the ten subsequent messages received from this source will constitute one transaction. A Transactional batch is a set of data containing a certain number of records, e.g. 10 or 100. The use of Transactional batches increases performance, because the transaction is committed to the internal database for a group of records rather than for single records separately. If a Transactional Batch size equals zero, then all data is processed in Logical batches. If no Logical batches are defined, then all data is processed as one transaction batch. If a Logical batch is split into smaller Transactional batches, the Grouping nodes will still operate on the level of Logical batches.
The Logical batch contains at least one Transactional batch. Under some circumstances the size of a Transactional batch equals the size of a Logical batch. If the Logical batch is split into many Transactional batches, Grouping Nodes still work on the level of Logical Batches, i.e. they trigger their execution only when the whole Logical Batch is delivered to them. If there are no Grouping nodes, or if the Grouping nodes are on a transaction region border, then there is no need to wait to process each batch.
If the processing of a Transactional batch fails and leads to a broken batch, then the broken batch can be reprocessed. The broken batch may either be reprocessed excluding the broken message, or all messages in the batch can be treated as broken in which case the entire batch is reprocessed. The handling of such errors is controlled by several options in the configuration.
The developer sets the parameter for each Transaction region of the Business Process, allowing for a better programming environment and external systems adaptation.
The developer uses an Execution Error Handling form to determine how execution errors are handled in the event that any execution errors occur during the processing of a batch. An example of a developer interface 736 showing the different modes for Execution Error Handling is shown in
In order to explain the modes of error handling, some terms are defined. Aptitude uses five record status codes: unprocessed, processing, processed, error and broken. Marking records as either "broken" or "error" ensures that they are not subsequently processed, but the two statuses "broken" and "error" have different results in the different error handling modes, as will be explained below. Initially, a record is in an unprocessed state. When the batch is created, and processing of the batch begins, the status of all records in the batch is changed to "processing". Once a record has been processed successfully, its status is changed to "processed". If an error occurs in processing a record, the status of the record is changed to "error". A fifth status, "broken", is used when the batch has not been successfully processed and those records marked "broken" should not be re-processed. The "broken" status prevents the records from being re-processed, and it is still possible to identify the record in which the error happened as it has the "error" status (rather than the broken status).
The following modes of error handling are available:
Reprocess Events 838: In case of an error, a rollback operation is performed on processed records, which withdraws all changes made during the batch processing both to the records and to external systems. The record that gave rise to the error is marked as "error", and then all records are reprocessed excluding the record which gave rise to the error.
Continue Processing 840: If this option is set, data processing is continued and the broken record is marked as "error". Neither a rollback operation nor reprocessing is performed. This mode may only be used in sequential, one Target, processes. After processing, records are marked as either "processed" or "error".
Break Batch Processing 842: Rollback is performed. All records contained in a batch where the error occurred are marked as "broken" except the record causing the error which is marked as an "error". Marking records as either "broken" or "error" ensures that they are not subsequently processed. Rollback is performed but processing of the batch is not repeated.
Stop Microflow Execution 844: Rollback is performed. All records contained in a batch where the error occurred are marked as "broken", and the record that gave rise to the error is marked as "error". The Project execution is terminated.
Mark Batch As Error 846: Rollback is performed. All records contained in a batch where the error occurred are marked as "error". In this mode, data can be processed in packages rather than individual records, which means processing is faster. However, the end user has no way of knowing which record caused the error. The batch is not re-processed.
Reprocess Events—Optimistic Mode 848: This mode works like a combination of the "Mark Batch As Error" and "Reprocess Events" modes. Processing starts in the "Mark Batch As Error" mode, assuming optimistically that there will be no errors. Data can be processed in packages rather than in individual records and the processing is fast. If there are no errors by the end of the batch, then the processing is completed in this mode. If there are errors, however, the end user will not know which record caused the error, as data was processed as a single package. In this situation, a rollback operation is performed and the processing is re-started in the "Reprocess Events" mode, which is slower but makes it possible to identify the record(s) that gave rise to the error. This record is then marked as "error", and then all records are reprocessed excluding the record which gave rise to the error (just as in the Reprocess Events mode).
The optimistic mode works well for a small or moderate number of errors, as it processes data significantly faster. The more errors however, the more times the batch processing has to be repeated, so in case of high error rate it may be slower.
The optimistic mode is summarized in
850. A processing function is stored in a memory.
852. A function icon corresponding to the processing function is used in an Aptitude data flow diagram.
854. The developer sets error handling attributes associated with the function icon.
856. The Aptitude data flow diagram is complied as a computer program.
858. During subsequent processing of a batch of data using the function, it is determined that one of the data messages in the batch has given rise to a processing error. If there are no errors, the batch execution completes at this step.
860. The batch processing is rolled back to obtain the original data batch.
862. The data message that gave rise to the processing error is marked.
864. The batch is reprocessed, excluding the marked data. This may be repeated if more errors occur.
Referring now to
We now describe functionality of Aptitude which allows Complex Rules in Aptitude to be used for processing hierarchical data structures, and particularly for transforming data having a first tree structure into data having a second tree structure.
We described above the concept of Hierarchy Transformation in Aptitude, which made use of a Segment Processor for each Segment Link, and we explained that the Segment Processor may be implemented using Attribute Mapping or using a Complex Rule. In that case the Complex Rule was embedded in the Hierarchy Transformation's Segment Link. However, as an alternative to this Aptitude allows a developer to use Complex Rules to transform one data structure into another, without the developer drawing Hierarchy Transformation's Segment Links between inbound and outbound segments. In this sense Complex Rules may be used as an alternative to Hierarchy Transformation.
In general Complex Rules may be used to transform instances of a hierarchical inbound data format into zero, one or more instances of a hierarchical outbound data format.
Complex Rules is a functionality that is alternative to Hierarchy Transformation with regard to some of the hierarchical data processing issues. In Aptitude, Complex Rules accept Data Objects, Enrichment Schemas and scalar parameters as the format of their input and accept Data Objects and scalar parameters as the format of their outputs. Simple Rules accept only scalar parameters for both input and output. No Context Links are allowed in Simple Rules, as they cannot process hierarchical data. The icons used for Simple and Complex Rules are different.
Complex Rules give the developer a lot of flexibility when constructing calculations intermixed with data transformation, but at some cost of visibility (as will be discussed below).
Complex Rules would not be recommended for example for the transformation given in the example in
But Complex Rules can be used to deal with issues that Hierarchy Transformation cannot. For example, a set of Complex Rules, when constructed properly, can produce virtually any number of outbound Data Format Instances compliant with different Data Formats because each Rule can have more than one output. In contrast Hierarchy Transformation has only one outbound Data Format. This ability of Complex Rules is useful when productions of Segment Instances based on two or more different Segments share the same calculation routine. To achieve this functionality in Hierarchy Transformation we would need to construct as many Hierarchy Transformations as the number of outbound Data Formats, which would be less efficient from the runtime performance perspective.
For non-advanced users the use of Complex Rules is recommended when hierarchy transformation is simple, but the scalar data calculation routines are complicated. Advanced users can use Complex Rules (sometimes embedded in Hierarchy Transformation's Segment Links as Segment Processors) to deal with transformations where Hierarchy Transformation itself would be less suitable.
In Complex Rules, a transformation prescription is constructed by the developer as follows:
These concepts will be illustrated by means of an example. Our task in the example is to construct a set of Complex Rules that will simply clone the inbound Message (which in the Hierarchical Transformation terminology is an "Inbound Data Format Instance") from input to output. There is little advantage to having such a set of Rules, of course, but this example is given for the purpose of illustration.
Let us presume we have a Data Object (which in the Hierarchical Transformation terminology is a "Data Format") of the same format that we used for the Inbound Data Format in the Hierarchy Transformation example of
Complex Rule "Child" (referred to by "Family") also refers to (embeds) two other Complex Rules, namely the "Toy" Complex Rule and the "Book" Complex Rule by means of Rule Blocks 914 and 916 respectively, as illustrated in
An important point to note here is the fact that when in Aptitude's Rules Editor, the developer works on and is presented with only one Rule at a time, the Rule being displayed on a Rule editor sheet (an area covered by a grid of lines). This plain view of the Blocks is very useful when it comes to flat, scalar data calculations, but is not so convenient when performing hierarchy transformations, as the developer can see only the "insides" of the currently edited Rule and the names of any Rules that this Rule refers to directly by means of Rule Blocks (as the name of the embedded rule is displayed in the Rule Block). For instance: Rule "Family", when opened in the editor, lets the developer know about the "Child" Rule—but not about the "Toy" nor "Book" Rules. To find out about those, the developer would need to open the "Child" Rule in another editor sheet.
Now, when we take all our Rules together, we will see that—more or less knowingly—we have created a hierarchy of Rules as illustrated in
This hierarchy of Rules, when applied to a "Family" Data Object-compliant Message in runtime, will produce an exact copy of this Message.
The "pseudo-perspective" view of
The layout of the view of
The Complex Rules execution algorithm, in the context of hierarchical data processing, can be described by the flow chart of
Sometimes, during development, the number of levels in a hierarchy of Rules gets so large, that this is difficult for the developer to figure out how the Rules refer to each other or where the currently edited Rule is positioned in the hierarchy. To solve this problem Aptitude provides a browser, which we call a Complex Rules Navigator. The Navigator displays the hierarchy of the Rules together with connections to the inbound and the outbound Data Objects.
The Rules Navigator in the screenshot of
The screenshots of
The Complex Rule Navigator interprets the references between Rules and displays them in the form of a hierarchy of Rules correlated with the inbound and the outbound Data Formats.
Returning to
|Cited Patent
|Filing date
|Publication date
|5 Feb 1980
|1 Jun 1982
|The Bendix Corporation
|Task communicator for multiple computer system
|7 Dec 1987
|5 Dec 1989
|International Business Machines Corporation
|Method for compiling a master task definition data set for defining the logical data flow of a distributed processing network
|26 May 1989
|24 Dec 1991
|Hewlett-Packard Company
|Method and apparatus for computer program encapsulation
|15 May 1991
|23 Nov 1993
|Nec Corporation
|Individual task accounting for multiprocessor systems when executing multitask jobs
|25 Jun 1990
|4 Jan 1994
|Hewlett-Packard Company
|ANDF producer using the HPcode-Plus compiler intermediate language
|18 Dec 1989
|5 Apr 1994
|Anderson Consulting
|Computer-assisted software engineering system for cooperative processing environments
|18 Oct 1996
|29 Apr 1997
|Debenedictis; Erik P.
|Method and apparatus for controlling connected computers without programming
|11 Jan 1996
|22 Jul 1997
|Borland International, Inc.
|Development system with methods for visual inheritance and improved object reusability
|12 May 1995
|5 May 1998
|Design Intelligence, Inc.
|Adaptive binding
|26 Jun 1995
|2 Jun 1998
|Netdynamics, Inc.
|Interaction between databases and graphical user interfaces
|14 Feb 1997
|16 Nov 1999
|National Instruments Corp.
|Graphical programming system and method including three-dimensional nodes with pre-defined input and output capabilities
|24 Oct 1996
|14 Dec 1999
|Inprise Corporation
|Development system with methods providing visual form inheritance
|25 Apr 1997
|7 Nov 2000
|Debenedictis; Erik P.
|Method and apparatus for controlling connected computers without programming
|31 Jan 1996
|6 Feb 2001
|Inprise Corporation
|Development system with methods for type-safe delegation of object events to event handlers of other objects
|25 Aug 1998
|5 Jul 2005
|International Business Machines Corporation
|Dynamic object properties
|16 Jul 2001
|22 Nov 2005
|Borland Software Corporation
|Frame component container
|14 May 2002
|10 Jan 2006
|Codd Edgar F
|Delta model processing logic representation and execution system
|18 Apr 2007
|9 Sep 2008
|Symbol Technologies, Inc.
|Software method for maintaining connectivity between applications during communications by mobile computer terminals operable in wireless networks
|9 Sep 2004
|3 Feb 2009
|Microsoft Corporation
|Method, system, and apparatus for creating an architectural model for generating robust and easy to manage data protection applications in a data protection system
|23 Jan 2003
|21 Jul 2009
|Sun Microsystems, Inc.
|Markup compiler that outputs MIDlets
|20 May 2005
|15 Dec 2009
|Sun Microsystems, Inc.
|Method and apparatus for pattern-based system design analysis using a meta model
|23 Jun 2006
|19 Oct 2010
|Thomas Plum
|Automated safe secure techniques for eliminating undefined behavior in computer software
|23 Feb 2006
|18 Jan 2011
|Cadence Design Systems, Inc.
|Method and system for split-compiling a hybrid language program
|10 Mar 2005
|22 Feb 2011
|Research In Motion Limited
|System and method for building a deployable component based application
|8 Dec 2009
|5 Apr 2011
|Research In Motion Limited
|System and method for applying development patterns for component based applications
|24 Feb 2009
|27 Dec 2011
|Judson Ames Cornish
|Platform for processing semi-structured self-describing data with controlled side effects
|29 Dec 2009
|20 Mar 2012
|Microgen Aptitude Limited
|Transaction regions in graphical computer-implemented methods of processing data
|24 Jul 2008
|20 Mar 2012
|International Business Machines Corporation
|Object oriented based methodology for modeling business functionality for enabling implementation in a web based environment
|14 Feb 2012
|4 Sep 2012
|Media Direct, Inc.
|Systems and methods for a mobile application development and development platform
|16 Mar 2001
|12 Mar 2013
|Gutenberg Printing Llc
|Web application generator
|12 Mar 2001
|25 Oct 2001
|Richard Aumer
|Editor for creating process plans
|27 Jan 2006
|2 Nov 2006
|Neil Thomson
|Process automation
|5 Sep 2006
|8 Mar 2007
|Morfik Technology Pty. Ltd.
|10 Aug 1994
|1 Mar 1995
|AT&T Corp.
|Method and apparatus for configuring computer programs from available subprograms
|30 Sep 2005
|5 Apr 2006
|Microsoft Corporation
|An extensible framework for designing workflows
|26 Jan 2006
|2 Aug 2006
|Microgen PLC
|Process automation
|28 Nov 2002
|19 Jun 2003
|Siemens Aktiengesellschaft
|System and method for modelling and/or executing software applications, especially mes applications
|"Breaking the Software Development Bottleneck," AVS/Express, Advanced Visual Systems Inc. (Mar. 1994).
|Beecher, V. et al., "Oracle® Fusion Middleware, Developer's Guide for Oracle SOA Suite 11g Release (Jan. 1, 2011) E10224-01," Chapters 1, 14 and 18 (May 2009).
|Dyer, D.S., "Visualization. A Dataflow Toolkit for Visualization," IEEE Computer Graphics and Applications, vol. 10, No. 4, pp. 60-69 (Jul. 1990).
|EP, European Search Report, European Application No. 10196007.8 (Jun. 29, 2011).
|Gurd, J.R. et al., "The Manchester Prototype Dataflow Computer," Communications of the ACM, vol. 28, No. 1, pp. 34-52 (Jan. 1985).
|Habegger et al, "Web services for information extraction from the web", IEEE pp. 279-286, 2004.
|Linthicum, D.S., "Get the Picture with Visual Programming," Application Development Trends, pp. 52-58 (Feb. 1994).
|Mickens et al, "Atlantis: Robust, extensible execution environments for web applications", ACM, pp. 217-231, 2011.
|Puder, "A cross language framework for developing AJAX applications", ACM pp. 105-112, 2007.
|Strom, R. et al., "Poster Submission-A Visual Environment for Distributed Object-Oriented Multi-Applications," OOPSLA '92, Addendum to the Proceedings, pp. 205-206, Vancouver, British Columbia (Oct. 1992).
|Strom, R. et al., "Poster Submission—A Visual Environment for Distributed Object-Oriented Multi-Applications," OOPSLA '92, Addendum to the Proceedings, pp. 205-206, Vancouver, British Columbia (Oct. 1992).
|Sunshine et al, "DynXML: safely programminig the dynamic web", ACM pp. 29-38, 2010.
|Veen, Arthur H., "Dataflow Machine Architecture," ACM Computing Surveys, vol. 18, No. 4, pp. 365-396 (Dec. 1986).
|Citing Patent
|Filing date
|Publication date
|30 Nov 2012
|18 Nov 2014
|Visicom Media Inc.
|Tool configured to build cross-browser toolbar
|20 Sep 2013
|12 Jan 2016
|Microsoft Technology Licensing, Llc
|Input filters and filter-driven input processing
|30 Nov 2012
|11 Apr 2013
|Visicom Media Inc.
|Cross-browser toolbar and method thereof
|20 Sep 2013
|26 Mar 2015
|Microsoft Corporation
|Input filters and filter-driven input processing
|16 Jul 2013
|21 Jan 2015
|Form reproduction realization method
|U.S. Classification
|717/140, 717/141, 714/15
|International Classification
|Cooperative Classification
|30 Dec 2009
Owner name: MICROGEN PLC, UNITED KINGDOM
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:THOMSON, NEIL;PUSZ, GRZEGORZ R.;REEL/FRAME:023716/0234
Effective date: 20091223
|15 Jan 2010
Owner name: MICROGEN APTITUDE LIMITED, UNITED KINGDOM
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROGEN PLC;REEL/FRAME:023794/0558
Effective date: 20100106
|7 Apr 2014
Owner name: APTITUDE SOFTWARE LIMITED, UNITED KINGDOM
Free format text: CHANGE OF NAME;ASSIGNOR:MICROGEN APTITUDE LIMITED;REEL/FRAME:032612/0748
Effective date: 20140204
|24 Nov 2016
|Fee payment
Year of fee payment: 4