Component based interface to handle tasks during claim processing

[0001] The present invention relates to task management and more particularly to handling task during insurance claim processing utilizing a computer system.

[0002] Computers have become a necessity in life today. They appear in nearly every office and household worldwide. A representative hardware environment is depicted in prior art FIG. 1, which illustrates a typical hardware configuration of a workstation having a central processing unit 110, such as a microprocessor, and a number of other units interconnected via a system bus 112. The workstation shown in FIG. 1 includes a Random Access Memory (RAM) 114, Read Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk storage units 120 to the bus 112, a user interface adapter 122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, and/or other user interface devices such as a touch screen (not shown) to the bus 112, communication adapter 134 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 136 for connecting the bus 112 to a display device 138. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system.

[0003] Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided.

[0004] OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

[0005] In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

[0006] OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

[0007] OOP also allows creation of an object that “depends from” another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine “depends from” the object representing the piston engine. The relationship between these objects is called inheritance.

[0008] When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

[0009] With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, the logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:

• • [0010] Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.
  • [0011] Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.
  • [0012] An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.
  • [0013] An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.

[0014] With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

[0015] If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects.

[0016] This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.

[0017] A computer program is provided for developing component based software capable of handling insurance-related tasks. The program includes a data component that stores, retrieves and manipulates data utilizing a plurality of functions. Also provided is a client component that includes an adapter component that transmits and receives data to/from the data component. The client component also includes a business component that serves as a data cache and includes logic for manipulating the data. A controller component is also included which is adapted to handle events generated by a user utilizing the business component to cache data and the adapter component to ultimately persist data to a data repository. In use, the client component is suitable for receiving a plurality of tasks that achieve an insurance-related goal upon completion, allowing users to add new tasks that achieve the goal upon completion, allowing the users to edit the tasks, and generating a historical record of the tasks that are completed.

[0037] Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

[0038] The benefits of object classes can be summarized, as follows:

• • [0039] Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems.
  • [0040] Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.
  • [0041] Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.
  • [0042] Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.
  • [0043] Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.
  • [0044] Libraries of reusable classes are useful in many situations, but they also have some limitations. For example:
  • [0045] Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes.
  • [0046] Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects.
  • [0047] Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

[0048] Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

[0049] Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

[0050] The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still “sits on top of” the system.

[0051] Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.

[0052] Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

[0053] A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

[0054] Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.

[0055] There are three main differences between frameworks and class libraries:

• • [0056] Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.
  • [0057] Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.
  • [0058] Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

[0059] Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Bemers-Lee, D. Connoly, “RFC 1866: Hypertext Markup Language-2.0” (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, “Hypertext Transfer Protocol—HTTP/1.1: HTTP Working Group Internet Draft” (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

[0060] To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

• • [0061] Poor performance;
  • [0062] Restricted user interface capabilities;
  • [0063] Can only produce static Web pages;
  • [0064] Lack of interoperability with existing applications and data; and
  • [0065] Inability to scale.

[0066] Sun Microsystem's Java language solves many of the client-side problems by:

• • [0067] Improving performance on the client side;
  • [0068] Enabling the creation of dynamic, real-time Web applications; and
  • [0069] Providing the ability to create a wide variety of user interface components.

[0070] With Java, developers can create robust User Interface (UI) components. Custom “widgets” (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.

[0071] Sun's Java language has emerged as an industry-recognized language for “programming the Internet.” Sun defines Java as: “a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets.” Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add “interactive content” to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, “C++ with extensions from Objective C for more dynamic method resolution.”

[0072] Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named “Jakarta.” ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.

[0073] One embodiment of the present invention is a server based framework utilizing component based architecture. Referring to FIG. 2A, one embodiment of the present invention includes an Architecture Object 200, an Application Object 202, a User Interface Form 204, a User Interface Controller 206, a Client Component Adapter 208, a COM Component Interface 210, and a Server Component 222.

[0074] In general, the components of the present invention operate as shown in FIG. 2B. In step 230, data is stored in an object of the component. In step 232, functions which manipulate the object are encapsulated with the object data. Later, in step 234, the stored object data can be manipulated by other components utilizing the functions of step 232.

Architecture Object

[0075] The Architecture Object 200 provides an easy-to-use object model that masks the complexity of the architecture on the client. The Architecture Object 200 provides purely technical services and does not contain any business logic or functional code. It is used on the client as the single point of access to all architecture services.

[0076] On the server side, the Architecture Object 200 is supplemented by a set of global functions contained in standard VB modules

[0077] The Architecture Object 200 is responsible for providing all client architecture services (i.e., codes table access, error logging, etc.), and a single point of entry for architecture services. The Architecture Object 200 is also responsible for allowing the architecture to exist as an autonomous unit, thus allowing internal changes to be made to the architecture with minimal impact to application.

[0078] The Architecture Object 200 provides a code manager, client profile, text manager, ID manager, registry manager, log manager, error manager, and a security manager. The codes manager reads codes from a local database on the client, marshals the codes into objects, and makes them available to the application. The client profile provides information about the current logged-in user. The text manager provides various text manipulation services such as search and replace. The ID manager generates unique IDs and timestamps. The registry manager encapsulates access to the system registry. The log manager writes error or informational messages to the message log. The error manager provides an easy way to save and re-raise an error. And the security manager determines whether or not the current user is authorized to perform certain actions.

Application Object

[0079] The Application Object 202 has a method to initiate each business operation in the application. It uses late binding to instantiate target UI controllers in order to provide autonomy between windows. This allows different controllers to use the Application Object 202 without statically linking to each and every UI controller in the application.

[0080] When opening a UI controller, the Application Object 202 calls the architecture initialization, class initialization, and form initialization member functions.

[0081] The Application Object 202 keeps a list of every active window, so that it can shut down the application in the event of an error. When a window closes, it tells the Application Object 202, and is removed from the Application Object's 202 list of active windows.

[0082] The Application Object 202 is responsible for instantiating each UI Controller 206, passing data/business context to the target UI Controller 206, and invoking standard services such as initialize controller, initializing Form and Initialize Architecture. The Application Object 202 also keeps track of which windows are active so that it can coordinate the shutdown process.

UI Form

[0083] The UI form's 204 primary responsibility is to forward important events to its controller 206. It remains mostly unintelligent and contains as little logic as possible. Most event handlers on the form simply delegate the work by calling methods on the form's controller 206.

[0084] The UI form 204 never enables or disables its own controls, but ask its controller 206 to do it instead. Logic is included on the UI form 204 only when it involves very simple field masking or minor visual details.

[0085] The UI form 204 presents an easy-to-use, graphical interface to the user and informs its controller 206 of important user actions. The UI form 204 may also provide basic data validation (e.g., data type validation) through input masking. In addition, the UI form is responsible for intelligently resizing itself, launching context-sensitive help, and unload itself.

User Interface Controller

[0086] Every UI Controller 206 includes a set of standard methods for initialization, enabling and disabling controls on its UI form 204, validating data on the form, getting data from the UI form 204, and unloading the UI form 204.

[0087] UI Controllers 206 contain the majority of logic to manipulate Business Objects 207 and manage the appearance of its UI form 204. If its form is not read-only, the UI Controller 206 also tracks whether or not data on the UI form 204 has changed, so as to avoid unnecessary database writes when the user decides to save. In addition, controllers of auxiliary windows (like the File-Save dialog box in Microsoft Word), keep track of their calling UI controller 206 so that they can notify it when they are ready to close.

[0088] FIG. 2C is a flowchart showing how the UI Controller operates in one embodiment of the present invention. In step 236, data is entered in a UI form by a user. In step 238, the UI controller interprets the data entered into the UI form. In step 240, the UI controller places the appropriate data into a Business Object to be utilized and retrieved later.

[0089] A UI Controller 206 defines a Logical Unit of Work (LUW). If an LUW involves more than one UI Controller 206, the LUW is implemented as a separate object.

[0090] The UI Controller 206 is responsible for handling events generated by the user interacting with the UI form 204 and providing complex field validation and cross field validation within a Logical Unit of Work. The UI Controller 206 also contains the logic to interact with business objects 207, and creates new business objects 207 when necessary. Finally, the UI Controller 206 interacts with Client Component Adapters 208 to add, retrieve, modify, or delete business objects 207, and handles all client-side errors.

Business Objects

[0091] The Business Object's (BO) 207 primary functionality is to act as a data holder, allowing data to be shared across User Interface Controllers 206 using an object-based programming model.

[0092] BOs 207 perform validation on their attributes as they are being set to maintain the integrity of the information they contain. BOs 207 also expose methods other than accessors to manipulate their data, such as methods to change the life cycle state of a BO 207 or to derive the value of a calculated attribute.

[0093] In many cases, a BO 207 will have its own table in the database and its own window for viewing or editing operations.

[0094] Business Objects 207 contain information about a single business entity and maintain the integrity of that information. The BO 207 encapsulates business rules that pertain to that single business entity and maintains relationships with other business objects (e.g., a claim contains a collection of supplements). Finally, the BO 207 provides additional properties relating to the status of the information it contains (such as whether that information has changed or not), provides validation of new data when necessary, and calculates attributes that are derived from other attributes (such as Full Name, which is derived from First Name, Middle Initial, and Last Name).

Client Component Adapters

[0095] Client Component Adapters (CCAs) 208 are responsible for retrieving, adding, updating, and deleting business objects in the database. CCAs 208 hide the storage format and location of data from the UI controller 206. The UI controller 206 does not care about where or how objects are stored, since this is taken care of by the CCA 208.

[0096] The CCA 208 marshals data contained in recordsets returned by the server into business objects 207. CCAs 208 masks all remote requests from UI Controller 206 to a specific component, and act as a “hook” for services such as data compression, and data encryption.

COM Component Interface

[0097] A COM Component Interface (CCI) 210 is a “contract” for services provided by a component. By “implementing” an interface (CCI) 210, a component is promising to provide all the services defined by the CCI 20.

[0098] The CCI 210 is not a physical entity (which is why it is depicted with a dotted line). It's only reason for existence is to define the way a component appears to other objects. It includes the signatures or headers of all the public properties or methods that a component will provide.

[0099] To implement a CCI 210, a server component exposes a set of specially named methods, one for each method defined on the interface. These methods should do nothing except delegate the request to a private method on the component which will do the real work.

[0100] The CCI 210 defines a set of related services provided by a component. The CCI allows any component to “hide” behind the interface to perform the services defined by the interface by “implementing” the interface.

Server Component

[0101] Server components 222 are course grained and transaction oriented. They are designed for maximum efficiency.

[0102] Server Components 222 encapsulate all access to the database, and define business transaction boundaries. In addition, Server Components 222 are responsible for ensuring that business rules are honored during data access operations.

[0103] A Server Component 222 performs data access operations on behalf of CCAs 208 or other components and participates in transactions spanning server components 222 by communicating with other server components 222. The Server Component 222 is accessible by multiple front end personalities (e.g., Active Server Pages), and contains business logic designed to maintain the integrity of data in the database.

[0104] FIG. 2D is a flowchart showing the interactions between the CCA, the CCI, and the Server Component in accordance with one embodiment of the present invention. In step 242, a request is made to place client created data on the server database. In step 244, the data is transferred to the server component 222 utilizing a CCI 210. In step 246, the server component 222 stores the data in the server database.

Overview

[0105] The distribution of business rules across tiers of the application directly affects the robustness and performance of the system as a whole. Business rules can be categorized into the following sections: Relationships, Calculations, and Business Events.

Relationships between Business Objects

[0106] Business Objects 207 are responsible for knowing other business objects 207 with which they are associated.

[0107] Relationships between BOs 207 are built by the CCA 208 during the marshaling process. For example, when a CCA 208 builds a claim BO 207, it will also build the collection of supplements if necessary.

Calculated Business Data

[0108] Business rules involving calculations based on business object 207 attributes are coded in the business objects 207 themselves. Participant Full Name is a good example of a calculated attribute. Rather than force the controllers to concatenate the first name, middle initial, and last name every time they wanted to display the full name, a calculated attribute that performs this logic is exposed on the business object. In this way, the code to compose the full name only has to be written once and can be used by many controllers 206.

[0109] Another example of a calculated attribute is the display date of a repeating task. When a task with a repeat rule is completed, a new display date must be determined. This display date is calculated based on the date the task was completed, and the frequency of repetition defined by the repeat rule. Putting the logic to compute the new display date into the Task BO 207 ensures that it is coded only once.

Responses to Business Events

[0110] Business rules that relate to system events and involve no user interaction are enforced on the server components.

[0111] Completion of a task is a major event in the system. When a task is completed, the system first ensures that the performer completing the task is added to the claim. Then, after the task is marked complete in the database, it is checked to see if the task has a repeat rule. If so, another task is created and added to the database. Finally, the event component is notified, because the Task Engine may need to react to the task completion.

[0112] Consider the scenario if the logic to enforce this rule were placed on the UI controller 206.

[0113] The controller 206 calls the Performer Component to see if the performer completing the task has been added to the claim. If the performer has not been added to the claim, then the controller 206 calls the performer component again to add them.

[0114] Next, the controller 206 calls the Task Component to mark the task complete in the database. If the task has a repeat rule, the controller 206 computes the date the task is to be redisplayed and calls the Task Component again to add a new task. Lastly, the controller 206 calls the Event Component to notify the Task Engine of the task completion.

[0115] The above implementation requires five network round trips in its worst case. In addition, any other controller 206 or server component 222 that wants to complete a task must code this logic all over again. Enforcing this rule in the task server component 222 reduces the number of network round trips and eliminates the need to code the logic more than once.

Responses to User Events

[0116] All responses to user events are coordinated by the controller 206. The controller 206 is responsible for actions such as enabling or disabling controls on its form, requesting authorization from the security component, or making calls to the CCA 208.

Authorization

[0117] All logic for granting authorization is encapsulated inside the security component. Controllers 206 and components 222 must ask the security component if the current user is authorized to execute certain business operations in the system. The security component will answer yes or no according to some predefined security logic.

[0118]

Summary
Type of Business Rule	Example	Responsibility
Maintaining relationships	Claim keeps a collection	Business Objects
between BOs	of supplements
Building relationships	CCA builds the claim's	CCAs
between BOs	collection of supplements
Calculated Business Data	Participant calculates its	Business Objects
	full name
Responses to Business	Task Component collab-	Components
Events	orates with other
	components
Requesting Authorization	Task Library controller	Controllers and
	asks the security compo-	Components
	nent if the current user is
	allowed to access Task
	Library
Granting Authorization	Security component	Security Component
	determines whether or
	not the current user can
	access Task Library

[0119] The Default Window Framework provides default window processing for each window contained within the system. This default processing aides the developer in developing robust, maintainable UIs, standardizes common processes (such as form initialization) and facilitates smooth integration with architecture services.

[0120] FIG. 3 shows the life cycle of a typical User Interface and the standard methods that are part of the Window Processing Framework 300.

[0121] The Window Processing Framework 300 encompasses the following:

• [0122] Window Initialization 302;
• [0123] Window Save Processing 304;
• [0124] Window Control State Management 306;
• [0125] Window Data Validation 308;
• [0126] Window Shutdown Processing 310.

[0127] Window Initialization Processing 302: After creating a controller 206 for the desired window, the App object 202 calls a set of standard initialization functions on the controller 206 before the form 204 is displayed to the user. Standardizing these functions makes the UIs more homogeneous throughout the application, while promoting good functional decomposition.

[0128] Window Save Processing 304: Any time a user updates any form text or adds an item to a ListBox, the UI Controller 206 marks the form as “dirty”. This allows the UI controller 206 to determine whether data has changed when the form closes and prompt the user to commit or lose their changes.

[0129] Window Control State Management 306: Enabling and disabling controls and menu options is a very complex part of building a UI. The logic that modifies the state of controls is encapsulated in a single place for maintainability.

[0130] Window Data Validation 308: Whenever data changes on a form, validation rules can be broken. The controller is able to detect those changes, validate the data, and prompt the user to correct invalid entries.

[0131] Window Shutdown Processing 310: The Window Shutdown framework provides a clear termination path for each UI in the event of an error. This reduces the chance of memory leaks, and General Protection failures.

Benefits

[0132] Standardized Processing: Standardizing the window processing increases the homogeneity of the application. This ensures that all windows within the application behave in a consistent manner for the end users, making the application easier to use. It also shortens the learning curve for developers and increases maintainability, since all windows are coded in a consistent manner.

[0133] Simplified Development: Developers can leverage the best practices documented in the window processing framework to make effective design and coding decisions. In addition, a shell provides some “canned” code that gives developers a head start during the coding effort.

[0134] Layered Architecture: Because several architecture modules provide standardized processing to each application window, the core logic can be changed for every system window by simply making modifications to a single procedure.

[0135] To open a new window, the App Object 202 creates the target window's controller 206 and calls a series of methods on the controller 206 to initialize it. The calling of these methods, ArchInitClass, InitClass, InitForm, and ShowForm, is illustrated below.

ArchInitClass

[0136] The main purpose of the ArchInitClass function is to tell the target controller 206 who is calling it. The App Object 202 “does the introductions” by passing the target controller 206 a reference to itself and a reference to the calling controller 206. In addition, it serves as a hook into the controller 206 for adding architecture functionality in the future.

[0137]

Public Sub ArchInitClass(objAPP As Object, objCallingCTLR As
Object)
	′ remember who called me
	Set m_objApp = objApp
	Set m_objCallingCTLR = objCallingCTLR
End Sub

InitClass

[0138] This function provides a way for the App Object 202 to give the target controller 206 any data it needs to do its processing. It is at this point that the target controller 206 can determine what “mode” it is in. Typical form modes include, add mode, edit mode, and view mode. If the window is in add mode, it creates a new BO 207 of the appropriate type in this method.

[0139]

	Public Sub InitClass(colPrevSelection As CArchCollection)
	If colprevSelection Is Nothing Then
	′ no accounts were previously selected
	Set m_colPrevSelection = New CArchCollection
	Set m_colNewSelection = New CArchCollection
	Else
	′ some accounts may have already been selected
	Set m_colPrevSelection = colprevSelection
	Set m_colNewSelection = colPrevSelection.Clone( )
	End If
	Set m_colResults = New CArchCollection
	DetermineFormMode( )
	End Sub

InitForm

[0140] The InitForm procedure of each controller 206 coordinates any initialization of the form 204 before it is displayed. Because initialization is often a multi-step process, InitForm creates the window and then delegates the majority of the initialization logic to helper methods that each have a single purpose, in order to follow the rules of good functional decomposition. For example, the logic to determine a form's 204 state based on user actions and relevant security restrictions and move to that state is encapsulated in the DetermineFormState method.

[0141]

	Public Sub InitForm( )
	′ create my form
	Set m_frmCurrentForm = New frmAccountSearch
	′ figure out the state of my form based on arguments I
	received in InitClass and
	′ enable/disable the appropriate controls
	DetermineFormState( )
	′ fill my form with data
	PopulateForm( )
	End Sub

PopulateForm

[0142] PopulateForm is a private method responsible for filling the form with data during initialization. It is called exactly once by the InitForm method. PopulateForm is used to fill combo boxes on a form 204, get the details of an object for an editing window, or display objects that have already been selected by the user, as in the following example.

[0143]

	Private Sub PopulateForm( )
	Dim acct As CAccount
	Dim item As GTListItem
	′ display any accounts already selected by the user
	′ create and add a ListItem for every Account in the
	previous selection collection
	With frmCurrentForm.lvwResults.ListItems
	.Clear
	For Each acct In m_colPrevSelection
	Set item = .Add(, acct.Number, acct.Number)
	item.SubItems(1) = acct.Name
	Next
	End With
	End Sub

ShowForm

[0144] The ShowForm method simply centers and displays the newly initialized form 204.

[0145]

Public Sub ShowForm( )
	′ center my form
	frmCurrentForm.Move(Screen .Width - frmCurrentForm.Width) /
2,—
	(Screen.Height - frmCurrentForm.Height)
/ 2
	′ display my form
	frmCurrentForm.Show vbModal
End Sub

[0146] It is often necessary to enable or disable controls on a form 204 in response to user actions. This section describes the patterns employed by the Component Based Architecture for MTS (CBAM) to manage this process effectively.

Form Mode

[0147] It is helpful to distinguish between form mode and form state. Form mode indicates the reason the form 204 has been invoked. Often, forms 204 are used for more than one purpose. A common example is the use of the same form to view, add, and edit a particular type of object, such as a task or an insurance claim. In this case, the form's modes would include View, Add, and Update.

[0148] The modes of a form 204 are also used to comply with security restrictions based on the current user's access level. For example, Task Library is a window that limits access to task templates based on the current user's role. It might have a Librarian mode and a Non-Librarian mode to reflect the fact that a non-librarian user cannot be allowed to edit task templates. In this way, modes help to enforce the requirement that certain controls on the form 204 remain disabled unless the user has a certain access level.

[0149] It is not always necessary for a form 204 to have a mode; a form might be so simple that it would have only one mode—the default mode. In this case, even though it is not immediately necessary, it may be beneficial to make the form “mode-aware” so that it can be easily extended should the need arise.

Form State

[0150] A form 204 will have a number of different states for each mode, where a state is a unique combination of enabled/disabled, visible/invisible controls. When a form 204 moves to a different state, at least one control is enabled or disabled or modified in some way.

[0151] A key difference between form mode and form state is that mode is determined when the controller 206 is initialized and remains constant until the controller 206 terminates. State is determined when the window initializes, but is constantly being reevaluated in response to user actions.

Handling UI Events

[0152] When the value of a control on the form 204 changes, it is necessary to reevaluate the state of the controls on the form (whether or not they are enabled/disabled or visible/invisible, etc.). If changing the value of one control could cause the state of a second control to change, an event handler is written for the appropriate event of the first control.

[0153] The following table lists common controls and the events that are triggered when their value changes.

[0154]

	Control	Event
	TextBox	Change
	ComboBox	Change
	ListBox	Click
	CheckBox	Click
	Option Button	Click

[0155] The event handler calls the DetermineFormState method on the controller 206.

Setting the State of Controls

[0156] It is essential for maintainability that the process of setting the state of controls be separate from the process for setting the values of those controls. The DetermineFormState method on the controller 206 forces this separation between setting the state of controls and setting their values.

[0157] DetermineFormState is the only method that modifies the state of any of the controls on the form 204. Because control state requirements are so complex and vary so widely, this is the only restriction made by the architecture framework.

[0158] If necessary, parameters are passed to the DetermineFormState function to act as “hints” or “clues” for determining the new state of the form 204. For complex forms, it is helpful to decompose the DetermineFormState function into a number of helper functions, each handling a group of related controls on the form or moving the form 204 to a different state.

Example

[0159] The Edit/Add/View Task Window has three modes: Edit, Add, and View. In Add mode, everything on the form is editable. Some details will stay disabled when in Edit mode, since they should be set only once when the task is added. In both Add and Edit modes, the repeat rule may be edited. Enabling editing of the repeat rule always disables the manual editing of the task's due and display dates. In View mode, only the Category combo box and Private checkbox are enabled.

[0160]

′ Edit/Add/View Task Form
Private Sub txtName_Change( )
	myController.DetermineFormState
End Sub
′ Edit/Add/View Task Controller
Public Sub DetermineFormState( )
	On Error Goto ErrorHandler
	Select Case m_nFormMode
	′ In Edit Mode, enable only “editable” details and
Repeat Rule editing if necessary
	Case cmFormModeEdit
	EnableAddDetails False
	EnableEditDetails True
	EnableViewDetails True
	If m_frmCurrentForm.chkRepetetiveTask.Checked Then
	EnableEditRepeatRule True
	EnableEditDisplayDueDates False
	Else
	EnableEditRepeatRule False
	EnableEditDisplayDueDates True
	End If
	If m_nFormDirty Then EnableSave True Else
EnableSave False
	′ In Add Mode, enable all details and Repeat Rule
editing if necessary
	Case cmFormModeAdd
	EnableAddDetails True
	EnableEditDetails True
	EnableViewDetails True
	If m_frmCurrentForm.chkRepetetiveTask.Checked Then
	EnableEditRepeatRule True
	EnableEditDisplayDueDates False
	Else
	EnableEditRepeatRule False
	EnableEditDisplayDueDates True
	End If
	If m_nFormDirty Then EnableSave True Else
EnableSave False
	′ In View Mode, disable everything except a few
details
	Case cmFormModeView
	EnableAddDetails False
	EnableEditDetails False
	EnableViewDetails True
	EnableEditRepeatRule False
	EnableEditDisplayDueDates False
	EnableSave False
	Case Else
	End Select
	Exit Sub
ErrorHandler:
	′ error handling
End Sub
′ Edit/Add/View Task Controller
Private Sub EnableAddDetails(bYesNo As Boolean)
	On Error Goto ErrorHandler
	′ Enable or disable controls that should be available only
when the task is being added.
	With frmCurrentForm
	.Name.Enabled = bYesNo
	.Description.Enabled = bYesNo
	.Type.Enabled = bYesNo
	.Level.Enabled = bYesNo
	.Source.Enabled = bYesNo
	End With
	Exit Sub
ErrorHandler:
	′ error handling logic
End Sub

[0161] Window data validation is the process by which data on the window is examined for errors, inconsistencies, and proper formatting. It is important, for the sake of consistency, to implement this process similarly or identically in all windows of the application.

Types of Validation

Input Masking

[0162] Input masking is the first line of defense. It involves screening the data (usually character by character) as it is entered, to prevent the user from even entering invalid data. Input masking may be done programmatically or via a special masked text box, however the logic is always located on the form, and is invoked whenever a masked field changes.

Single-field Range Checking

[0163] Single-field range checking determines the validity of the value of one field on the form by comparing it with a set of valid values. Single-field range checking may be done via a combo box, spin button, or programmatically on the form, and is invoked whenever the range-checked field changes.

Cross-field Validation

[0164] Cross-field validation compares the values of two or more fields to determine if a validation rule is met or broken, and occurs just before saving (or searching). Cross-field validation may be done on the Controller 206 or the Business Object 207, however it is preferable to place the logic on the Business Object 207 when the validation logic can be shared by multiple Controllers 206.

[0165] Invalid data is caught and rejected as early as possible during the input process. Input masking and range checking provide the first line of defense, followed by cross-field validation when the window saves (or searches).

Single-field Validation

[0166] All single-field validation is accomplished via some sort of input masking. Masks that are attached to textboxes are used to validate the type or format of data being entered. Combo boxes and spin buttons may also be used to limit the user to valid choices. If neither of these are sufficient, a small amount of logic may be placed on the form's event handler to perform the masking functionality, such as keeping a value below a certain threshold or keeping apostrophes out of a textbox.

Cross-field Validation

[0167] When the user clicks OK or Save, the form calls the IsFormData Valid on the controller to perform cross-field validation (e.g., verifying that a start date is less than an end date). If the business object 207 contains validation rules, the controller 206 may call a method on the business object 207 to make sure those rules are not violated.

[0168] If invalid data is detected by the controller 206, it will notify the user with a message box and, if possible, the indicate which field or fields are in error. Under no circumstances will the window perform validation when the user is trying to cancel.

Example

[0169]

′ Generic Edit Form
Private Sub cmdOK_Click( )
	On Error Goto ErrorHandler
	′ shut down if my data is valid.
	′ saving/canceling will occur in my controller's
QueryUnload function
	If IsFormDataValid Then Unload Me
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub
Public Function IsFormDataValid( ) As Boolean
	On Error Goto ErrorHandler
	′ assume success
	IsFormDataValid = True
	′ evaluate all validation rules
	With frmCurrentForm
	′ make sure start date is earlier than end date
	If .txtStartDate.Text > .txtEndDate.Text Then
	IsFormDataValid = False
	MsgBox cmMsgInvalidEndDate
	.txtEndDate.SetFocus
	ElseIf ...
	′ more validation rules
	End If
	End With
	Exit Function
ErrorHandler:
	′ error handling logic
End Function

[0170] Window “Save Processing” involves tracking changes to data on a form 204 and responding to save and cancel events initiated by the user.

Tracking Changes to Form Data

[0171] Each window within the CBAM application contains a field within its corresponding control object known as the dirty flag. The dirty flag is set to True whenever an end user modifies data within the window. This field is interrogated by the UI Controller 206 to determine when a user should be prompted on Cancel or if a remote procedure should be invoked upon window close.

[0172] The application shell provides standard processing for each window containing an OK or Save button.

Saving

[0173] The default Save processing is implemented within the UI Controller 206 as follows:

[0174] The UI Controller is Notified that the OK button has been clicked. Then the controller 206 checks its Dirty Flag. If flag is dirty, the controller 206 calls the InterrogateForm method to retrieve data from the form 204 and calls a server component 222 to store the business object 207 in the database. If the Dirty Flag is not set, then no save is necessary. The window is then closed.

Canceling

[0175] When the user cancels a window, the UI Controller 206 immediately examines the Dirty Flag. If the flag is set to true, the user is prompted that their changes will be lost if they decide to close the window.

[0176] Once prompted, the user can elect to continue to close the window and lose their changes or decide not to close and continue working.

[0177] In the event of an error, it is sometimes necessary to shutdown a window or to terminate the entire application. It is critical that all windows follow the shutdown process in order to avoid the GPFs commonly associated with terminating incorrectly. Following is how the window/application is shutdown.

Shutdown Scope

[0178] The scope of the shutdown is as small as possible. If an error occurs in a controller 206 that does not affect the rest of the application, only that window is shut down. If an error occurs that threatens the entire application, there is a way to quickly close every open window in the application. The window shutdown strategy is able to accommodate both types of shutdowns.

Shutdown

[0179] In order to know what windows must be shut down, the architecture tracks which windows are open. Whenever the App Object 202 creates a controller 206, it calls its RegCTLR function to add the controller 206 to a collection of open controllers. Likewise, whenever a window closes, it tells the App Object 202 that it is closing by calling the App Object's 202 UnRegCTLR function, and the App Object 202 removes the closing controller 206 from its collection. In the case of an error, the App Object 202 loops through its collection of open controllers, telling each controller to “quiesce” or shutdown immediately.

GeneralErrorHandler

[0180] The GeneralErrorHandler is a method in MArch.bas that acts as the point of entry into the architecture's error handling mechanism. A component or a controller will call the GeneralErrorHandler when they encounter any type of unexpected or unknown error. The general error handler will return a value indicating what the component or controller should do: (1) resume on the line that triggered the error (2) resume on the statement after the line that triggered the error (3) exit the function (4) quiesce (5) shutdown the entire application.

[0181]

ErrorHandler:
	Select Case CStr(Err.Number)
	′ handle a search with no result error
	Case cmErrNoClaimTreeData
	MsgBox cmMsgNoResultsQuery, vbInformation
	frmCurrentForm.StatusBar.Panels(1) =
cmNoResultsQuery
	′Sets mouse pointer back to default
	frmCurrentForm.MousePointer = vbDefault
	Case Else
	Dim nResumeCode As Integer
	nResumeCode =
GeneralErrorHandler(objApp.objArch.AsMsgStruct, cmController,
—
	cmClassName,
cmMethodName)
	Select Case CStr(nResumeCode)
	Case cmErrorResume
	Resume
	Case cmErrorResumeNext
	Resume Next
	Case cmErrorExit
	Exit Sub
	Case cmErrorQuiesce
	Quiesce
	Case Else
	objApp.Shutdown
	End Select
	End Select
End Sub

[0182] In order to prevent recursive calls the GeneralErrorHandler keeps a collection of controllers that are in the process of shutting down. If it is called twice in a row by the same controller 206, it is able to detect and short-circuit the loop. When the controller 206 finally does terminate, it calls the UnRegisterError function to let the GeneralErrorHandler know that it has shut down and removed from the collection of controllers.

Shutdown Process

[0183] After being told what to do by the GeneralErrorHandler, the controller 206 in error may try to execute the statement that caused the error, proceed as if nothing happened, exit the current function, call its Quiesce function to shut itself down, or call the Shutdown method on the App Object 202 to shut the entire application down.

Searching

[0184] Controllers 206 that manage search windows have a public method named Find<Noun>s where <Noun> is the type of object being searched for. This method is called in the event handler for the Find Now button.

Saving

[0185] Any controller 206 that manages an edit window has a public method called Save that saves changes the user makes to the data on the form 204. This method is called by the event handlers for both the Save and OK buttons (when/if the OK button needs to save changes before closing).

Closing

[0186] A VB window is closed by the user in several ways: via the control-box in upper left corner, the X button in upper right corner, or the Close button. When the form closes, the only method that will always be called, regardless of the way in which the close was initiated, is the form's 204 QueryUnload event handler.

[0187] Because of this, there cannot be a standard Close method. Any processing that must occur when a window closes is to be done in the QueryUnload method on the controller 206 (which is called by the form's QueryUnload event handler).

[0188] The VB statement, Unload Me, appears in the Close button's event handler to manually initiate the unloading process. In this way, the Close button mimics the functionality of the control box and the X button, so that the closing process is handled the same way every time, regardless of how the user triggered the close. The OK button's event handler also executes the Unload Me statement, but calls the Save method on the controller first to save any pending changes.

[0189] Business Objects 207 are responsible for containing data, maintaining the integrity of that data, and exposing functions that make the data easy to manipulate. Whenever logic pertains to a single BO 207 it is a candidate to be placed on that BO. This ensures that it will not be coded once for each controller 206 that needs it. Following are some standard examples of business object logic.

Overview

[0190] The “state” of a business object 207 is the set of all its attributes. Life cycle state refers only to a single attribute (or a small group of attributes) that determine where the BO 207 is in its life cycle. For example, the life cycle states of a Task are Open, Completed, Cleared, or Error. Business objectives usually involve moving a BO toward its final state (i.e., Completed for a Task, Closed for a Supplement, etc.).

[0191] Often, there are restrictions on a BO's movement through its life cycle. For example, a Task may only move to the Error state after first being Completed or Cleared. BOs provide a mechanism to ensure that they do not violate life cycle restrictions when they move from state to state.

Approach

[0192] A BO 207 has a method to move to each one of its different life cycle states. Rather than simply exposing a public variable containing the life cycle state of the task, the BO exposes methods, such as Task.Clear( ), Task.Complete( ), and Task.MarkInError( ), that move the task a new state. This approach prevents the task from containing an invalid value for life cycle state, and makes it obvious what the life cycle states of a task are.

Example

[0193]

′ CTask Business Object
Public Sub MarkInError( )
	On Error Goto ErrorHandler
	Select Case m_nLifeCycleState
	′ move to error only if I've already been completed or
cleared
	Case cmTaskCompleted, cmTaskCleared
	m_nLifeCycleState = cmTaskInError
	′ otherwise, raise an error
	Case Else
	Err.Raise cmErrInvalidLifeCycleState
	End Select
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub

Overview

[0194] Sometimes, a BO 207 acts as a container for a group of other BOs. This happens when performing operations involving multiple BOs. For example, to close, an insurance claim ensures that it has no open supplements or tasks. There might be a method on the insurance claim BO—CanClose( )—that evaluates the business rules restricting the closing of a claim and return true or false. Another situation might involve retrieving the open tasks for a claim. The claim can loop through its collection of tasks, asking each task if it is open and, if so, adding it to a temporary collection which is returned to the caller.

Example

[0195]

′ Claim Business Object
′ Error handling omitted for clarity
Public Function CanClose( ) As Boolean
	CanClose = HasOpenTasks( ) And HasOpenSupplements( )
End Function
Public Function HasOpenTasks( ) As Boolean
	′ assume that I have open tasks
	HasOpenTasks = True
	′ loop through all my tasks and exit if I find one that is
open
	Dim task As CTask
	For Each task In m_colTasks
	If task.IsOpen( ) Then Exit Function
	Next task
	′ I must not have any open tasks
	HasOpenTasks = False
End Function
Public Function HasOpenSupplements( ) As Boolean
	′ assume that I have open supplements
	HasOpenSupplements = True
	′ loop through all my supplements and exit if I find one
that is open
	Dim supp As CSupplement
	For Each supp In m_colSupplements
	If supp.IsOpen( ) Then Exit Function
	Next supp
	HasOpenSupplements = False
End Function
Public Function GetOpenTasks( ) As Collection
	Dim task As CTask
	Dim colOpenTasks As Collection
	For Each task In m_colTasks
	If task.IsOpen( ) Then colOpenTasks.Add task, task.Id
	Next task
	Set GetOpenTasks = colOpenTasks
End Function

Overview

[0196] When a BO 207 is added or updated, it sends all of its attributes down to a server component 222 to write to the database. Instead of explicitly referring to each attribute in the parameter list of the functions on the CCA 208 and server component 222, all the attributes are sent in a single variant array. This array is also known as a structure.

Approach

[0197] Each editable BO 207 has a method named AsStruct that takes the object's member variables and puts them in a variant array. The CCA 208 calls this method on a BO 207 before it sends the BO 207 down to the server component 222 to be added or updated. The reason that this is necessary is that, although object references can be passed by value over the network, the objects themselves cannot. Only basic data types like Integer and String can be sent by value to a server component 222. A VB enumeration is used to name the slots of the structure, so that the server component 222 can use a symbolic name to access elements in the array instead of an index. Note that this is generally used only when performing adds or full updates on a business object 207.

[0198] In a few cases, there is a reason to re-instantiate the BO 207 on the server side. The FromStruct method does exactly the opposite of the AsStruct method and initializes the BO 207 from a variant array. The size of the structure passed as a parameter to FromStruct is checked to increase the certainty that it is a valid structure.

[0199] When a BO 207 contains a reference to another BO 207, the AsStruct method stores the primary key of the referenced BO 207. For example, the Task structure contains a PerformerId, not the performer BO 207 that is referenced by the task. When the FromStruct method encounters the PerformerId in the task structure, it instantiates a new performer BO and fills in the ID, leaving the rest of the performer BO empty.

Example

[0200]

′ CTask Business Object
′ enumeration of all task attributes
Public Enum TaskAttributes
	cmTaskId
	cmTaskName
	:
	cmTaskDescription
End Enum
′ all task attributes declarations here
′ all setter and getter functions here
Public Function AsStruct( ) As CTask
	On Error Goto ErrorHandler
	′ create and fill structure
	Dim vStruct(cmTaskNumOfAttributes − 1) As Variant
	vStruct(cmTaskId) = m_vId
	vStruct(cmTaskName) = m_sName
	vStruct(cmTaskPerformerId) = m_vPerformerId
	:
	vStruct(cmTaskDescription) = m_sDescription
	AsStruct = vStruct
	Exit Function
ErrorHandler:
	Err.Raise Err.Number
End Function
Public Sub FromStruct(vStruct As Variant)
	On Error Goto ErrorHandler
	′ check size of vStruct
	If Ubound(vStruct) <> (cmTaskNumOfAttributes − 1) Then
Err.Raise cmErrInvalidParameters
	′ update my values from the structure
	m_vId = vStruct(cmTaskId)
	m_sName = vStruct(cmTaskName)
	m_vPerformer.Id = vStruct(cmTaskPerformerId)
	:
	m_sDescription = vStruct(cmTaskDescription)
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub

Overview

[0201] Often a copy of a business object 207 is made. Cloning is a way to implement this kind of functionality by encapsulating the copying process in the BO 207 itself. Controllers 206 that need to make tentative changes to a business object 207 simply ask the original BO 207 for a clone and make changes to the clone. If the user decides to save the changes, the controller 206 ask the original BO to update itself from the changes made to the clone.

Approach

[0202] Each BO 207 has a Clone method to return a shallow copy of itself. A shallow copy is a copy that doesn't include copies of the other objects that the BO 207 refers to, but only a copy of a reference to those objects. For example, to clone a task, it does not give the clone a brand new claim object; it gives the clone a new reference to the existing claim object. Collections are the only exception to this rule—they are always copied completely since they contain references to other BOs.

[0203] Each BO 207 also has an UpdateFromClone method to allow it “merge” a clone back in to itself by changing its attributes to match the changes made to the clone.

Example

[0204]

	′ CTask Business Object
	Public Function Clone( ) As CTask
	On Error Goto ErrorHandler
	′ create clone object
	Dim tskClone As CTask
	Set tskClone = New CTask
	′ fill clone with my data
	With tskClone
	.Id = m_vId
	.Name = m_sName
	.PerformerId = m_vPerformerId
	Set .Performer = m_prfPerformer
	:
	.Description = m_sDescription
	End With
	Set Clone = tskClone
	Exit Function
	ErrorHandler:
	Err.Raise Err.Number
	End Function
	Public Sub UpdateFromClone(tskClone As CTask)
	On Error Goto ErrorHandler
	′ set my values equal to the clone's values
	With tskClone
	m_vId = .ID
	m_sName = .Name
	m_vPerformerId = .PerformerId
	Set m_prfPerformer = .Performer
	:
	m_sDescription = .Description
	End With
	Exit Sub
	ErrorHandler:
	Err.Raise Err.Number
	End Sub

Overview

[0205] BOs 207 occasionally are filled only half-full for performance reasons. This is done for queries involving multiple tables that return large data sets. Using half-baked BOs 207 can be an error prone process, so it is essential that the half-baking of BOs are carefully managed and contained.

[0206] In most applications, there are two kinds of windows—search windows and edit/detail windows. Search windows are the only windows that half-bake BOs 207. Generally, half-baking only is a problem when a detail window expecting a fully-baked BO receives a half-baked BO from a search window.

Approach

[0207] Detail windows refresh the BOs 207 they are passed by the search windows, regardless of whether or not they were already fully-baked. This addresses the problems associated with passing half-baked BOs and also helps ensure that the BO 207 is up-to-date.

[0208] This approach requires another type of method (besides Get, Add, Update, and Delete) on the CCA 208: a Refresh method. This method is very similar to a Get method (in fact, it calls the same method on the server component) but is unique because it refreshes the data in objects that are already created. The detail window's controller 206 calls the appropriate CCA 208 passing the BO 207 to be refreshed, and may assume that, when control returns from the CCA 208, the BO 207 will be up-to-date and fully-baked.

[0209] This is may not be necessary if two windows are very closely related. If the first window is the only window that ever opens the second, it is necessary for the second window to refresh the BO 207 passed by the first window if it knows that the BO 207 is baked fully enough to be used.

[0210] CCAs 208 are responsible for transforming data from row and columns in a recordset to business objects 207, and for executing calls to server components 222 on behalf of controllers 206.

Overview

[0211] After asking a component to retrieve data, the CCA 208 marshals the data returned by the component into business objects 207 that are used by the UI Controller 206.

Approach

[0212] The marshaling process is as follows:

[0213] CCAs 208 call GetRows on the recordset to get a copy of its data in a variant array in order to release the recordset as soon as possible. A method exist to coordinate the marshaling of each recordset returned by the component.

[0214] Only one recordset is coordinated in the marshaling process of a single method. A method exist to build a BO from a single row of a recordset. This method is called once for each row in the recordset by the marshaling coordination method.

Example

[0215]

	′ Task CCA
	Public Function GetAllTasks( ) As Collection
	On Error Goto ErrorHandler
	′ call a helper method to retrieve tasks
	Dim vRows As Variant
	vRows = RetrieveAllTasks
	Dim i As Integer
	Dim task As CTask
	Dim colTasks As Collection
	Set colTasks = New Collection
	′ vRows is dimmed as column, row. Loop til I run out of
	rows.
	For i = 0 To Ubound(vRows, 2)
	′ build BO using helper method
	Set task = BuildTaskFromRow(vRows, i)
	′ add to collection with ID as the key
	colTasks.Add task, task.Id
	Next i
	Set MarshalTasks = colTasks
	Exit Function
	ErrorHandler:
	Err.Raise Err.Number
	End Function
	Private Function RetrieveAllTasks( ) As Variant
	On Error Goto ErrorHandler
	′ call my component and get a recordset full of all tasks
	Dim rs As ADOR.Recordset
	Set rs = tskComp.GetAllTasks( )
	′ get data in variant array from the recordset
	GetAllTasks = rs.GetRows
	′ release the recordset ASAP
	rs.Close
	Set rs = Nothing
	Exit Function
	ErrorHandler:
	Err.Raise Err.Number
	End Function
	Private Function BuildTaskFromRow(vRows As Variant,
	nCurrentRow As Integer, —
	Optional task As CTask) As
	CTask
	On Error Goto ErrorHandler
	′ create task if it wasn't passed
	If task Is Nothing Then Set task = New CTask
	′ fill task with data
	With task
	.Id = vRows(0, nCurrentRow)
	.Name = vRows(1, nCurrentRow)
	.PerformerId = vRows(2, nCurrentRow)
	:
	.Description = vRows(32, nCurrentRow)
	End With
	Set BuildTaskFromRow = task
	Exit Function
	ErrorHandler:
	Err.Raise Err.Number
	End Function

Overview

[0216] The logic to refresh BOs 207 is very similar to the logic to create them in the first place. A “refresh” method is very similar to a “get” method, but must use BOs 207 that already exist when carrying out the marshalling process.

Example

[0217]

′ Task CCA
Public Sub RefreshTask(task As CTask)
	On Error Goto ErrorHandler
	′ call a helper method to retrieve tasks
	Dim vRow As Variant
	vRow = RetrieveTaskWithId(task.Id)
	BuildTaskFromRow vRow, i, task
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub
Private Function RetrieveTaskWithId(vId As Variant) As Variant
	On Error Goto ErrorHandler
	′ call my component and get a recordset full of all tasks
	Dim rs As ADOR.Recordset
	Set rs = tskComp.GetTaskWithId(vId)
	′ get data in variant array from the recordset
	RetrieveTaskWithId = rs.GetRows
	′ release the recordset ASAP
	rs.Close
	Set rs = Nothing
	Exit Function
ErrorHandler:
	Err.Raise Err.Number
End Function

Overview

[0218] Controllers 206 are responsible for creating and populating new BOs 207. To add a BO 207 to the database, the controller 206 must call the CCA 208, passing the business object 207 to be added. The CCA 208 calls the AsStruct method on the BO 207, and pass the BO structure down to the component to be saved. It then updates the BO 207 with the ID and timestamp generated by the server. Note the method on the CCA 208 just updates the BO 207.

Example

[0219]

	′ Task CCA
	Public Sub AddTask (task As CTask)
	On Error Goto ErrorHandler
	′ call component to add task passing a task structure
	Dim vIdAndTimestamp As Variant
	vIdAndTimestamp = tskComp.AddTask (task.AsStruct())
	′ update ID and Timestamp on task
	task.Id = vIdAndTimestamp (0)
	task.TimeStamp = vIdAndTimestamp (1)
	Exit Sub
	ErrorHandler:
	Err.Raise Err.Number
	End Sub

Overview

[0220] The update process is very similar to the add process. The only difference is that the server component only returns a timestamp, since the BO already has an ID.

Example

[0221]

′ Task CCA
Public Sub UpdateTask(task As CTask)
	On Error Goto ErrorHandler
	′ call component to update task passing a task structure
	Dim lTimeStamp As Long
	lTimeStamp = tskComp.AddTask(task.AsStruct( ))
	′ update Timestamp on task
	task.TimeStamp = lTimeStamp
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub

Deleting Overview

[0222] Like the add and the update methods, delete methods take a business object 207 as a parameter and do not have a return value. The delete method does not modify the object 207 it is deleting since that object will soon be discarded.

Example

[0223]

′ Task CCA
Public Sub DeleteTask(task As CTask)
	On Error Goto ErrorHandler
	′ call component to update task passing a the ID and
Timestamp
	tskComp.DeleteTask task.Id, task.TimeStamp
	Exit Sub
ErrorHandler:
	Err.Raise Err.Number
End Sub

[0224] Server components 222 have two purposes: enforcing business rules and carrying out data access operations. They are designed to avoid duplicating logic between functions.

Enforcing Encapsulation

[0225] Each server component 222 encapsulates a single database table or a set of closely related database tables. As much as possible, server components 222 select or modify data from a single table. A component occasionally selects from a table that is “owned” or encapsulated by another component in order to use a join (for efficiency reasons). A server component 222 often collaborates with other server components to complete a business transaction.

Partioning Logic between Multiple Classes

[0226] If the component becomes very large, it is split into more than one class. When this occurs, it is divided into two classes—one for business rules and one for data access. The business rules class implements the component's interface and utilizes the data access class to modify data as needed.

Example

[0227]

Private Function MarkTaskInError(vMsg As Variant, —
	vTaskId As Variant, —
	lTimestamp As Variant, —
	sReason As String) As Long
	On Error GoTo ErrorHandler
	Const cmMethodName = “MarkTaskInError”
	′ set the SQL statement
	Dim sSQL As String
	sSQL = cmSQLMarkTaskInError
	′ get a new timestamp
	Dim lNewTimeStamp As Long
	lNewTimeStamp = GetTimeStamp( )
	′ create and fill a collection of arguments to be merged
with
	′ the SQL by the ExecuteQuery method
	Dim colArgs As CCollection
	Set colArgs = New CCollection
	With colArgs
	Add lNewTimeStamp
	Add cmDBBooleanTrue
	.Add sReason
	.Add vTaskId
	.Add lTimestamp
	End With
	′ run the SQL and set my return value
	ExecuteQuery vMsg, cmUpdate, sSQL, colArguments:=colArgs
	MarkTaskInError = lNewTimeStamp
	′ tell MTS I'm done
	GetObjectContext.SetComplete
	Exit Function
ErrorHandler:
	′ do error handling here
End Function

[0228] With the exception of “Class_Initialize”, “Class_Terminate”, and methods called within an error handler, every function or subroutine has a user defined ‘On Error GoTo’ statement. The first line in each procedure is: On Error GoTo ErrorHandler. A line near the end of the procedure is given a label “ErrorHandler”. (Note that because line labels in VB 5.0 have procedure scope, each procedure can have a line labeled “ErrorHandler”). The ErrorHandler label is preceded by a Exit Sub or Exit Function statement to avoid executing the error handling code when there is no error.

[0229] Errors are handled differently based on the module's level within the application (i.e., user interface modules are responsible for displaying error messages to the user).

[0230] All modules take advantage of technical architecture to log messages. Client modules that already have a reference to the architecture call the Log Manager object directly. Because server modules do not usually have a reference to the architecture, they use the LogMessage( ) global function complied into each server component.

[0231] Any errors that are raised within a server component 222 are handled by the calling UI controller 206. This ensures that the user is appropriately notified of the error and that business errors are not translated to unhandled fatal errors.

[0232] All unexpected errors are handled by a general error handler function at the global Architecture module in order to always gracefully shut-down the application.

[0233] The error handler for each service module contains a Case statement to check for all anticipated errors. If the error is not a recoverable error, the logic to handle it is first tell MTS about the error by calling GetObjectContext.SetAbort( ). Next, the global LogMessage( ) function is called to log the short description intended for level one support personnel. Then the LogMessage( ) function is called a second time to log the detailed description of the error for upper level support personnel. Finally, the error is re-raised, so that the calling function will know the operation failed.

[0234] A default Case condition is coded to handle any unexpected errors. This logs the VB generated error then raises it. A code sample is provided below:

[0235] Following is an example of how error handling in the task component is implemented when an attempt is made to reassign a task to a performer that doesn't exist. Executing SQL to reassign a task to a non-existent performer generates a referential integrity violation error, which is trapped in this error handler:

[0236]

′Class Declarations
Private Const cmClassName = “CTaskComp”
Public Sub ReassignTask(...)
	On Error GoTo ErrorHandler
	Private Const cmMethodName = “ReassignTask”
	Private Const cmErrReassignTask = “Could not reassign
task.”
	:
	′ logic to reassign a task
	:
	GetObjectContext.SetComplete
	Exit Sub
ErrorHandler:
	Dim sShortDescr As String
	sShortDescr = cmErrReassignTask
	′ log short description as warning
	LogMessage vMsg, Err.Nurnber, cmSeverityWarning,
cmClassName, cmMethodName, sShortDescr
	Dim sLongDescr As String
	Select Case Err.Number
	Case cmErrRefIntegrityViolation
	GetObjectContext.SetAbort
	sLongDescr = “Referential integrity violation -
tried ” —
	& “to reassign task to a non-existant
performer. ” —
	& “Association ID: ” & sAssnId —
	& “Association Type: ” & sAssnType —
	& “Old Performer Id: ” & sOldPerformerId —
	& “New Performer Id: ” & sNewPerformerId
	′ log long description as severe
	LogMessage vMsg, Err.Number, cmSeveritySevere,
cmClassName, cmMethodName, —
	sLongDescr
	Err.Raise Err.Number
	:
	′ more error handling
	:
	Case Else
	′ let architecture handle unanticipated error
	Dim nResumeCode As Integer
	nResumeCode = GeneralErrorHandler(vMsg, cmServer,
cmClassName, cmMethodName)
	Select Case nResumeCode
	Case cmErrorResume
	Resume
	Case cmErrorResumeNext
	Resume Next
	Case cmErrorExit
	Exit Sub
	Case Else
	GetObjectContext.Abort
	Err.Raise Err.Number
	End Select
	End Select
End Sub

[0237] All CCI's, CCA's, Business Objects, and Forms raise any error that is generated. A code sample is provided below:

[0238]

	Sub SubName ( )
	On Error GoTo ErrorHandler
	<the procedure's code here>
	.........
	Exit Sub
	ErrorHandler:
	Err.Raise Err.Number
	End Sub

[0239] The user interface controllers 206 handle any errors generated and passed up from the lower levels of the application. UI modules are responsible for handling whatever errors might be raised by server components 222 by displaying a message box to the user.

[0240] Any error generated in the UI's is also displayed to the user in a dialog box. Any error initiated on the client is logged using the LogMessage( ) procedure. Errors initiated on the server will already have been logged and therefore do not need to be logged again.

[0241] All unexpected errors are trapped by a general error method at the global architecture module. Depending on the value returned from this function, the controller may resume on the statement that triggered the error, resume on the next statement, call its Quiesce function to shut itself down, or call a Shutdown method on the application object to shutdown the entire application.

[0242] No errors are raised from this level of the application, since controllers handle all errors. A code sample of a controller error handler is provided below:

[0243]

′Class Constants
Private Const cmClassName As String = “<ComponentName>”
Sub SubName( )
	On Error GoTo ErrorHandler
	Const cmMethodName As String = “<MethodName>”
	:
	:
	<the procedure's code here>
	:
	:
	Exit Sub
ErrorHandler:
	Select Case CStr(Err.Number)
	Case ...
	′display the error to the user
	′ perform any necessary logic
	Exit Sub (or Resume, or Resume Next)
	:
	:
	Case Else
	Dim nResumeCode As Integer
	nResumeCode = GeneralErrorHandler(vMsg,
cmController, cmClassName, cmMethodName)
	Select Case CStr(nResumeCode)
	Case cmErrorResume
	Resume
	Case cmErrorResumeNext
	Resume Next
	Case cmErrorExit
	Exit Sub
	Case cmErrorQuiesce
	Quiesce
	Case Else
	objApp.SHUTDOWN
	End Select
	End Select
End Sub

[0244] The CBAM application is constructed so that it can be localized for different languages and countries with a minimum effort or conversion.

[0245] The CBAM architecture provides support for certain localization features:

• [0246] Localizable Resource Repository;
• [0247] Flexible User Interface Design;
• [0248] Date Format Localization; and
• [0249] Exposure of Windows Operation System Localization Features.

[0250]

Localization Approach Checklist
	Supported via	Supported via	Best Practices
	Architecture	Architecture	and
Localization Feature	Service	API's	Assumptions*
Language Code	✓
(Locale Identifier)
Time Zones			✓
Date/Time		✓
Name			✓
Telephone Numbers			✓
Functions to Avoid			✓
Weights and Measures			✓
Money			✓
Addresses/Address			✓
Hierarchies
Menus, Icons, Labels/			✓
Identifiers on
Windows
Messages/Dialogs	✓
String Functions, Sort	✓
Order and String
Comparison
Code Tables	✓
Drop-Down Lists	✓
Form & Correspond-			✓
ence Templates
Online and Printed			✓
Documentation
Database (DB2)			✓
3rd Party Controls			✓
Miscellaneous			✓

[0251] The CBAM application has an infrastructure to support multiple languages. The architecture acts as a centralized literals repository via its Codes Table Approach.

[0252] The Codes Tables have localization in mind. Each row in the codes table contains an associated language identifier. Via the language identifier, any given code can support values of any language.

[0253] Flexible user interface 400 and code makes customization easy. The FIG. 4 illustrates how different languages are repainted and recompiled. For example, both a English UI 404, and a French UI 406 are easily accommodated. This entails minimal effort because both UIs share the same core code base 402. Updates to the UIs are merely be a superficial change.

[0254] Generic graphics are used and overcrowding is avoided to create a user interface which is easy to localize.

[0255] Language localization settings affect the way dates are displayed on UIs (user interfaces). The default system display format is different for different Language/Countries. For Example:

• • [0256] English (United States) displays “mm/dd/yy” (e.g., “05/16/98”)
  • [0257] English (United Kingdom) displays “dd/mm/yy” (e.g., “16/05/98”).

[0258] The present inventions UI's employ a number of third-party date controls including Sheridan Calendar Widgets (from Sheridan Software) which allow developers to set predefined input masks for dates (via the controls' Property Pages; the property in this case is “Mask”).

[0259] Although the Mask property can be manipulated, the default setting is preferably accepted (the default setting for Mask is “0—System Default”; it is set at design time). Accepting the default system settings eliminates the need to code for multiple locales (with some possible exceptions), does not interfere with intrinsic Visual Basic functions such as DateAdd, and allows dates to be formatted as strings for use in SQL.

[0260] The test program illustrated below shows how a date using the English (United Kingdom) default system date format is reformatted to a user-defined format (in this case, a string constant for use with DB2 SQL statements):

• [0261] Const cmDB2DateAndTime=“mm-dd-yyyy-h.mm.ss”
• [0262] Private Sub cmdConvToDB2_Click( )
  • [0263] Dim sDB2Date As String
  • [0264] sDB2Date=Format$(SSDateCombol.Date,
    • [0265] cmDB2DateAndTime)
  • [0266] txtDB2String.Text=sDB2Date
• [0267] End Sub

[0268] The CBAM architecture exposes interface methods on the RegistryService object to access locale specific values which are set from the control panel.

[0269] The architecture exposes an API from the RegistryService object which allows access to all of the information available in the control panel. Shown below is the signature of the API:

• • [0270] GetRegionalInfo(Info As RegionalInfo) As String
    • [0271] Where RegionalInfo can be any of the values in the table below:

[0272]

RegionalInfo Values
CmLanguageId	CmDTDateSeparator	cmDayLongNameMonday	cmMonthLongNameJan
CmLanguageLocalized	CmDTTimeSeparator	cmDayLongNameTuesday	cmMonthLongNameFeb
CmLanguageEnglish	CmDTShortDateFormat	cmDayLongNameWednesday	cmMonthLongNameMar
CmLanguageAbbr	CmLDTongDateFormat	cmDayLongNameThursday	cmMonthLongNameApr
CmLanguageNative	CmDTTimeFormat	cmDayLongNameFriday	cmMonthLongNameMay
CmCountryId	CmDTDateFormatOrdering	cmDayLongNameSaturday	cmMonthLongNameJun
CmCountryLocalized	CmDTLongDateOrdering	cmDayLongNameSunday	cmMonthLongNameJul
CmCountryEnglish	CmDTTimeFormatSpecifier	cmDayAbbrNameMonday	cmMonthLongNameAug
CmCountryAbbr	CmDTCenturyFormatSpecifier	cmDayAbbrNameTuesday	cmMonthLongNameSep
CmCountryNative	CmDTTimeWithLeadingZeros	cmDayAbbrNameWednesday	cmMonthLongNameOct
CmLanguageDefaultId	CmDTDayWithLeadingZeros	cmDayAbbrNameThursday	cmMonthLongNameNov
CmCountryDefaultId	CmDTMonthWithLeadingZeros	cmDayAbbrNameFriday	cmMonthLongNameDec
	CmDTDesignatorAM	cmDayAbbrNameSaturday	cmMonthAbbrNameJan
	CmDTDesignatorPM	cmDayAbbrNameSunday	cmMonthAbbrNameFeb
			cmMonthAbbrNameMar
			cmMonthAbbrNameApr
			cmMonthAbbrNameMay
			cmMonthAbbrNameJun
			cmMonthAbbrNameJul
			cmMonthAbbrNameAug
			cmMontbAbbrNameSep
			cmMonthAbbrNameOct
			cmMonthAbbrNameNov
			cmMonthAbbrNameDec

Get RegionalInfo Example:

[0273]

	Private Sub Command1_Click( )
	MsgBox “This is the language id for English: ” & —
	GetRegionalInfo(cmLanguageId)
	End Sub

[0274] The Logical Unit of Work (LUW) pattern enables separation of concern between UI Controllers 206 and business logic.

Overview

[0275] Normally, when a user opens a window, makes changes, and clicks OK or Save, a server component 222 is called to execute a transaction that will save the user's changes to the database. Because of this, it can be said that the window defines the boundary of the transaction, since the transaction is committed when the window closes.

[0276] The LUW pattern is useful when database transactions span windows. For example, a user begins editing data on one window and then, without saving, opens another window and begins editing data on that window, the save process involves multiple windows. Neither window controller 206 can manage the saving process, since data from both windows must be saved as an part of an indivisible unit of work. Instead, a LUW object is introduced to manage the saving process.

[0277] The LUW acts as a sort of “shopping bag”. When a controller 206 modifies a business object 207, it puts it in the bag to be paid for (saved) later. It might give the bag to another controller 206 to finish the shopping (modify more objects), and then to a third controller who pays (asks the LUW to initiate the save).

Approach

[0278] Controllers 206 may have different levels of LUW “awareness”:

• [0279] Requires New: always creates a new LUW;
• [0280] Requires: requires an LUW, and creates a new LUW only if one is not passed by the calling controller;
• [0281] Requires Existing: requires an LUW, but does not create a new LUW if one is not passed by the calling controller. Raises an error if no LUW is passed; and
• [0282] Not Supported: is not capable of using an LUW.

[0283] Controllers 206 that always require a new LUW create that LUW in their ArchInitClass function during initialization. They may choose whether or not to involve other windows in their LUW. If it is desirable for another window to be involved in an existing LUW, the controller 206 that owns the LUW passes a reference to that LUW when it calls the App Object 202 to open the second window. Controllers 206 that require an LUW or require an existing LUW accept the LUW as a parameter in the ArchInitClass function.

[0284] LUWs contain all the necessary logic to persist their “contents”—the modified BOs 207. They handle calling methods on the CCA 208 and updating the BOs 207 with new IDs and/or timestamps.

[0285] Following is an overview of the architecture object model, including a description of each method and the parameters it accepts. Additional sections address the concepts behind specific areas (code caching, message logging, and data access) in more detail.

[0286] FIG. 5 depicts the current properties on the Arch Object 200.

[0287] The following are APIs located on the Arch Object 200 which return either a retrieved or created instance of an object which implements the following interfaces:

• [0288] CodesMan( ) 500;
• [0289] TextMan( ) 502;
• [0290] IdMan( ) 504;
• [0291] RegMan( ) 506;
• [0292] LogMan( ) 508;
• [0293] ErrMan( ) 510;
• [0294] UserMan( ) 512; and
• [0295] SecurityMan( ) 514.
  AsMsgStruct( )

[0296] This method on the Arch Object returns a variant structure to pass along a remote message.

Syntax:

• • [0297] Public Function AsMsgStruct( ) As Variant
  • [0298] End Function
    Example:
  • [0299] Dim vMsg As Variant
  • [0300] vMsg=objArch.AsMsgStruct

[0301] The following are APIs located on the interface of the Arch Object 200 named CodesMan 500:

• [0302] CheckCacheFreshness( );
• [0303] FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]);
• [0304] FilterCodes(colAllCodes, nCodeStatus);
• [0305] GetCategoryCodes(nCategory);
• [0306] GetCodeObject(nCategory, sCode);
• [0307] GetResourceString(lStringId);
• [0308] GetServerDate( );
• [0309] RefreshCache( );
• [0310] RemoveValidDates(sCode, colPassedInAssignedCodes); and
• [0311] SetServerDate(dtServerDate).
  CheckCacheFreshness( )

[0312] Checks whether the cache has expired, if so refresh.

Syntax:

[0313]

	Private Sub CheckCacheFreshness( )
	End Sub

Example:

[0314]

	CheckCacheFreshness

FillControl( )

[0315] This API is used to fill listboxes or comboboxes with values from a list of CodeDecodes. Returns a collection for subsequent lookups to Code objects used to fill controls.

Syntax:

[0316]

	Public Function FillControl (ctlControl As Object, nCategory As
	CodeDecodeCats, nFillType As CodeDecodeLengths, Optional
	nCodeStatus As CodeDecodeFilters = cmValidCodes, Optional
	colAssignedCodes As CCollection) As CCollection
	End Function

Parameters:

[0317]

Parameters:
ctlControl: A reference to a passed in listbox or combobox.
nCategory: The integer based constant which classified these
CodeDecodes from others. Several of the valid constants include:
	cmCatTaskType = 1
	cmCatSource
	cmCatTaskStatus
nFillType: The attribute of the CodeDecode which you want to fill.
Several of the valid values include:
	cmCode
	cmShortDecode
	cmLongDecode
nCodeStatus: Optional value which filters the Code Decodes according to
their Effective and Expiration dates. Several of the valid constants include:
	cmAllCodes	Pending + Valid + Expired Codes
	cmPendingCodes	Codes whose effective date is greater
		than the current date
	cmValidCodes	Not Pending or Expired Codes
colAssignedCodes: Used when filling a control which should fill and
include assigned values.

Example:

[0318]

	‘Declare an instance variable for States collection on object
	Private colStates As CCollection
	‘Call FillControll API, and set local collection inst var to collection
	of codes which were used to fill the controll. This collection will
	be used for subsequent lookups.
	Set colStates = objArch.CodesMan.FillControl
	(frmCurrent.Form.cboStates, cmCatStates, cmLongDecode)

FilterCodes( )

[0319] Returns a collection of code/decodes that are filtered using their effective and expiration dates based on which nCodeStatus is passed from the fillcontrol method.

Syntax:

[0320]

	Private Function FilterCodes (colAllCodes As CCollection,
	nCodeStatus As CodeDecodeFilters) As CCollection
	End Function

Parameters:

[0321]

	colAllCodes:
	nCodeStatus:

Example:

[0322]

	Set colFilteredCodes = FilterCodes (colCodes, nCodeStatus)

GetCategoryCodes( )

[0323] Returns a collection of CCode objects given a valid category

Syntax:

[0324]

	Public Function GetCategoryCodes (nCategory As
	CodeDecodeCats) As CCollection
	End Function

Parameters:

[0325]

	nCategory: The integer based constant which classified these
	CodeDecodes from others.

Example:

[0326]

Dim colMyStates As CCollection
Set colMyStates = objArch.CodesMan.GetCategoryCodes(cmCatStates)
′Below shows an example of looking up the Code value for the currently
selected state.
With frmCurrentForm.cboStates
If .ListIndex > −1 Then
Dim objCode As CCode
	Set objCode = colStates(.ItemData(.ListIndex))
	sStateCode = objCode.Code
End If
End With

GetCodeObject( )

[0327] Returns a valid CCode object given a specific category and code.

Syntax:

[0328]

	Public Function GetCodeObject (nCategory As CodeDecodeCats,
	sCode As String) As CCode
	End Function

Parameters:

[0329]

	nCategory: The integer based constant which classified these
	CodeDecodes from others.
	sCode: A string indicating the Code attribute of the CodeDecode
	object.

Example:

[0330]

	frmCurrentForm.lblState = objArch.CodesMan.GetCodeObject
	(cmCatStates, “IL”).LongDecode

GetResourceString( )

[0331] Returns a string from the resource file given a specific string ID.

Syntax:

[0332]

	Private Function GetResourceString (lStringId As Long) As
	String
	End Function

Parameters:

[0333]

	lStringId: the id associated with the string in the resource file.

Example:

[0334]

	sMsg = arch.CodesMan.GetResourceString (CLng (vMessage))

GetServerDate( )

[0335] Returns the date from the server.

Syntax:

[0336]

	Private Function GetServerDate( ) As Date
	End Function

Example:

[0337]

	SetServerDate CCA.GetServerDate

Refresh Cache( )

[0338] Refreshes all of the code obhjects in the cache.

Syntax:

[0339]

	Private Sub RefreshCache ( )
	End Sub

Example:

[0340]

	m_Cache.RefreshCache

RemoveValidCodes( )

[0341] Removes all valid codes from the passed in assigned codes collection, which is used to see which codes are assigned and not valid.

Syntax:

[0342]

	PrivateSub RemoveValidCodes (sCode As String,
	colPassedInAssignedCodes As CCollection)
	End Sub

Parameters:

[0343]

	sCode: Name of code
	colPassedInAssignedCodess: Codes already in use.

Example:

[0344]

	RemoveValidCodes codCode.Code, colPassedInAssignedCodes

SetServerDate( )

[0345] Sets the server date.

Syntax:

[0346]

	Private Sub SetServerDate (dtServerDate As Date)
	End Sub

Parameters:

[0347]

	dtServerDate: Date of Server.

Example:

[0348]

	SetServerDate CCA.GetServerDate

[0349] The following are APIs located on the interface of the Arch Object 200 named TextMan 502.

• [0350] PairUpAposts( );
• [0351] PairUpAmps( ); and
• [0352] MergeParms ( ).
  PairUpAposts ( )

[0353] Pairs up apostrophes in the passed string.

Syntax:

[0354]

Public Function PairUpAposts (sOriginalString As String) As String
End Function

Parameters:

[0355]

sOriginalString: string passed in by the caller

Example:

[0356]

Dim sString As String
sString = objArch.TextMan.PairUpAposts (“This is Monika's string”)
‘expected return: sString = “This is Monika''s string”

PairUpAmps ( )

[0357] Pairs up ampersands in the passed string.

Syntax:

[0358]

	Public Function PairUpAmps (sOriginalString As String) As String
	End Function

Parameters:

[0359]

	sOriginalString: String passed in by the caller

Example:

[0360]

	Dim sString As String
	sString = objArch.TextMan.PairUpAmps (“Forms&Corr”)
	‘expected return: sString = “Forms&Corr”

MergeParms ( )

[0361] Merges string with the passed parameters collection.

Syntax:

[0362]

Public Function MergeParms (sString As String, colParms As
CCollection) As String
End Function

Parameters:

[0363]

sOriginalString: string passed in by the caller
colParms As Ccollection: collection of the parameters passed in by
the caller

Example:

[0364]

Dim sString As String
sString = objArch.TextMan.MergeParms (sString, colParms)

[0365] The following are APIs located on the interface of the Arch Object 200 named IdMan 504:

• [0366] GetGUID( );
• [0367] GetSequenceID( );
• [0368] GetTimeStamp( );
• [0369] GetTrackingNbr( ); and
• [0370] GetUniqueId( ).
  GetGUID ( )
  Syntax:

[0371]

	Public Function GetGUID ( )
	End Function

Example:

[0372]

	Dim vNewGuid As Variant
	vNewGuid = objArch.IdMan.GetGUID

GetSequenceId ( )
Syntax:

[0373]

Public Function GetSequenceId (STemplateType As CounterName)
As String
End Function

Parameters:

[0374]

sTemplate: The string specifying the template requesting as sequence id
	(i.e. cmCountFC = Forms & Corr)

Example:

[0375]

frmCurrentForm.txtTemplateNumber = objArch.IdMan.GetSequenceId
(cmCountFC)

GetTimeStamp ( )
Syntax:

[0376]

	Public Function GetTimeStamp ( )
	End Function

Example:

[0377]

	Dim nNewTimeStamp As Long
	nNewTimeStamp = objArch.IdMan.GetTimeStamp

GetTrackingNbr ( )
Syntax:

[0378]

	Public Function GetTrackingNbr ( )
	End Function

Example:

[0379]

	Set objTechArch = New CTechArch
	sUniqueTrackNum = objTechArch.IdMan.GetTrackingNbr

GetUniqueId ( )
Syntax:

[0380]

	Public Function GetUniqueId ( )
	End Function

Example:

[0381]

	Dim vUid As Variant
	vNewUid = objArch.IdMan.GetUniqueId

[0382] The following are APIs located on the interface of the Arch Object 200 named RegMan 506:

• [0383] GetCacheLife( );
• [0384] GetClientDSN( );
• [0385] GetComputerName( );
• [0386] GetDefaultAndValidate( );
• [0387] GetFCArchiveDirectory( );
• [0388] GetFCDistributionDirectory( );
• [0389] GetFCMasterDirectory( );
• [0390] GetFCUserDirectory( );
• [0391] GetFCWorkingDirectory( );
• [0392] GetHelpPath( );
• [0393] GetLocalInfo( );
• [0394] GetLogLevel( );
• [0395] GetRegionalInfo( );
• [0396] GetRegValue( );
• [0397] GetServerDSN( );
• [0398] GetSetting( );
• [0399] GetTimerLogLevel( );
• [0400] GetTimerLogPath( ); and
• [0401] GetUseLocalCodes( ).
  GetCacheLife( )
  Syntax:

[0402]

	Public Function GetCacheLife ( ) As String
	End Function

Example:

[0403]

	Dim s As String
	s = objArch.RegMan.GetCacheLife

GetClientDSN( )
Syntax:

[0404]

	Public Function GetClientDSN( ) As String
	End Function

Example:

[0405]

	Dim s As String
	s = objArch.RegMan.GetClientDSN

GetComputerName( )
Syntax:

[0406]

	Public Function GetComputerName ( ) As String
	End Function

Example:

[0407]

	Dim s As String
	s = objArch.RegMan.GetComputerName

Syntax:

[0408]

Private Function GetDefaultAndValidate (sKey As String) As String
End Function

Parameters:

[0409]

sKey: The key within the registry of which the user is requesting
(i.e.: Help Path)

Example:

[0410]

Dim sDefault As String
sDefault = objArch.RegMan.GetDefaultAndValidate (sKey)

GetFCArchiveDirectory( )
Syntax:

[0411]

	Public Function GetFCArchiveDirectory ( ) As String
	End Function

Example:

[0412]

	Dim s As String
	s = objArch.RegMan.GetFCArchiveDirectory

GetFCDistributionDirectory( )
Syntax:

[0413]

	Public Function GetFCDistributionDirectory ( ) As String
	End Function

Example:

[0414]

	Dim s As String
	s = objArch.RegMan.GetFCDistributionDirectory

GetFCMasterDirectory( )
Syntax:

[0415]

	Public Function GetFCMasterDirectory ( ) As String
	End Function

Example:

[0416]

	Dim s As String
	s = objArch.RegMan.GetFCMasterDirectory

GetFCUserDirectory( )
Syntax:

[0417]

	Public Function GetFCUserDirectory ( ) As String
	End Function

Example:

[0418]

	Dim s As String
	s = objArch.RegMan.GetFCUserDirectory

GetFCWorkingDirectory( )
Syntax:

[0419]

	Public Function GetFCWorkDirectory ( ) As String
	End Function

Example:

[0420]

	Dim s As String
	s = objArch.RegMan.GetFCWorkingDirectory

GetHelpPath( )
Syntax:

[0421]

	Public Function GetHelpPath ( ) As String
	End Function

Example:

[0422]

	Dim s As String
	s = objArch.RegMan.GetHelpPath

GetLocalInfo( )
Syntax:

[0423]

	Public Function GetLocalInfo ( ) As String
	End Function

Example:

[0424]

	Dim s As String
	s = objArch.RegMan.GetLocalInfo

GetLogLevel( )
Syntax:

[0425]

	Public Function Get LogLevel ( ) As String
	End Function

Example:

[0426]

	Dim s As String
	s = objArch.RegMan.GetLogLevel

GetRegionalInfo( )

[0427] Allows access to all locale specific values which are set from control panel.

Syntax:

[0428]

Public Function GetRegionalInfo(Info As RegionalInfo) As String
End Function

Parameters:

[0429]

Info: string containing the regional information. Several of the valid
constants include:
	cmLanguageId = &H1	′ language id
	cmLanguageLocalized = &H2	′ localized name of language
	cmLanguageEnglish = &H1001	′ English name of language
	cmLanguageAbbr = &H3	′ abbreviated language name
	cmLanguageNative = &H4	′ native name of language

Example:

[0430]

	Dim s As String
	s = objArch.RegMan.GetRegionalInfo

GetRegValue( )
Syntax:

[0431]

	Public Function GetRegValue ( ) As String
	End Function

Example:

[0432]

	Dim s As String
	s = objArch.RegMan.GetRegValue

GetServerDSN( )
Syntax:

[0433]

	Public Function GetServerDSN ( ) As String
	End Function

Example:

[0434]

	Dim s As String
	s = objArch.RegMan.GetServerDSN

GetSetting( )

[0435] Get setting from the registry.

Syntax:

[0436]

Public Function GetSetting (sKey As String) As String
End Function

Parameters:

[0437]

sKey: The key within the registry of which the user is requesting
(i.e.: Help Path)

Parameters:

[0438]

GetHelpPath = GetSetting (cmRegHelpPathKey)

GetTimerLogLevel( )
Syntax:

[0439]

	Public Function GetTimerLogLevel ( ) As String
	End Function

Example:

[0440]

	Dim s As String
	s = objArch.RegMan.GetTimerLogLevel

GetTimerLogPath( )
Syntax:

[0441]

	Public Function GetTimerLogPath ( ) As String
	End Function

Example:

[0442]

	Dim s As String
	s = objArch.RegMan.GetTimerLogPath

GetUseLocalCodes( )
Syntax:

[0443]

	Public Function GetUseLocalCodes( ) As String
	End Function

Example:

[0444]

	Dim s As String
	s = objArch.RegMan.GetUseLocalCodes

LPSTRToVBString( )

[0445] Extracts a VB string from a buffer containing a null terminated string.

Syntax:

[0446]

	Private Function LPSTRToVBString$ (ByVal s$)
	End Function

[0447] The following are APIs located on the interface of the Arch Object 200 named LogMan 508:

• [0448] LogMessage ( );
• [0449] WriteToDatabase( ); and
• [0450] WriteToLocalLog( ).
  LogMessage ( )

[0451] Used to log the message. This function will determine where the message should be logged, if at all, based on its severity and the vMsg's log level.

Syntax:

[0452]

Syntax:
	Public Sub LogMessage(vMsg As Variant, —
	lSeverity As Long, —
	sClassName As String, —
	sMethodName As String, —
	sVersion As String, —
	lErrorNum As Long, —
	Optional sText As String = vbNullString)
	End Sub

Parameters:

[0453]

vMsg: the standard architecture message
1Severity: the severity of the message
sClassName: the name of the class logging the message
sMethodName: the name of the method logging the message
sVersion: the version of the binary file (EXE or DLL) that contains the
method logging message
1ErrorNum: the number of the current error
sText: an optional parameter containing the text of the message. If
omitted, the text will be looked up in a string file or the generic VB
error description will be used

Example:

[0454]

If Err.Number <> 0 Then
	′ log message
	Arch.LogMan.LogMessage(vMsg, cmSeverityFatal,
“COrganizationCTLR”, “InitForm”,
	GetVersion( ), Err.Number, Err.Description)
	′ re-raise the error
	Err.Raise Err.Number
End If

WriteToDatabase ( )

[0455] Used to log the message to the database on the server using the CLoggingComp. This function returns the TrackingId that is generated by the CLoggingObject.

Syntax:

[0456]

Private Sub WriteToDatabase(vMsg As Variant, msgToLog As CMessage)
End Sub

Parameters:

[0457]

vMsg: the standard architecture message
msgToLog: a parameter containing the text of the message.

Example:

[0458]

If msgToLog.IsLoggableAtLevel (m_1LocalLogLevel) Then
	WriteToDatabase vMsg, msgToLog
End If

WriteToLocalLog ( )

[0459] Used to log the message to either a flat file, in the case of Windows 95, or the NT Event Log, in the case of Windows NT.

Syntax:

[0460]

	Private Sub WriteToLocalLog(msgToLog As CMessage)
	End Sub

Parameters:

[0461]

	msgToLog: a parameter containing the text of the message.

Example:

[0462]

	ErrorHandler:
	WriteToLocalLog msgToLog
	End Sub

[0463] The following are APIs located on the interface of the Arch Object 200 named ErrMan 510:

• [0464] HandleError( );
• [0465] RaiseOriginal( );
• [0466] ResetError( ); and
• [0467] Update( ).
  HandleError( )

[0468] This method is passed through to the general error handler in MArch.bas

Syntax:

[0469]

Public Function HandleError (vMsg As Variant, nCompType As
CompType, sClassName As String, sMethodName As String) As
ErrResumeCodes
End Sub

Parameters:

[0470]

	vMsg:	General Architecture Information
	nCompType:	Contains tier information (Client or Server)
	sClassName:	Class which raised the error.
	sMethodName:	Method which raised the error.

RaiseOriginal( )

[0471] This method is used to Reset the error object and raise.

Syntax:

[0472]

	Public Sub RaiseOriginal ( )
	End Sub

Example:

[0473]

	objArch.ErrMan.RaiseOriginal

ResetError( )

[0474] This method is used to reset attributes.

Syntax:

[0475]

	Public Sub ResetError ( )
	End Sub

Example:

[0476]

	objArch.ErrMan.ResetError

Update( )

[0477] This method is used to update attributes to the values of VBs global Error object.

Syntax:

[0478]

	Public Sub Update ( )
	End Sub

Example:

[0479]

	objArch.ErrMan.Update

[0480] The following are APIs located on the interface of the Arch Object 200 named UserMan 512.

• [0481] UserId;
• [0482] EmployeeId;
• [0483] EmployeeName;
• [0484] EmployeeFirstName;
• [0485] EmployeeLastName;
• [0486] EmployeeMiddleInitial;
• [0487] GetAuthorizedEmployees;
• [0488] IsSuperOf( );
• [0489] IsRelativeOf( ); and
• [0490] IsInRole( ).
  UserId( )
  Syntax:

[0491]

	Public Property Get UserId ( ) As String
	End Property

Example:

[0492]

	Dim sNewUserId As String
	sNewsUserId = objArch.UserMan.UserId

EmployeeId( )
Syntax:

[0493]

	Public Property Get EmployeeId ( ) As String
	End Property

Example:

[0494]

	Dim sNewEmployeeId As String
	sNewEmployeeId = objArch.UserMan.EmployeeId

EmployeeName( )
Syntax:

[0495]

	Public Property Get EmployeeName ( ) As String
	End Property

Example:

[0496]

	Dim sName As String
	sName = objArch.UserMan.EmployeeName

EmployeeFirstName( )
Syntax:

[0497]

	Public Property Get EmployeeFirstName ( ) As String
	End Property

Example:

[0498]

	Dim sFName As String
	sFName = objArch.UserMan.EmployeeFirstName

EmployeeLastName( )
Syntax:

[0499]

	Public Property Get EmployeeLastName ( ) As String
	End Property

Example:

[0500]

	Dim sLName As String
	sLName = objArch.UserMan.EmployeeLastName

EmployeeMiddleInitial( )
Syntax:

[0501]

	Public Property Get EmployeeMiddleInitial ( ) As String
	End Property

Example:

[0502]

	Dim sMI As String
	sMI = objArch.UserMan.EmployeeMiddleInitial

GetAuthorizedEmployees( )

[0503] Creates a collection of user's supervisees from the dictionary and returns GetAuthorizedEmployees—collection of authorized employees

Syntax:

[0504]

	Public Function GetAuthorizedEmployees ( ) As CCollection
	End Function

Example:

[0505]

	Dim colAuth As Collection
	colAuth = objArch.UserMan.GetAuthorizedEmployees

IsSuperOf ( )

[0506] Checks if the current user is supervisor of the passed in user.

Syntax:

[0507]

	Public Function IsSuperOf (sEmpId As String) As Boolean
	End Function

Parameters:

[0508]

	sEmpId: string containing Employee ID Number

Example:

[0509]

	Dim bIsSuperOfMonika As Boolean
	bIsSuperOfMonika = objArch.UserMan.IsSuperOf (“TS012345”)

IsRelativeOf ( )

[0510] Checks if the passed in user is relative of the current user.

Syntax:

[0511]

	Public Function IsRelativeOf (sEmpId As String) As Boolean
	End Function

Parameters:

[0512]

	sEmpId: string containing Employee Number

Example:

[0513]

	Dim bIsRelativeOfMonika As Boolean
	bIsRelativeOf = objArch.UserMan.IsRelativeOf (“TS012345”)

IsInRole ( )

[0514] Checks to see if the current user is in a certain role.

Syntax:

[0515]

	Public Function IsInRole (sRole As String) As Boolean
	End Function

Parameters:

[0516]

	sRole: string containing role

Example:

[0517]

	Dim bIsInRoleTaskLibrarian As Boolean
	bIsInRoleTaskLibrarian = objArch.UserMan.IsInRole (“TA”)

[0518] The following APIs are located on the interface of the Arch Object 200 named SecurityMan 514.

• [0519] EvalClaimRules;
• [0520] EvalFileNoteRules;
• [0521] EvalFormsCorrRules;
• [0522] EvalOrgRules;
• [0523] EvalRunApplicationRules;
• [0524] EvalRunEventProcRules;
• [0525] EvalTaskTemplateRules;
• [0526] EvalUserProfilesRules;
• [0527] IsOperAuthorized;
• [0528] GetUserId; and
• [0529] OverrideUser.
  EvalclaimRules ( )

[0530] This API references business rules for claim security checking and returns a boolean if rules are met.

Syntax:

[0531]

Private Function EvalClaimRules (1BasicOp As cmBasicOperations,
vContextData As Variant) As Boolean
End Function

Parameters:

[0532]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)
vContextData: a variant array holding relevant business objects or other
information.

Example:

[0533]

Select Case lOperation
Case cmWorkOnClaim
	IsOperAuthorized = EvalClaimRules(cmView, vContextData)
	And —
	EvalClaimRules(cmEdit, vContextData)

EvalFileNoteRules ( )

[0534] This API references business rules for FileNote security checking and returns a boolean if rules are met.

Syntax:

[0535]

Private Function EvalFileNoteRules (1BasicOp As cmBasicOperations,
vContextData As Variant) As Boolean
End Function

Parameters:

[0536]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)
vContextData: a variant array holding relevant business objects or other
information.

Example:

[0537]

Select Case lOperation
Case cmDeleteFileNote
	IsOperAuthorized = EvalFileNoteRules(cmDelete,
	vContextData)

EvalFormsCorrRules ( )

[0538] This API references business rules for Forms and Corr security checking and returns a boolean if rules are met.

Syntax:

[0539]

Private Function EvalFormsCorrRules (1BasicOp As cmBasicOperations)
As Boolean
End Function

Parameters:

[0540]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)

Example:

[0541]

Select Case lOperation
Case cmMaintainFormsCorr
	IsOperAuthorized =	EvalFormsCorrRules(cmEdit) And —
		EvalFormsCorrRules(cmDelete) And —
		EvalFormsCorrRules(cmAdd)

EvalOrgRules ( )

[0542] This API references business rules for Event Processor security checking and returns a boolean if rules are met.

Syntax:

[0543]

Private Function EvalOrgRules (1BasicOp As cmBasicOperations) As
Boolean
End Function

Parameters:

[0544]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)

Example:

[0545]

Select Case lOperation
Case cmMaintainOrg
	IsOperAuthorized =	EvalOrgRules(cmAdd) And —
		EvalOrgRules(cmEdit) And —
		EvalOrgRules(cmDelete)

EvalRunApplicationRules ( )

[0546] This API references business rules for running the application and returns a boolean if rules are met.

Syntax:

[0547]

Private Function EvalRunApplicationRules (1BasicOp As
cmBasicOperations) As Boolean
End Function

Parameters:

[0548]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)

Example:

[0549]

Select Case lOperation
	Case cmRunApplication
	IsOperAuthorized = EvalRunApplicationRules(cmExecute)

EvalRunEventProcRules ( )

[0550] This API references business rules for Event Processor security checking and returns a boolean if rules are met.

Syntax:

[0551]

Private Function EvalRunEventProcRules (1BasicOp As
cmBasicOperations) As Boolean
End Function

Parameters:

[0552]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)

Example:

[0553]

Select Case lOperation
Case cmRunEventProcessor
	IsOperAuthorized = EvalRunEventProcRules(cmExecute)

EvalTaskTemplateRules ( )

[0554] This API references business rules for Task Template security checking and returns a boolean if rules are met.

Syntax:

[0555]

Private Function EvalTaskTemplateRules (1BasicOp As
cmBasicOperations) As Boolean
End Function

Parameters:

[0556]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)

Example:

[0557]

Select Case lOperation
Case cmMaintainTaskLibrary
	IsOperAuthorized =	EvalTaskTemplateRules(cmAdd) And —
		EvalTaskTemplateRules(cmEdit) And —
		EvalTaskTemplateRules(cmDelete)

EvalUserProfileRules ( )

[0558] This API references business rules for Task Template security checking and returns a boolean if rules are met.

Syntax:

[0559]

Private Function EvalUserProfileRules (1BasicOp As cmBasicOperations,
vContextData As Variant) As Boolean
End Function

Parameters:

[0560]

1BasicOp: a basic operation the current user is wishing to perform
(i.e. Delete)
vContextData: a variant array holding relevant business objects or other
information.

Example:

[0561]

Select Case lOperation
Case cmIsRelativeOf
	IsOperAuthorized =	EvalUserProfileRules(cmView, vContextData)
And _
	EvalUserProfileRules(cmAdd, vContextData)
And —
	EvalUserProfileRules(cmEdit, vContextData)
And —
	EvalUserProfileRules(cmDelete, vContextData)

GetUserId ( )

[0562] Returns the login name/user id of the current user.

Syntax:

[0563]

	Public Function Get UserId ( ) As String
	End Function

Example:

[0564]

	Dim sUserId as String
	sUserId = GetUserId

IsOperAuthorized ( )

[0565] This API references business rules and returns a boolean determining whether the user has security privileges to perform a certain operation.

Syntax:

[0566]

Public Function IsOperAuthorized (vMsg, as variant, nOperation as
cmOperations, vContext As Variant) A Boolean
End Function

Parameters:

[0567]

vMsg: the standard architecture message
nOperation: an enumeration containing name of operation to be checked.
vContext: a variant array holding relevant business objects or other
information.

Example:

[0568]

Dim nCanIDoThis As Boolean
bCanIDoThis = objArch.SecurityMan.IsOperAuthorized (vMsg,
aOperationName, vContext)
T1bEditIcon.Enabled = bCanIDoThis

OverrideUser ( )

[0569] Re-initializes for a different user.

Syntax:

[0570]

Public Sub OverrideUser (Optional sUserId As String, Optional dictRoles
As CDictionary, Optional dictSubs As CDictionary)
End Function

Parameters:

[0571]

sUserId:
dictRoles:
dictSubs:

Example:

[0572]

Dim s As New CTechArch
	x.SecurityMan.OverrideUser “Everyone”, New CDictionary,
	New Dictionary

[0573] Separate tables (CodesDecodes) are Created for storing the static values.

[0574] Only the references to codes/decodes are stored in business tables (e.g., Task) which utilize these values. This minimizes the size of the business tables, since storing a Code value takes much less storage space than its corresponding Decode value (e.g., For State, “AL” is stored in each table row instead of the string “Alabama”).

[0575] CodeDecodes are stored locally on the client workstation in a local DBMS. On Application startup, a procedure to ensure the local tables are in sync with the central DBMS is performed.

[0576] The present invention's Code Decode Infrastructure 600 Approach outlines the method of physically modeling codes tables. The model allows codes to be extended with no impact to the physical data model and/or application and architecture. FIG. 6 shows the physical layout of CodeDecode tables according to one embodiment of the present invention.

Infrastructure

[0577] The physical model of the CodeDecode infrastructure 600 does the following: Supports relational functionality between CodeDecode objects; Supports extensibility without modification to the DBMS or Application Architecture;

[0578] Provides a consistent approach for accessing all CodeDecode elements; and

[0579] Is easily maintainable.

[0580] These generic tables are able to handle new categories, and modification of relationships without a need to change the DBMS or CodeDecode Application Architecture.

[0581] Benefits of this model are extensibility and maintainability. This model allows for the modifications of code categories without any impact to the DBMS or the Application Architecture code. This model also requires fewer tables to maintain. In addition, only one method is necessary to access CodeDecodes.

Table Relationships and Field Descriptions:

• • [0582] (pk) indicates a Primary Key
    Code_Category 602
  • [0583] C_Category (pk): The category number for a group of codes
  • [0584] C_Cache (currently not utilized): Can indicate whether the category should be cached in memory on the client machine
  • [0585] T_Category: A text description of the category (e.g., Application Task Types, Claim Status, Days of Week)
  • [0586] D_Last_Update: The date any data within the given category was last updated; this field is used in determining whether to update a category or categories on the local data base

[0587] Relationships

• • [0588] A one-to-many relationship with the table Code (i.e., one category can have multiple codes)
    Code 604
  • [0589] C_Category (pk): The category number for a group of codes
  • [0590] C_Code (pk): A brief code identifier (up to ten characters; the current maximum length being used is five characters)
  • [0591] D_Effective: A date field indicating the code's effective date
  • [0592] D_Expiration: A date field indicating the code's expiration date (the default is Jan. 1, 2999)

[0593] Relationships

• • [0594] A many-to-one relationship with Code_Category 602 (described above)
  • [0595] A one-to-many relationship with Code_Relations 606 (a given category-and-code combination can be related to multiple other category-and-code combinations)
    Code_Relations 606
  • [0596] C_Category1 (pk): The first category
  • [0597] C_Code1 (pk): The first code
  • [0598] C_Category2 (pk): The related category
  • [0599] C_Code2 (pk): The related code

[0600] Relationships

• • [0601] A many-to-one relationship with the Code table (each category and code in the Code table can have multiple related category-code combinations)
    Code_Decode 608
  • [0602] C_Category (pk): The category number for a group of codes
  • [0603] C_Code (pk): A brief code identifier (up to ten characters; the current maximum length being used is five characters)
  • [0604] N_Lang_ID (pk): A value indicating the local language setting (as defined in a given machine's Regional Settings). For example, the value for English (United States) is stored as 0409. Use of this setting allows for the storage and selection of text code descriptions based on the language chosen
  • [0605] T_Short_Desc: An abbreviated textual description of C_Code
  • [0606] T_Long_Desc: A full-length textual description of C_Code—what the user will actually see (e.g., Close Supplement—Recovery, File Note, Workers Compensation)

Enabling Localization

[0607] Codes have support for multiple languages. The key to this feature is storing a language identifier along with each CodeDecode value. This Language field makes up a part of the compound key of the Code_Decode table. Each Code API lookup includes a system level call to retrieve the Language system variable. This value is used as part of the call to retrieve the values given the correct language.

Maintaining Language Localization Setting

[0608] A link to the Language system environment variable to the language keys is stored on each CodeDecode. This value is modified at any time by the user simply by editing the regional settings User Interface available in the Microsoft Windows Control Panel folder.

[0609] Handling Time Sensitive Codes becomes an issue when filling controls with a list of values. One objective is to only allow the user to view and select appropriate entries. The challenge lies in being able to expire Codes without adversely affecting the application. To achieve this, consideration is given to how each UI will decide which values are appropriate to show to the user given its current mode.

[0610] The three most common UI modes that affect time sensitive codes are Add Mode, View Mode, and Edit Mode.

Add Mode

[0611] In Add Mode, typically only valid codes are displayed to the user as selection options. Note that the constant, cmValidCodes, is the default and will still work the same even when this optional parameter is omitted.

• • [0612] Set colStates=objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates,
    • [0613] cmLongDecode, cmValidCodes)
      View Mode

[0614] In View Mode, the user is typically viewing results of historical data without direct ability to edit. Editing selected historical data launches another UI. Given this the controls are filled with valid and expired codes, or in other words, non-pending codes.

• • [0615] Set colStates=objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates,
    • [0616] cmLongDecode, cmNonPendingCodes)
      Edit Mode

[0617] In Edit Mode, changes are allowed to valid codes but also expired codes are displayed if already assigned to the entity.

• • [0618] Dim colAssignedCodes As New cCollection
  • [0619] colAssignedCodes.Add HistoricalAddress.State
  • [0620] Set colStates=objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates,
    • [0621] cmLongDecode, cmValidCodes, colAssignedCodes)

[0622] The Local CodeDecode tables are kept in sync with central storage of CodeDecodes. The architecture is responsible for making a check to see if there are any new or updated code decodes from the server on a regular basis. The architecture also, upon detection of new or modified CodeDecode categories, returns the associated data, and performs an update to the local database. FIG. 7 is a logic diagram for this process 700.

[0623] After an API call, a check is made to determine if the Arch is initialized 702. If it is a check is made to determine if the Freshness Interval has expired 704. If the Freshness Interval has not expired, the API call is complete 706. However, if either the Arch is not initialized or the Freshness Interval has expired, then the “LastUpdate” fields for each category are read from the CodeDecode and passed to the server 708. Then new and updated catagories are read from the database 710. Finally the Local database is updated 712.

[0624] The following are APIs located on the interface of the Arch Object 200 named CodesMan 500.

• [0625] GetCodeObject(nCategory, sCode);
• [0626] GetCategoryCodes(nCategory);
• [0627] FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]).
  GetCodeObject: Returns a valid CCode object given a specific category and code.
  Syntax:
  • [0628] GetCodeObject(nCategory, sCode)
    Parameters:
  • [0629] nCategory: The integer based constant which classified these CodeDecodes from others.
  • [0630] sCode: A string indicating the Code attribute of the CodeDecode object.
    Example:

[0631]

frmCurrentForm.1blState = objArch.CodesMan.GetCodeObject
(cmCatStates, “IL”).LongDecode

GetCategoryCodes: Returns a collection of CCode objects given a valid category
Syntax:

• • [0632] GetCategoryCodes(nCategory)
    Parameters:
  • [0633] nCategory: The integer based constant which classified these CodeDecodes from others.
    Example:

[0634]

Dim colMyStates As CCollection
Set colMyStates = objArch.CodesMan.GetCategory (cmCatStates)

FillControl: This API is used to fill listboxes or comboboxes with values from a list of CodeDecodes. Returns a collection for subsequent lookups to Code objects used to fill controls.
Syntax:

• • [0635] FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes])
    Parameters:
  • [0636] ctlControl: A reference to a passed in listbox or combobox.
  • [0637] nCategory: The integer based constant which classified these CodeDecodes from others.
  • [0638] nFillType: The attribute of the CodeDecode which you want to fill. Valid values include:

[0639]

	cmCode
	cmShortDecode
	cmLongDecode

• • [0640] nCodeStatus: Optional value which filters the Code Decodes according to their Effective and Expiration dates. Valid constants include the following:

[0641]

cmAllCodes	Pending + Valid + Expired Codes
cmPendingCodes	Codes whose effective date is greater than the
	current date
cmValidCodes	Not Pending or Expired Codes
cmExpiredCodes	Codes whose expired date is greater than the
	current date
cmNonPendingCodes	Valid + Expired Codes
cmNonValidCodes	Pending + Expired Codes
cmNonExpiredCodes	Pending + Valid Codes

• • [0642] colAssignedCodes: Used when filling a control which should fill and include assigned values.
    Example:
  • [0643] ‘Declare an instance variable for States collection on object

[0644]

	Private colStates As CColection

• • [0645] ‘Call FillControl API, and set local collection inst var to collection of codes which were used to fill the control. This collection will be used for subsequent lookups.

[0646]

Set colStates = objArch.CodesMan.FillControl
(frmCurrentForm.cboStates, cmCatStates, cmLongDecode)

• • [0647] ‘Below shows an example of looking up the Code value for the currently selected state.

[0648]

	With frmCurrentForm.cboStates
	If.ListIndex > −1 Then
	Dim objCode As CCode
	Set objCode = colStates(.ItemData(.ListIndex))
	sStateCode = objCode.Code
	End If
	End With