ao-iomzzon - theartofservicelab.s3.amazonaws.com Toolkits/The...Patent Application Publication Sep. 1, 2005 Sheet 3 0f 15 US 2005/0192925 A1 Fig. 3 n’n‘n Enterprlso lnformatian

l|||||||||||||ll||l||||||||l|||||||||||||||||||||l||||||l||||||||||||l|||||||||||||||||||| US 20050192925A1

(19) United States (12) Patent Application Publication (10) Pub. No.: US 2005/0192925 A1

Nichols (43) Pub. Date: Sep. 1, 2005

(54) ENTERPRISE INFORMATION SYSTEM Publication CIHSSi?CHtiOIl ARCHITECTURE (EISA)

(51) Int. c1.7 ..................................................... .. G06F 7/00

(76) Inventor: Terry Lee Nichols, Palm Coast, FL (52) US. Cl. ............................................................. .. 707/1

(Us) (57) ABSTRACT

Correspondence Address: A method and system for Enterprise Information System

Terr Lee Nichols . . . . . .

y Architecture provides a standardized enterprise information 38 Seascape Drive Palm Coast’ FL 32137 (Us) architecture With the ability to share data, provide a consis

tent user access method, connect application logic to data, (21) APPL NO; 11/037,854 provide a uniform method to connect interfaces With appli

cations, interact With Work?oW, interact With external sys (22) Filed; Jam 18, 2005 tems, provide a uni?ed navigation architecture schema,

provide a standard security schema, provide an integrated documentation methodology, and provide pathways for

Related US, Application Data time-based processes for data, programs, Work?oW and documentation. This architecture provides a single overarch

(60) Provisional application No. 60/537,366, ?led on Jan. ing system With system development and diverse enterprise 16, 2004. information system integration capabilities.

Architecture Addressability

6.. J/ Phie 6,6- / / System Organization Ila Vendor de manoiher "' instal ' as

5.1 / w ‘ Plape’so _- Man/‘4am / a Navigation mime: Pl’Ogram / 4_1 41 /Map 11¢?Zé‘y?em / 4.5 / 4.6 Data / I‘ / / Plane 3 - / as / n Documentation ’ "av of Fl“- hl 5mm - -

Authorization / z‘ / 22 all 01 Sandi:me ofnation SM 25 / 2s

.LHv u - L5 / 1.6 enCube'" RMS \ \\\\\\ \\ \\\\\\ Plane1-0 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 enCube Systems)

Systems developed

within 1.1.6.1 1.1.6.2 enCube'"

1.1.6.4 1.1.6.5 1.1.5.6

1.1.6.3.1 1.1.6.32 1.1 15.3.3 1.1.6.3.4 1.1.6.3.6

1.1.63.5.1 11.6.3.5.3 11.6.3.5.4 1.1.63.5.5 1.1.6.355

1.1.6.3.5.Z.1 1.1.63.5.22 1.1.5.3513 1.1.6.3525 1.1.5.1525

Patent Application Publication Sep. 1, 2005 Sheet 1 0f 15 US 2005/0192925 A1

Fig. 1

Architecture Addressability

6' 59/ 591/ W as System Organization Vendor msdpl 50manomerenc "'lnstal > / s1 / siwlier a 4 _' Man emem / 5*‘

Navigation Me _

Program / u 11 /M.pd9#g,s,em / 4.5 / 4.6 Data / 3‘ / / Pl_ane3_ - / 3's / 3.8 Documentation “WM “5mm

Authorization / z, / u )w/fswsjim?mfimg n/ as / 2s _.___ z 12 L5 /,'5 enCube‘" RMS

/ Plane“! 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 enCube .

Systems) ' " f '

1.1.5.4 1.1.6.5 1.1.6.6 /

\\ \\\\ Systems developed

Within 1.1.6.1 1.1.6.2 encube'" \ \ \\\\\\

1.1.5.3.1 1.1.6.32 1.1.6.13 1.1.6.3.4 1.1.6.3.6

11.6.3.5.1 1.1.6.153 1.1.6.354 1.1.6.3.55 1.1.6.355

1.1.6.3521 1.1.6.3522 1.1.6.3523 ‘ i 1.1.6.1525 1.1.6.1525 /

Patent Application Publication Sep. 1, 2005

Fig. 2

External lnteg ratlo n Arch itectu re

ao-iomzzon

Sheet 2 0f 15 US 2005/0192925 A1


Fig. 3

n’n‘n Enterprlso lnformatian System Architecture - External

Desktop M Item Task Invocation Scheduled Task mm

Manual lnvom?on Third Party Tusk lnvowtion

Th'l'd Party App Intarnal App

‘l'hid Party Task Internal Task

ANY CODE 3rd Party. Internal, External Advanced Prog'am Logic Wrapped In rl'n'n’ EIA

Trid Party App "normal App

Thid Party Task lmernal Task

a, '_ tables to “ access

Back End Dali


Fig. 4

Nodes

Any NODE can be: ,_ Navigation Presentation - WA ____.> Task Work?ow Data

L

| UNLIMITED ]


Fig. 5

WORK AREA Hierarchical Folders

University of the Southeast

Compton Campus

Academics

Of?ces and Services

Publicity/Community Relations

—~—-——O Development

Business Of?ce.

Purchasing

—O Materials


Fig. 6

WORK AREA ORGANIZATION

Client v ‘ °s°°

_ | —|

Co u "try USA ‘ umda USA Ma

I —l J I State MD FL om’ SAS on on up AP

[_—_—___l

MD FL DC OH _ ONT SAS UP 5A5


Fig. 7

Tasklnvocation

User Interface


. __ _ _.__ _ _ ‘ J13. ‘

BBIII: Prupertlal EFfewVQ Date I I l n

h l ‘M I '3 sllwbox Nam Pymisi?almw

_ I18 1

Twin l?qlg_____________________’: .7 _ - Styli: C1555 -

0mm." Drivan ‘Balm _ __ _,..~ . V . .. . _ ‘

Adminiswatinn lSalery Plan - General USA >~| ‘ "'ms PIQI'A 'ww‘wm“ ‘

Empty Chad: I:

CVntena Event n-ndllnq

Event Typa lugjvum] ___ 'I hung Saala I Script Code

DB Elemant

Column Name

Data Tyne

Lenq?'l

Mow Nulls

Solomon Optlnn;

09mins Eastarn US Sales Western US Service P :asantcxn Davalopment Balth Care-Operations ?s?galii?gga


Fig. 9

Human Capital Management Financial Management

Productivity ‘Global Settings Security Maintenance


Fig. 10

Client Side Components Server Side Components

Apache Tomcat Servlet Container

= Custom Web Browser Pages

* UDDI

Registry ' Registry Broiiiiserv =

F s

V‘ V ____ Deployed

' Web

Services

Web Services Architecture


Fig. 11

“E vEnharprisu Design Administration Human Capital Managemant Financial Management vHuman Resource Portal

(y Global Snllings Security Maintenance

DNA Pad!

“milder

' Tm lh?der ‘

' Sadly-d In?u- a woject_name \

_ \_‘; pmjact_dgs: I Table tanhcl (?nlltt_nlm2 1

1 Wm connc(_ph\mn_ k; Tr :I _ M _

I

I ER”.

0 eramr ' Where " Condition \ Valua ' ‘Ad move ‘ ' Selected conditions- i ' i I" P y Y

AND v rn’ect id > 1 100g projecgnam: f ! I J In 1 “ I J I " @ prnject_desc I

l @ cnntlctJuame ‘ ‘k 2 contact Bhnne ' - I ~» I s

i

' v m ’ = , _| ‘ canyon/J's: (lli'th?b250) .

= display_$'(au|s (tinyinn l) @ cauguLst/mus (linyirml) ‘ i f wagon/Jame (varchanSlJ) _ _ I] H V 7, V V ,

, E a v wppeiatmi" when!v Cundrtion 3' A "value Add/‘Ramon ' I‘ I ‘Se!elntedjpgirmii‘lions\v ‘ ,

‘ Mg 7 ate 0 m; = - 1 u\:oqory_namu(varchar.50] '

i I q ry- [ ' "w @ nugorLdu: (ulrchmZSO) i E category_stitus (u'nyintl) B

Expoit w j I,

T] Database table


Fig. 12

Time-based Task Processing

FUTURE


Fig. 13

Position No V _ Effective Date [Elia-‘finn

Status ‘

,s H V. V ,>._ . 7 ‘it .._ “we. a. .s. an

Position Long Name [System Adminstrator

Position Short Name [System Administrator Position Group v 7 7

Primary Purpose Performs activities which directly support h, the operations at integrity of computing _ “ systems.

Essential Tasks Adding or Removing Hardware 3&1

Performing Backups Installing New Hardware -_

installing New Software _ ,

Monitoring the System ?l


Fig. 15

Status [Active .'|

Date 8: Time Restrictions

0a? of Start Time End Time Start Time End Time Start Time End Time Week Rangel Rangel RangeZ RangeZ Range3 Range3

1i 000100510011 190;1100_+1 100310051 190310021 10°:J109i] [0031903

0' 00110091103 190310011 100010091 1009110011 100910011 100110021

17 Tue 10031-0051 1001.1100il 100£|100£1 109:110031 100:1100i1 10.9_'J100A

1' 01801901110011 1.00.0110031 1002110011 10931003 10031003 100:.110011

11'- Thu 1001110011 109111903 1905110011 100310011 100111003 1002110011

11' Fri 1002110021 1002119011 1.00;1100;1 1003110011 10031003 100310031

I’ sat 100310011 109310021 190;1100;1 1.0031003 1.0031001 100.111.0011


Fig. 16

‘t. _ Login - Laygr Screen “

User ID I Effective Date |_— f|— f]

Account

0 Expires On Fir/TEE] At m

USuspend 0n Fir/FEE] At @ [I Resume On At

Login

US 2005/0192925 A1

ENTERPRISE INFORMATION SYSTEM ARCHITECTURE (EISA)

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority of Nichols’s US. Provisional 168765 Application Ser. No. 60/537,366 ?led on Jan. 16, 2004, entitled “_Enterprise Information System Architecture (EISA)_,” the contents of Which are incorpo rated herein by reference in their entirety including the contents and teachings of any references contained therein.

TECHNICAL FIELD

[0002] The invention relates generally to “Enterprise Soft Ware Systems” and, more particularly, to “In?nitely Con ?gurable Enterprise Information Architecture”, “Enterprise

1, “ Operating System”, “Security , Data Integration”.

BACKGROUND OF THE INVENTION

[0003] Today’s enterprise softWare World does not have an architecture that governs the manner in Which enterprise softWare systems are created. This lack of standards creates an environment full of applications that cannot share data, cannot provide a consistent user access method, cannot uniformly connect application logic to data, cannot provide a uniform method to connect interfaces With applications, cannot interact With Work?oW, cannot interact With external systems, cannot provide a uni?ed navigation architecture schema, does not provide a standard security schema, cannot provide an integrated documentation methodology, and can not provide pathWays for time-based processes for data, programs, Work?oW and documentation. The resulting islands of functionality, yields a patchWork enterprise infor mation technology landscape Where all system components from one system can not be reached or synchroniZed With components from another, including legacy systems and backend systems of record. In short, today’s enterprise is burdened With a jumble of standards, platforms, systems and applications that have no Way in Which to provide uni?ed information access and control. Our invention, Enterprise Information System Architecture, as this patent application shoWs, solves uniquely this problem.

SUMMARY OF THE INVENTION

[0004] In accordance With the foregoing architecture for developing enterprise systems, the invention provides a standardiZed enterprise information architecture With the ability to share data, provide a consistent user access method, connect application logic to data, provide a uniform method to connect interfaces With applications, interact With Work?oW, interact With external systems, provide a uni?ed navigation architecture schema, provide a standard security schema, provide an integrated documentation methodology, and provide pathWays for time-based processes for data, programs, Work?oW and documentation. This architecture provides a single overarching system With system develop ment and diverse enterprise information system integration capabilities. [0005] In particular, our invention, Enterprise Information System Architecture, as this patent application shoWs, uniquely solves the problems summariZed in the above section entitled BACKGROUND of the INVENTION. Our

Sep. 1, 2005

invention uniquely brings order to the situation described above via its overarching Enterprise Information System Architecture, Wherein each of the underlying systems sum mariZed above becomes a fully integrated contributing and controllable entity presented to the Enterprise via our overall Enterprise front end.

[0006] Additional features and advantages of the inven tion Will be made apparent from the folloWing detailed description of illustrative embodiments that proceeds With reference to the accompanying ?gures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] While the appended claims set forth the features of the present invention With particularity, the invention, together With its objects and advantages, may be best understood from the folloWing detailed description taken in conjunction With the accompanying draWings of Which:

[0008] FIG. 1 is System Addressability . . .

[0009] FIG. 2 is External Integration Architecture

[0010] FIG. 3 is Enterprise Information External archi tecture

[0011] FIG. 4 is Menu Nodes

[0012] FIG. 5 is Work How Folder Examples

[0013] FIG. 6 is Work How Structure Flexibility

[0014] FIG. 7 is Process Invocation

[0015] FIG. 8 is Task Builder Screen Shot Examples

[0016] FIG. 9 is Work?oW Model

[0017] FIG. 10 is Web Services Architecture

[0018] FIG. 11 is Data Communication Menu

[0019] FIG. 12 is Time Based Task Processing

[0020] FIG. 13 is Position Basic Data Menu

[0021] FIG. 14 is Security Schema

[0022] FIG. 15 is Date-Layer Screen

[0023] FIG. 16 is Security Login Screen

DETAILED DESCRIPTION OF THE DRAWINGS

[0024] OvervieW

[0025] Our overarching Enterprise Information Systems Architecture (EISA) connects all of an enterprise’s various systems into a cohesive Whole Within a single enterprise architecture. The architecture provides important capabili ties including an n*n*n component-based architecture, an open enterprise integration infrastructure Which includes open collaboration With all external system components, process integration With comprehensive exchange infra structure, infrastructure management, compliance With open internet and industry standards, time-based task processing and model-based cascading security.

[0026] Design Philosophy [0027] Throughout EISA, a unique design philosophy permeates all aspects of the system. This philosophy is based on nodes that represent the logical unit of Work and its place in the overall enterprise structure.

US 2005/0192925 A1

[0028] True to its modular design, the architecture makes it possible to re?ect complex processes Which connect to Work?oW based one table/one task methodology. This design provides a place for everything related to enterprise softWare. The architecture uses a hierarchy of small reusable modules that are grouped to represent system entities.

[0029] EISA enables all data stores and the procedures that affect them to be put together in a one-to-one fashion. One table and one procedure becomes the norm. EISA moves complex relationships among related tables and procedures out from the tables and procedures themselves and into EISA’s Advanced Connector Logic technology space, leav ing the code directly related to the maintenance of individual tables unadulterated by foreign and dependency-creating relationship & Work?oW code. By factoring Work How & relationship code out aWay from the tables and the proce dures that maintain them, one change to a complex relation ship does not break all participants in that relationship.

[0030] System Design OvervieW

[0031] is a standards-based approach to solving complex system design and application integration challenges. The architecture is based on a hierarchical node-based model Which provides the system designer With the frameWork and instruments to produce and host systems, applications, menus and individual end user Work areas Where select Work tasks are determined, and subsequently performed.

[0032] Architecture Addressability

[0033] The architecture utiliZes a hierarchical numbering schema to identify each system component. For example, the address for the ?rst node is 1.0. The third child of the ?rst node Will have an address of 1.3. The 5th child of the third node Will have an address of 1.3.5, and so on. There are an in?nite number of nodes at any level.

[0034] The n*n*n architecture is a hierarchical structure comprised of system nodes may represent navigation, func tional Work areas, tasks, sub tasks and Work?oW. The purpose of the structure is to ensure a logical series of related steps and processes that produce the desired results. As navigations, Work areas, and tasks are created, the objects that result from the design are de?ned to the architecture and a road map of the creation process established. This is accomplished using an allocation table that contains a blue print of the creation process from the parent node, through the loWest child node Which comprises actual data elements de?ned to a particular task. See FIG. 1.

[0035] External System Architecture Addressability

[0036] The architecture also utiliZes a hierarchical num bering schema to identify each external system component. External system addressability uses the same numbering schema found in the core architecture numbering schema

[0037] 1. Connectors are used to integrate any exter nal system component—menus, functional areas, tasks, sub-tasks and Work?oW—With the core archi tecture. The logical construct provides an extended architectural layer designed for interaction, integra tion, and evolution of components. See FIG. 2.

[0038] External System Integration

[0039] EISA’s in?nitely con?gurable node architecture is designed to facilitate integration, interfacing or evolving any

Sep. 1, 2005

functional component from any external application. For example, an external application may have several menu items that it Would be nice to be able to activate from Within EISA’s menu structure directly. Instead of having to open SAP and select these menu items, it makes more sense to group them With other EISA Work-area tasks to achieve better integration and functional grouping.

[0040] To bring this integration With EISA even further along, EISA can trigger background tasks to folloW the execution of one of these third Party application tasks that has been initiated from an EISA Work Area. An example of a background task folloWing a 3rd Party application’s task might be to synchroniZe data altered by the third Party task With data in an EISA table for instance.

[0041] Each background task can be built With EISA’s Background Builder and assigned to folloW a particular third Party EISA activated Task via assignment in DNA Builder. This assignment maps to potentially every third Party task, an EISA Background task, Which in turn can be the start point for an EISA Work?oW or Communicator Process or

any combination thereof. The poWer and ?exibility is simply limitless, While alWays operating under the protection of the EISA Security and Enterprise Application Infrastructure Control.

[0042] See FIG. 3.

[0043] Menu Nodes

[0044] Menus, When placed at any node preceding a task, are designed to provide systematic pathWays to Work areas. See FIG. 4.

[0045] Work Area Nodes

[0046] Work area nodes may employ a variety of structure types including:

[0047] DNA

[0048] Tree Structure

[0049] Linear Folders

[0050] Hierarchical Folders

[0051] Graphical Desktops

[0052] Image Map

[0053] The purpose of a Work area for launching tasks, sub-tasks and Work?oWs. Examples are seen in FIG. 5.

[0054] Work Area Organizational Structure Flexibility

[0055] The architecture provides the ability to design organiZational structures on demand.

[0056] The folloWing attached image is and discussion addresses the native ability to perform Enterprise Design Organizational Structure manipulations.

[0057] The discussion speci?cally concerns the sWapping of levels in an enterprise design diagram. Further, the impact of such a sWap and What exactly a sWap means from a tables and records perspective Within the architecture is discussed.

US 2005/0192925 A1

[0058] Notice in the image that We have three levels and their respective ordering before We swap:

[0059] 1. Client and its Client table

[0060] 2. Country and its Country table

[0061] 3. State/Region and its Region table

[0062] See FIG. 6.

[0063] In FIG. 6 We desire to sWap levels 1 and 2 and examine the impact, shoW hoW the trees Would have to look, and What Would happen to each of the tables and their records.

[0064] After sWapping levels one and tWo, We have:

[0065] 1. Country and its Country table

[0066] 2. Client and its Client table

[0067] 3. State/Region and its Region table

[0068] Let us look at the situation before We sWap levels:

[0069] The Client table has 2 records in it, one for IBM and one for CSCO

[0070] The Country table has four records in it, USA tWice and Canada and India once each and this is so because USA occurs under both clients IBM and CSCO Whereas Canada occurs under only IBM and India occurs only under CSCO.

[0071] The State/Region table has eight records in it, for each region, i.e. MD, FL, under the USA; ONT, SAS, under Canada, and UP and AP under India.

[0072] NoW let us look at the situation AFTER levels one and tWo, i.e. Client and Country, are sWapped to be Country and Client.

[0073] After the level sWap, this is What We have:

[0074] The Country table goes from having four records in it, to only three countries in it, ie 1 record for USA, 1 record for Canada, and one record for India.

[0075] The Client table goes from having only 2 records in it, to having 4 records in it, With IBM occurring tWice, once under USA and once under Canada, Whereas before the sWap, IBM only occurred once in the Company table.

[0076] Finally, the State/Region table does not change in terms of number of records.

[0077] Of course, the table, Which records the parent child relationships, Will also have to change Whenever level changes occur as Well.

[0078] The architecture supports level changes Without manual intervention.

[0079] Task Nodes

[0080] This is the ?nal menu level node created Within the architecture, and like the other levels, the parent-child relationships are established at superior nodes. At this level, the end user or process scheduler Will select the actual tasks that are available to support the logical unit of Work.

[0081] A System is composed of one or more related Applications, Which in turn is composed of one or more related Work Areas, Which in turn is composed of one or more related Tasks and their tables.

Sep. 1, 2005

[0082] All menus leading up to the tasks themselves are purely navigational. Until a task is invoked, processing consists of rendering the next level of menus based on the previous level and the sub menu chosen, the identity and security pro?le of the user and the deployment descriptors for that node.

[0083] Once a Task Within a particular Work Area has been selected, a logical unit of Work is performed on a table Which can in turn trigger an interactive event, or a scheduled event. In either case, the details of execution take place Within a background process/daemon technology to marshal all Work ?oWs from a scheduling and fault tolerance perspective.

[0084] Tasks are comprised of the folloWing components: Internal Application Source Invocation (Menu, Scheduled, or Work?oW invoked), External Application Source Invoca tion (Menu, Scheduled, or Work?oW driven), and Data Connections.

[0085] See FIG. 7

[0086] System Immunity [0087] The goal is to have all aspects of the system con?gurable via our Web interface; all design articulation being done though a menu, all coding performed Within EISA. For example Where a custom piece of logic needs expression With our EISA Connector Logic Language, there Will be only one relevant place to do that, i.e. via a WindoW peering into that part of the system Where such expression is required. [0088] System Omniscience

[0089] Everything relevant to the architecture from a systems integrity perspective Will be knoWn to the architec ture. Everything Will be contextual: Designers only see the options determined to be relevant to the system. These options are available for con?guration based on its system context. The con?guration choices—the ?elds of data in that part of the system being conFig.d—Will be the only valid choices for the system designer to select.

[0090] The architecture supports an IMMUNE System by design. This is the IMMUNITY daemon that alWays checks system integrity is alWays aWare of every aspect of itself. This is based on inter-relationships expressed With architec ture’s Connector Logic Language and Entity Relationship Builder [discussed beloW].

[0091] For the EISA, Connector Logic Language to con nect deterministically, all GUI instruments (radio button groups, checklist groups, lookup Widgets, data driven multi select pick lists, query and substitute instruments, etc) Will be componentiZed. This is accomplished via robust de?ni tion of each component’s interface that anticipates all pos sible relevant uses of the component. These components, fully de?ned and the functions to associate them With one another Will form the basis of the EISA BiZLogic API.

[0092] The EISA Connector Logic Language calls on these components and dictates the syntax of expressions that deal With them. This includes the operators, the order of operations, the “sentence structure” and punctuation. The EISA BiZLogic API’s objects and methods are the nouns and verbs. Silicon Beach Systems uses this as an interpreted macro language at compile time, informing EISA hoW to compile and/or deploy itself, ie its various components

US 2005/0192925 A1

based on the SBS Designers intent as expressed via the EISA Design Interface. This is codeless Intentional Programming, With an autonomous nervous system and immune system operating in the background at all times. This keeps the virtual representation of the enterprise self-referentially intact.

[0093] The source code for all programming consists of diagrams. From these business analyst created diagrams the designer’s intent is articulated into an instance of EISA, across all aspects of the enterprise virtual desktop. Changes in the diagrams are used to re?ect the designer’s intentions and result in a neW instance of EISA. Graphical Semantic Models produce all the source code in EISA. Apicture truly is Worth a thousand Words, or in EISA’s case at least a thousand lines of code.

[0094] [0095] Task Builder alloWs you to specify the data ?elds and their types that are in the table, as Well the non-data element components such as vieWs etc. associated With the task. Task Builder is the tool for screen layer design. Designers select instruments from the Tool Bar and they appear on the canvas. Every instrument’s attributes can be speci?ed and altered via the properties panel Which appears to the right of the canvas.

[0096] See FIG. 8.

[0097] When placing more compleX instruments such as Lookups, Which populate VieWs Whose records come from a different table, Which may not have been de?ned, the instrument may still be placed. Speci?cs may be later de?ned during another session With Task Builder once the dependent table has been de?ned. In other Words, Task Builder is ?eXible enough to alloW design even if all dependent aspects have yet to be de?ned.

Interface Design

[0098] As a part of this screen building process three control tables are populated.

[0099] Master Screen Descriptor Control Table

[0100] Each record in the Master Screen Descriptor Con trol Table pertains to a screen as Well as a screen component/ instrument specifying it uniquely as Well as describing its spatial orientation/position, & instrument type. Instrument Types include (but are not limited to):

[0101] Label & TeXt BOX With or Without link to data element

[0102] Label & TeXt BOX W/Look-up Pop-up VieW W/replace [PassWord & suppress label options on each]

[0103] Label

[0104] Hidden Field

[0105] Multi-line TeXt BOX

[0106] Select List

[0107] Radio Group

[0108] Check BOX Group

[0109] Email Link

[0110] Hyper Link

[0111] Lookup W/on Screen VieW

Sep. 1, 2005

[0112] Submit

[0113] Clear Form

[0114] Image [0115] File Upload

[0116] Select BOX

[0117] Composite Instruments

[0118] Composite Instruments are made up of other instru ments, e.g. Date Selector Instrument is composed of several pick lists, but together comprises one instrument.

[0119] An Instrument Table, de?ning each type of instru ment available in the Task Builder Instrument Panel, can groW as neW instruments are de?ned.

[0120] Due to the numerous types of components/instru ments necessary to fully eXpress a Task’s GUI, helper tables are necessary to support the Master Screen Descriptor Table in areas such as:

[0121] Instrument connectivity—to tables and the criteria for determining result sets in vieWs etc.

[0122] Instrument validation—for eXample, a teXt boX can only have certain acceptable values Which might correspond to a ?eld in a table. Another teXt boX may not correspond With a table ?eld, but still may need to be validated to control its range of in?uence on the form. Therefore, validation needs to be separated from the loWer data element level and attached to the more generic screen descriptor level. Instrument validation is another Instrument Param eter deserving its oWn sub-table linked to the Master Screen Descriptor Control Table.

[0123] Helper tables Will be linked back to the Master Screen Descriptor Control Table instrument/data element record via the positional notation of the element.

[0124] Parameters regarding instruments such as, in the case of a lookup instrument the table or tables referenced in the lookup plus the search criteria variables/formula used When selecting the result set, need to be stored in another Screen Descriptor Helper table called the Instrument Param eters Table [WPT]. Each record in the WPT refers to a speci?c Instrument on a speci?c Task’s Screen Which is a speci?c record in the Screen Descriptor Control table. The Screen Rendering Engine reads Screen Descriptor Control table & its helper tables to paint screens.

[0125] 1/0 Design [0126] For a given task, the records in the Master Screen Descriptor Control Table Will often be a superset of the records for the same task in the Data Dictionary Control table. This is because items appearing on a task’s screen Will include more than just data elements.

[0127] Therefore, the notation to refer to ?elds in a table is simply an extension of the architecture’s signature for that task, Whereas the notation to uniquely identify a screen element generically cannot be the same notation as its members are a superset to the set of data elements alone.

[0128] Data Dictionary Control Table

[0129] Each record in the Data Dictionary Control Table corresponds With one data element in a task’s primary table.

Documents

ao-iomzzon - theartofservicelab.s3.amazonaws.com Toolkits/The...Patent Application Publication Sep. 1, 2005 Sheet 3 0f 15 US 2005/0192925 A1 Fig. 3 n’n‘n Enterprlso lnformatian