Dynamic value sets in a service-oriented business framework

A method includes receiving a representation of a service, the service including handling of a request for a context-dependent data set derived from one or more collections of data elements. The representation includes a specification of a first data field, a specification of an input data structure including two or more data fields and the first data field, the two or more data fields defining a context for the first data set, a specification of an output data structure, instances of the output data structure including the context-dependent data set, and a name of a service provider. The method stores the representation of the service in a repository, receives a request for the service by a software entity, the request including an instance of the input data structure, checks the request against the representation of the service, sends the request to the service provider, receives one or more instances of the output data structure from the service provider, and sends the one or more instances of the output data structure to the software entity.

TECHNICAL FIELD

The present invention relates to data processing by digital computer, and more particularly to dynamic value sets in a service-oriented business framework.

BACKGROUND

Large-scale business software applications are sometimes categorized in terms of a “front end component” that includes a graphical user interface (GUI) to present data to users and accept data entry from users. Such front-end components are customized for specific customers. Another component of such software applications is sometimes referred to as a “back end component” that stores business data and processes the business data according to business logic. The back end component retrieves, generates, and maintains the business data. The back end component is usually responsible for the consistency and correctness of the data. The back end component also can store relationships between the various data. In a typical business software application, the front-end component includes application code to display, aggregate, and enable modification of data of the back end.

For large-scale business applications, it is sometimes difficult to coordinate software development of the front end and back end components. Meta data, in a repository, has been used to model standard operations on data collections in the back end. This meta data can be used to develop front-end components.

The front-end application code can provide help to users for generating requests to the back end for data retrieval operations. One essential feature for a user interface is adequate help values for entry fields. This help may include pull down windows with choices for a user to select from. In many state-of-the-art applications these help values are presented as list boxes or combo boxes with values retrieved from a static list. Thus, the help values are fixed for the lifetime of the application.

SUMMARY

In one aspect, the invention features a method including receiving a representation of a service, the service including handling of a request for a context-dependent data set derived from one or more collections of data elements. The representation includes a specification of a first data field, a specification of an input data structure including two or more data fields and the first data field, the two or more data fields defining a context for the first data set, a specification of an output data structure, instances of the output data structure including the context-dependent data set, and a name of a service provider. The method stores the representation of the service in a repository, receives a request for the service by a software entity, the request including an instance of the input data structure, checks the request against the representation of the service, sends the request to the service provider, receives one or more instances of the output data structure from the service provider, and sends the one or more instances of the output data structure to the software entity.

In embodiments, the service provider determines the context-dependent data set by matching the data elements of the one or more collections against the instance of the input data structure of the request. The matching can include matching one or more fields of the data elements of the one or more collections against one or more fields of the instance of the input data structure of the request. The one or more fields of the instance of the input data structure can be unspecified, and further wherein the data elements of the one or more collections can be not matched against the unspecified one or more fields of the instance. The software entity can control a graphical user interface and the context-dependent data set can be a set of help values for a user. The graphical user interface can enable the user to select a value from the help values. The one or more collections of data elements can data elements stored in a database.

The method can include receiving a request for modifications to a collection from the one or more collections of data elements, sending the request to a service provider, the service provider configured to store the modifications in a transaction buffer and subsequently update the database with the modifications. A collection from the one or more collections of data elements can include modifications to the data elements in the transaction buffer. The output data structure can include a data structure of the context-dependent data set and a text description of each data element in the context-dependent data set. The data elements can be text strings, and further wherein the instance of the input data structure in the request can include a beginning of a text string and a wildcard symbol. The service provider can detect the wildcard symbol and can determine the one or more instances of the output data structure by matching beginnings of the data elements in the one or more collections against the beginning of the text string of the instance of the input data structure.

In another aspect, the invention features a system including a first computer configured to execute a client program, a second computer configured to execute a server program, a network linking the first and second computers such that the server program can be configured to execute the following: receive a representation of a service, the service including handling of a request for a context-dependent data set derived from one or more collections of data elements, the representation including a specification of a first data field, a specification of an input data structure including two or more data fields and the first data field, the two or more data fields defining a context for the first data set, a specification of an output data structure, instances of the output data structure including the context-dependent data set, and a name of a service provider, store the representation of the service in a repository, receive a request for the service by a software entity, the request including an instance of the input data structure, check the request against the representation of the service, send the request to the service provider, receive one or more instances of the output data structure from the service provider, and send the one or more instances of the output data structure to the software entity.

In embodiments, the service provider determines the context-dependent data set by matching the data elements of the one or more collections against the instance of the input data structure of the request. The matching can include matching one or more fields of the data elements of the one or more collections against one or more fields of the instance of the input data structure of the request. The one or more fields of the instance of the input data structure can be unspecified, and further wherein the data elements of the one or more collections can be not matched against the unspecified one or more fields of the instance. The software entity can control a graphical user interface and the context-dependent data set can be a set of help values for a user. The graphical user interface can enable the user to select a value from the help values. The one or more collections of data elements can data elements stored in a database.

The system can include receiving a request for modifications to a collection from the one or more collections of data elements, sending the request to a service provider, the service provider configured to store the modifications in a transaction buffer and subsequently update the database with the modifications. A collection from the one or more collections of data elements can include modifications to the data elements in the transaction buffer. The output data structure can include a data structure of the context-dependent data set and a text description of each data element in the context-dependent data set. The data elements can be text strings, and further wherein the instance of the input data structure in the request can include a beginning of a text string and a wildcard symbol. The service provider can detect the wildcard symbol and can determine the one or more instances of the output data structure by matching beginnings of the data elements in the one or more collections against the beginning of the text string of the instance of the input data structure.

These and other embodiments may have one or more of the following advantages. The value set requests return data that is dependent on a context so the data is dynamic rather than a static list. The representation (also known as meta data) of the value set requests enables easier development of front-end component software. The value set requests can include a context and data returned is dependent on the context. The value set requests also can request reads of data in intermediate buffers before the data is stored in backend databases. The value set requests can include a wildcard.

DETAILED DESCRIPTION

FIG. 1illustrates an overview logical representation of a business software architecture2, which includes a client3, a separation layer5, a repository7and backend data9and9′. Client3provides a user interface (UI) that enables a user to interact with the backend data9and/or9′. Backend data9and9′ can be associated with different backend applications and/or can be arranged and formatted differently from each other. Separation layer5separates the front end user interface provided by client3from the back end data9and9′. This separation enables client3to interact with backend data9and9′ in a consistent and similar manner, regardless of the formatting or application-associated differences between backend data9and9′. In other words, separation layer5provides a canonical interface to backend data9and9′ so that client3is configured to interact with separation layer5and only needs to be updated if separation layer5changes. Changes to backend data9and9′ do not necessitate an update to client3. Further, separation layer5is scalable and configured to handle changes and growth to backend data9and9′ and any other disparate backend data and backend services that are further connected to separation layer5.

As described in more detail below, separation layer5is based on a meta model that defines how backend data (e.g.,9and9′) are represented in separation layer5. Meta data is stored in repository7that describes how the backend data9and9′ fit into the meta model representation. Client3interacts with backend data9and9′ using a generic command set defined by separation layer5. As described in more detail below, separation layer5accesses service providers that perform the generic commands from client3, using the meta data in repository7, to effect the requested manipulation of backend data9and9′. The service providers are configurable so that different service providers can be used for different backend data9and9′. Separation layer5includes an interface (e.g., a service manager) that hides the characteristics of the corresponding backend data9and9′ and also the granularity and distribution of the implementation (i.e., the service providers).

One example of the architecture2is described by U.S. application Ser. No. 10/747,018 for SERVICE MANAGEMENT OF A SERVICE-ORIENTED BUSINESS FRAMEWORK, filed Dec. 23, 2003, the disclosure of which is incorporated by reference in its entirety. This example, denoted as the Enterprise Service Framework (ESF) Service layer, is an interface and modeling facility for supporting different scenarios described above.

FIG. 2illustrates this example of the business software architecture2. As shown inFIG. 2, the business software architecture2includes a first computer4and a second computer6. The computers4and6each can include a processor, a random access memory (RAM), a program memory (for example, a writable read-only memory (ROM) such as a flash ROM), a hard drive controller, a video controller, and an input/output (I/O) controller coupled by a processor (CPU) bus. The computers4and6can be preprogrammed, in ROM, for example, or the computers4,6can be programmed (and reprogrammed) by loading a program from another source (for example, from a floppy disk, a CD-ROM, or another computer) into a RAM for execution by the processor. The hard drive controller is coupled to a hard disk suitable for storing executable computer programs, including programs embodying the present invention, and data. The I/O controller is coupled by an I/O bus to an I/O interface. The I/O interface receives and transmits data in analog or digital form over communication links, e.g., a serial link, local area network, wireless link, or parallel link. Also coupled to the I/O bus are a display and a keyboard. Alternatively, separate connections (separate buses) can be used for the I/O interface, display, and keyboard.

A network20connects computers4and6. The network20is any form or medium of digital data communication, e.g., a communication network. Examples of communication network20include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

Computer4executes instructions of a front-end application program12. Application program12represents a front-end component of the business software architecture2. Service manager16, running on computer6, is a service layer between the front-end application program12and a set of back end service providers26. Service manager16provides a service interface to front end application program12to enable indirect interaction with the set of back end service providers26running on computer6. This service interface allows for a partial separation of software development for front-end application program12and the set of back end service providers26.

Computer6includes a data storage device22that stores a back end database24containing data that can be used by the set of back end service providers26. A transactional buffer50is used to store modifications to the database24. Computer6also includes a data storage device8containing an information repository18that defines and describes the services provided by the set of back end service providers26. The meta data in repository18is organized according to a meta model and stored in an additional database. In some examples, the meta data in the repository18is stored in tables.

In general, a meta model is a collection of “concepts” that are the vocabulary with which a certain domain can be described. Meta models typically are built according to a strict rule set, which in most cases is derived from entity-relationship-attribute or object-oriented modeling. The front-end application program12can access (and interpret according to the strict rule set) the contents of repository18via the service manager16. These services support the functionality of application program12and include retrieving and reading data in addition to modifying stored data. The service providers26can access or modify stored data in backend database24to provide services to front end application program12. To provide the services, the set of back end service providers26, upon request from the front end application program12, either access or modify stored data in backend database24or calculate new data.

The repository18defines a syntax for requesting services provided by the set of back end service providers26and semantically describes the services. As front-end application program12executes, front-end application program12can use this syntax and semantic description from the repository18(accessed through the service manager16) to determine what services front-end application program12can use to meet its requirements. This syntax and semantic description for stored or computed backend data can be referred to as “meta data”. This stored or computed backend data is conceptually organized using object-oriented terminology in terms of business objects, where each business object is an instance of a class or data entity type. In one example, a class of business objects refers to a relational database table where each row of data in the table represents the data for a particular business object. In this example, each field in the table represents an attribute of the business object class. In another example, there is a class of business objects that partially refers to a relational database table such that some of the fields in the table represent attributes of the business object class and other fields are computed upon request.

In the business software architecture2, services provided to front end application program12are focused on data (i.e., data-centric) so the description of these services in repository18is also data-centric. Thus, the meta data in repository18is structured around representations of classes of these business objects. This meta data includes aspects, or descriptions of these representations of business object classes, and descriptions of available operations on aspects such as select, insert, update, delete, select by relation, and update fields that are provided by service providers26. Each description of these aspects includes data attributes as well as actions that can be requested to be executed by the set of backend service providers26on instances of these aspects.

Classifications of data, relations between data classes, prebuilt queries for accessing data, and other descriptions of data provided by the set of backend service providers26are represented by repository18. This representation, or meta data, of data (e.g., stored in backend database24) provided by the set of backend service providers26describes different abstract types or classes of data in backend database24and how different data classes relate to each other. Objects are instances of these different abstract types. Meta data is information about data rather than content of the data. The meta data also defines a set of pre-built queries that can be executed on the data in database24.

The semantic description in repository18can enable front-end application program12to determine which services to request from service manager16. These services often take the form of requesting data to display. Front-end application program12reads the meta data in repository18and can flexibly request data organized in different ways that are specified by the meta data. For example, two service managers16with two different repositories18handle services that determine prices of books for companies A and B. For A and B, book prices are represented by different aspects with different data fields. Front-end application program12reads A's repository18to obtain descriptions of data (including a price) concerning a particular book from A's service providers26. Front-end application program12reads B's repository18to obtain descriptions of data (including a price) concerning a particular book from B's service providers26. Front end application program12is able to request and display the information from A's service provider26and the information organized differently from B's service provider26to present the book price information to a user.

During execution, front end application program12issues service requests to service manager16, service manager16checks the requests for consistency with the meta data in repository18, and then the service manager16passes the requests to back end service providers26according to the meta data in the repository database18. The manner of implementing the set of back end service providers26and data in database24is independent of application12, with back end service providers26and data in database24conforming to the definitions and descriptions of the meta data in the repository18. Database24can be a relational database. However, database24can be modified to use a different mode of data organization other than a relational database and front end application program12does not need to be modified if back end service providers26and data in database24still conform to the meta data in the repository18. One such different mode of data organization for database24can be an object-oriented database.

Front-end application program12provides user interfaces displayed on monitor10. Front-end application program12provides application code to display and aggregate the data received from the set of backend service providers26. Front end application program12is interaction-centric, focused on aggregating data of the back end service providers26and combining interactive steps into a flow of screens and syndicated screen elements.

Front-end application program12contains screen-flow logic of User Interface (UI) oriented applications and front-end application program12binds a UI to the meta data in repository18.

In some implementations, a service manager proxy14gives the front end application program12a buffered access to a service interface provided by service manager16. Service manager proxy14is a server on computer4that acts as an intermediary between the front-end application program12and the service manager16so that the business software architecture2can ensure security, administrative control, and caching service. The service manager16offers a queuing functionality, which is used by the front end application program12to bundle several service requests or commands (resulting in service methods) into a single service method queue in order to save round trips.

In one example, the front-end application program12communicates with service manager16either directly or via a proxy using SOAP (Simple Object Access Protocol) messages via network20. SOAP is a way for a program running in one kind of operating system (such as a Windows® XP Operating system available from Microsoft Corporation of Redmond, Wash.) to communicate with a program in the same or another kind of an operating system (such as Linux) by using the World Wide Web's Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML) as mechanisms for information exchange. Since Web protocols are installed and available for use by all major operating system platforms, HTTP and XML provide a solution to a problem of how programs running under different operating systems in a network can communicate with each other. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer can call and pass information to a program in another computer. SOAP also specifies how the called program can return a response.

As shown inFIG. 3, the service manager16provides an interface (defined by the meta data in repository18) to front end application program12that hides the characteristics of the corresponding back end service providers from the set of backend service providers26and data in database24. Front-end application12uses this interface to retrieve data from backend database24to display in graphical user interface (GUI)28for interaction with a user.

The service manager16provides the interface to front end application program12by receiving and executing requests from front end application program12to backend service providers26. After each receipt of a request by the service manager16, the service manager16delegates the request to one or more service providers30,32,34,40,42,44, and46. Service provider30is an instance of a software class repository service provider. Service providers32,34,40,42,44, and46represent instances of software classes such as query service provider class (32), aspect service provider class (34), transaction service provider class (40), locking service provider class (42), action service provider class (44), and query relation service provider class (46). The software classes for service providers32,34,40,42,44, and46can be implemented as ABAP global classes maintained by the ABAP class library using the ABAP development environment available from SAP of Walldorf, Germany. They also can be implemented by any other programming language on any other platform, e.g., Java on Linux or C# on Windows.

Repository service provider30handles requests to get or modify meta data from repository18. Query service provider32handles queries on data in backend database24from front-end application program12. Aspect service provider34handles accessing and modifying data, navigation through relations, and calling actions. The aspect service provider34has a standard set of methods that correspond to the standard operations on aspects that can be requested from the service manager16. These standard operations include select, insert, update, delete, select by relation, and update fields. Transaction service provider40allows business logic to act on different states of a transaction between front-end application program12and service providers26. Locking service provider42enables separation of concurrent accesses on data types in backend database24. Action service provider44enables execution of actions on aspects. Query relation service provider46is the interface for the target aspect of a relation. In some examples, service manager16can have different multiple instances of service providers32,34,40,42,44, and46for different elements in repository18representing services. Upon receiving a request for a service represented by an element in repository18, the service manager16can look up a name of a service provider (e.g.,32,34,40,42,44, and46) in the meta data for the element in repository18. For example, the meta data describing an aspect in repository18defines which aspect service provider34is designed to handle services for the aspect. The service manager16uses this information in the meta data to direct requests from the front-end application program12to the appropriate aspect service provider34. Similarly, the meta data describing a query in repository18defines which query service provider32is designed to handle services for the query. The front-end application program12can make requests such as insert, update, and delete to modify data in the back end database24. Aspect service provider34or action service provider44can handle such requests. These data-modifying operations are not performed on the backend database24directly. To allow well-defined transaction handling for these operations, each modifying operation is performed on a transactional buffer50that is controlled by the transaction service provider40. Only the methods of the transaction service provider40lead to a database commit or a rollback of the buffered data. In addition, the locking service provider42performs locking operations before the data is changed. Each locking operation must also be buffered.

Within the transactional buffer50, it should be clearly marked which modifying operation (such as insert, update, delete) was performed on which aspect row. Later on during a SAVE event, the application data storage is changed according to this buffer content, provided all checks during a BEFORE_SAVE event were successful.

A transaction is a sequence of information exchange and related work (such as database updating) that is treated as a unit for the purposes of satisfying a request from front end application program12to service manager16and for ensuring integrity of backend database24. For a transaction to be completed and changes to database24to be made permanent, a transaction has to be completed in its entirety. All of the steps of a transaction are completed before the transaction is successful and the database is actually modified to reflect all of the requested changes. If something happens before the transaction is successfully completed, any changes to the backend database24must be kept track of so that the changes can be undone.

To handle transactions, the transaction service provider40receives notifications on the various states of a transaction between service manager16, another non-transaction service provider (e.g.,32,34,44,46), and front-end application program12(or service manager proxy14in some cases). These notifications are the transaction service provider40's methods BEFORE_SAVE, CLEANUP, and SAVE that are called by the service manager16during transactions.

The service manager16calls the transaction service provider40's method BEFORE_SAVE to check if data in the transactional buffer50can be saved. This allows checking if the internal state of the non-transaction service provider is ready for being saved. The method BEFORE_SAVE returns false if it is not possible to save data in the transactional buffer50, then the transaction end is aborted. Thus, the BEFORE_SAVE method has a BOOLEAN return parameter. BEFORE_SAVE takes a Boolean as an input parameter REJECTED. The transactional service provider16can prevent the following save and commit operations by setting the REJECTED parameter to a non-initial value, i.e. to “true”. The method BEFORE_SAVE is called within the service manager's16's sequence of operations triggered by the front-end application12's SAVE method.

The SAVE method finally triggers the application to save the transactional buffer50to the database24. By calling SAVE, all internal states of a non-transaction service provider are made persistent—either by direct updates or by creating appropriate calls to the update task. If all service providers in architecture38have received a SAVE request, service manager16commits the transaction.

The CLEANUP method tells all non-transaction service providers to release all their transactional buffers and enqueue-based locks. Calling CLEANUP method communicates that all service providers in architecture38need to clean up their internal state. CLEANUP takes a REASON string as an input parameter. The REASON field indicates the reason for the clean up operation. This can be either a ‘COMMIT’ due to a SAVE-operation or the ‘END’ of the transaction due to the system closing the transaction automatically. There is no guarantee that cleanup is called under failure conditions.

The service providers32,34,40,42,44, and46, as described above, enable the following transactional model for the architecture38. Executing method SELECT of aspect service provider34reads from the backend database24or reads from the transactional buffer50stored in the back-end. Aspect service provider34merges data from both sources—the database and its transactional buffer50—in a consistent way so that the merge data reflects the updates made so far in this transaction. Next, executing UPDATE, INSERT, MODIFY, or DELETE methods of aspect service provider34builds up a transactional buffer. Before actually changing data in the transactional buffer50, the service manager16has to acquire a transactional lock on the data and read the data under the protection of a lock. There are exclusive, shared, and shared promotable lock modes available using locking service provider42as described previously. Locking has to be accompanied by selecting the locked data again under the protection of the lock. Applications can support optimistic locking by providing time-stamped or otherwise versioned data, and merging actual and modified data on the front-end in case of conflicts.

The BEFORE_SAVE method of the transaction service provider40enables all participating service providers to declare if they are ready for saving the transactional buffer50. The SAVE method of the transaction service provider40finally triggers service manager16to save the transactional buffer50to the backend database24.

The CLEANUP method of the transaction service provider40notifies all service providers (e.g., aspect service provider34) to release all their transactional buffers (e.g.,50) and enqueue-based locks. If CLEANUP is called with reason ‘END’, all locks have to be released. If reason is set to ‘COMMIT’, each service provider can chose to keep its locks.

Aspect service provider34must not call COMMIT WORK or ROLLBACK WORK internally on its own. The service manager16enforces this by automatically aborting the transaction if aspect service provider34is trying to commit a transaction.

The supported locking models and lock policies are as follows. Using policy S, many participants can obtain a shared lock. If a shared lock is obtained on an object, no exclusive lock or SP lock can be obtained. Shared locks can only be used to achieve a consistent view on a larger set of data during read operations. Using policy E, only a single participant can obtain a lock. Using policy SP (shared promotable), many participants can obtain the lock. If a SP lock exists, exclusive locks can only be obtained by participants already having a SP lock on the object. Only one of the participants can upgrade the lock to an exclusive lock. No other participant, who did obtain a lock prior to the upgrade, can upgrade to exclusive even if the first participant did release its lock.

In addition to the transactional buffer50, a locking buffer52stores the locking status of the aspect rows that are used during the transactional context.

Business software typically provides consumers with scenario-specific interface technology to access and update business application logic and business data. One essential feature for a user interface is adequate help values for entry fields. In many state-of-the-art applications these help values are presented as list boxes.

As long as the list of possible values is static (i.e. not depending on a specific instance of an aspect (i.e., aspect row) or other input data), the value help can be separated from business logic. The possible values are then part of the type information for the field. However, in the dynamic case where business logic needs to provide the real values for a field in a given aspect row, the value list should be transported and provided through the service manager16. In some examples, the business logic can provide these values by filtering the list of possible values based on a context established by data previously entered by the user.

The architecture38provides a dynamic field-bound context-related value set infrastructure and programming model. The service manager16provides a value set interface that can be implemented by the value set service provider48and that can be called by the application program12at runtime. The architecture38provides the service provider48all necessary context information without affecting any transactional buffer (e.g., buffer50). The application and service providers have to be compliant with a standard wildcard-query mechanism of the architecture38. The value set infrastructure provides a standardized and easy to use way for accessing dynamic value sets in the service-oriented business architecture38.

A value set service provider48provides an interface IF_COL_VALUE_SET that provides a service or method GET_VALUE_SET to handle a value set request. The application program12requests the service GET_VALUE_SET to retrieve value set data from the backend database24and its transactional buffer50. As with other requests using the architecture38, the application program12sends the request to the service manager16, the service manager16checks the request against meta data in the repository18, and then the service manager16passes the request to the service provider48. The service provider48is specified in the request. The service provider48handles the request and sends back a value set to the application program12through the service manager16. The meta data describing the value set request provides a standard description of possible value sets that can be requested by the application program12.

The returned value set data is dependent on a context that is possibly determined by a set of input values and a set of possible values stored in the database24and its transactional buffer50. These values can be grouped into a data structure. The input values are an instance of the data structure, with some fields of the data structure left unspecified. The set of possible values are possible instances of the data structure stored in the backend database24and its transactional buffer50. The application program12also specifies a field of interest for which value set data is to be provided. The service provider48then matches the instance of the data structure against all of the instances of the data structure stored in the backend database24and its transactional buffer50. Unspecified fields in the instance of the data structure do not constrain this matching. The stored instances of the data structure that match the instance are then put in a list. Values of the field of interest of these matching instances are put into a second list. This second list is sorted and redundant values are removed to form a third list. The context-dependent value set data is this third list that is passed to the application program12.

In some examples, the service provider48may use a search engine on the backend database24and its transactional buffer50. An example of such a search engine is the TRex® server that is commercially available from SAP® of Walldorf, Baden, Germany. The TRex® server is software that can also be installed on a separate server. TRex® is equipped with a variety of search functions: general queries, searches for special terms, Boolean searches linked with “and” as well as the “search similar” function. In addition to linguistic queries, such as different forms of the same word, and complex searches by author or date, TRex® also offers search functions provided by popular Internet search engines.

In some examples, the value set service is also available for free-style user interfaces and other clients, e.g. other services calling services by the service manager16.

One purpose of the value set data is to provide context-dependent help data to a user of a user interface such as GUI28. The context-dependent help data can be provided to the user using different techniques. For example, the list of possible values or description texts for values is presented in a drop-down list box, which is filled via a list of key-value-pairs.

The list of values can also be presented in a specific result view (either separate frame or replacing current frame content) when a value-help button is pressed. The structure of the result view can be specific for a field and may contain more than one column.

The request for value-help can also lead to the start of a separate application including an object identification pattern component with simple and advanced search facilities.

The method GET_VALUE_SET has input parameters STRUCTURE, FIELD, and INPARAM. That is, application program12inputs parameters STRUCTURE, FIELD, and INPARAM when the application program12calls the method GET_VALUE_SET. Parameter STRUCTURE contains a string name of a predefined data structure that stores records displayed by the GUI28. Parameter FIELD is a string name of a field in the data structure for which value help is to be provided by the service provider32. Parameter INPARAM contains data for the dynamic value help request.

The method GET_VALUE_SET has output parameters OUTVALUES and REJECTED. That is, application program12receives parameters OUTVALUES and REJECTED when the application program12calls the method GET_VALUE_SET. Parameter OUTVALUES is an INDEX TABLE type containing possible values for the FIELD for this value help request. Parameter REJECTED is a Boolean data type and indicates whether there was an error in executing the method GET_VALUE_SET by the service provider48(REJECTED=TRUE) or no error occurred (REJECTED=FALSE).

Before the value set request is started, it is not necessary to send changed data into the transactional buffer of the backend. The actual changes of the current aspect row on the GUI28are transported to the backend database24for the value request via the input parameters (INPARAM) only. The application12might support some kind of wild card mechanism for the aspect fields. If the field is typed as a character or a string, search requests like *X* might be send via the input parameters to the backend. The implementation of the wild card search is in the responsibility of the backend.

For each value set, meta data is supplied to describe the value set service provided by the service provider32. The meta data includes an input parameter structure, an outvalues structure, and a name of a value set service provider48. The input parameter structure is the INPARAMs structure that can be used for dynamic context-related value sets. The outvalues structure is the OUTVALUES structure containing the list of the allowed values for the actual field. These allowed values can be a simple key-text-list or a structure with more decrypting information to each value. Lastly, the value set provider class implements the interface IF_COL_VALUE_SET.

As mentioned previously, the meta data in the repository18is stored in database tables. For value sets, in one example, meta data for each value set request is stored as records of a table SCOL_VALUE_SET. Table SCOL_VALUE_SET has the following fields.

VALUE_SET_NAMEName of the dynamic value setFIELDNAMEName of the field for which the value setis requiredPARAM_STRUCTUREInput parameter structureOUTVAL_STRUCTUREOutput values structurePROVIDER_CLASSValue set service provider classEDITORDEROrder of entry of this dynamic value set inthe meta data repository screen

In examples, the field PROVIDER_CLASS specifies the value set service provider48. The service manager16, upon receiving a request for a particular dynamic value set (specified by VALUE_SET_NAME), looks up the record corresponding to the dynamic value set name and then retrieves the name of the value set service provider48in field PROVIDER_CLASS. The service manager16then calls the method GET_VALUE_SET of the interface IF_COL_VALUE_SET provided by the value set service provider48.

An example of the table SCOL_VALUE_SET is provided by Table 1 below. Table 1, SCOL_VALUE_SET, illustrates meta data for value sets CARRID, CITYFROM, CONNED, and PRICE. These value sets can be used to request help values for the GUI28for an aspect SCOL_FLIGHTS_DETAIL. Examples are described below that use the value sets CARRID and CITYFROM.

EXAMPLE I

Referring toFIG. 4, a menu screen100represents a usage of value set requests for flight information. Specifically, the menu screen100uses value set request CARRID defined in Table SCOL_VALUE_SET of the meta data in the repository18. The GUI28(also represented inFIG. 3) follows instructions of the application program12to generate the menu screen100for listing flight data stored in the backend database24in rows. For each flight in the listing, the menu screen100displays five fields including an airline carrier identity (ID), a flight number, a flight date, a depart city, and an arrival city. For each row, the combination of the five data elements is a unique combination. A column102, denoted as Airline Carrier, displays the airline carrier ID for each row. The menu screen100also allows a user to view data about other flights by changing the airline carrier ID for a given row. As shown inFIG. 4, when the user types an “A*” in a row104, the application program12makes the value set request CARRID to the service provider42for airlines having IDs beginning with “A”. The service provider34returns an OUTPARAMS structure for the CARRID value set request, the OUTPARAMS structure including a list of airlines having IDs beginning with “A”. The GUI28displays a pop-up window106with the list to the user. The pop-up window106includes two columns of data, a column108with airline carrier IDs and a column110with full names of the airlines. These airlines include American Airlines®, Air Berlin®, Air Canada®, Air France®, and Alitalia®. The user can select one airline carrier ID (e.g., “AF” corresponding to Air France®) from the list in the pop-up window106. Subsequently, the GUI28closes the pop-up window106and replaces the element “A*” with element “AF” in the menu screen102.

The GUI28then can modify the other fields for the row104according to the new element “AF”. For example, if Air France® does not have a flight with number 0017, on Mar. 12, 2003 departing from New York and arriving at San Francisco, various fields can be blanked out according to some rule and the user can fill in the missing information. For example, if Air France® has flights from New York to San Francisco, then the user can enter data in fields for Flight Number and Flight Date using pop-up windows similar to pop-up window106, each pop-up window having a finite number of selections based on flight data in the backend database24for Air France ®.

An aspect SCOL_FLIGHTS_DETAIL is the meta data corresponding to the flight data stored in the backend database24. The data corresponding to the aspect SCOL_FLIGHTS_DETAIL is spread out in multiple data tables. The backend database24stores Table 2, SCARR. The Table 2 has fields CARRID (carrier ID or acronym), and CARRNAME (carrier full text name) to enable matching an airline carrier ID to its name or vice-versa. The backend database24also stores other additional tables containing flight information. These additional tables include fields CONNID, COUNTRYFR, CITYFROM, COUNTRYTO, and CITYTO.

As described previously, the meta data descriptions of value set requests include values for STRUCTURE, FIELD, INPARAM, OUTVALUES, and REJECTED. For the meta data description of the value set request on the aspect SCOL_FLIGHTS_DETAIL to get value help information for the pop-up window106, the STRUCTURE is a string “SCOL_FLIGHTS_DETAIL” denoting the aspect SCOL_FLIGHTS_DETAIL. The FIELD is a string “CARRID” denoting the CARRID field in Table 2. Thus, the meta description of this value set request specifies that this value set request is intended to return possible values for the CARRID field. The INPARAM is SCOL_FLIGHTS_DETAIL so that the application12is expected to send an instance of the aspect SCOL_FLIGHTS_DETAIL in order to receive the possible values for the CARRID field. It should be noted that this instance of the aspect SCOL_FLIGHTS_DETAIL does not have to be completely filled out. For instance, in the example help value request to generate the pop-up window108, the instance of the aspect SCOL_FLIGHTS_DETAIL only has one field filled out, the Airline Carrier or CARRID field, with a wildcard. The OUTVALUES, or return index table, is SCOL_DDIC_KEY_TEXT_LIST. This SCOL_DDIC_KEY_TEXT_LIST index table is defined in the meta data of the repository18to include two fields: FIELDKEY and TEXT. Thus, the SCOL_DDIC_KEY_TEXT_LIST is a two-column table. When an instance of the return index table SCOL_DDIC_KEY_TEXT_LIST is passed to the application program12from the service provider34, the FIELDKEY field contains the CARRID information and the TEXT field contains the CARRNAME information for instances of the aspect SCOL_FLIGHTS_DETAIL matching the partially filled out instance of the aspect SCOL_FLIGHTS_DETAIL sent by the application program12as part of the value set request.

Specifically, the application program12sends to the service provider34a value set request with the CARRID specified as “A*”, and other fields CARRNAME, CONNID, COUNTRYFR, CITYFROM, COUNTRYTO, and CITYTO set to NULL. The service provider34searches in the backend database24for all instances of the aspect SCOL_FLIGHTS_DETAIL matching the partially filled out instance of the aspect SCOL_FLIGHTS_DETAIL. This match includes all instances in the backend database24having CARRID beginning with an “A”. The service provider34then generates a first list of these instances and removes instances whose CARRID values are duplicated to generate a second list. That is, if backend database24stores two flights for CARRID=“AF” (Air France®), resulting in a first list with the two flights, the second list only has one CARRID=“AF” entry. This second list follows the SCOL_DDIC_KEY_TEXT_LIST format with the FIELDKEY field containing the CARRID text and the TEXT field containing the CARRNAME text. In general, the SCOL_DDIC_KEY_TEXT_LIST format can be used to return a technical name (FIELDKEY) and a longer text name or nickname (TEXT).

Upon receiving the second list with the SCOL_DDIC_KEY_TEXT_LIST structure, the application program12fills out the pop-up window106with the values in the second list. In other examples, the application program12presents to the user a dropdown list box with two columns containing the same information.

EXAMPLE II

Referring toFIG. 5A, a menu screen120shows another example of the value set request CARRID to assist a user with a search for flight information. The GUI28(illustrated inFIG. 3) follows instructions of the application program12to generate the menu screen120to enabling a user to generate a search for flight data. The menu screen120presents a set of fields for search criteria for the user to specify. This search criterion includes an airline carrier name field122, a country key field124, a city of departure field126, an airport of departure field128, a country key field130, an arrival city field132, a destination airport field134, flight date fields136and138, and a flight class field140. After specifying one or more of the search criteria, the user clicks a “Search” button142to initiate a search of flight data in the backend database24based on the specified search criteria. The application program12displays the results of the search in rows of a section144of the GUI28.

For specifying a search criterion, e.g., an airline carrier, the user types in a name of an airline in the airline carrier name field122. However, the user may not know the exact spelling of the airline. For example, the user may wish to search for flights offered by Lufthansa® but may only know that Lufthansa® begins with an “L”. In this case, the user types an “L*” in the field122and clicks on a downward arrow146. The application program12then initiates the value set request CARRID to the service provider34.

Referring toFIG. 5B, the results of the value set request are displayed in a drop-down-list box152.

The meta data description of the value set request CARRID was described for Example I. For the example value set request to generate values for the drop-down-list box152, the user sets the Airline Carrier Name field146with a wildcard “L*”. When an instance of the return index table SCOL_DDIC_KEY_TEXT_LIST is passed to the application program12from the service provider34, the FIELDKEY field contains the CARRID information and the TEXT field contains the CARRNAME information for instances of the aspect SCOL_FLIGHTS_DETAIL matching the partially filled out instance of the aspect SCOL_FLIGHTS_DETAIL sent by the application program12as part of the value set request.

Specifically, the application program12sends to the service provider34a value set request with the CARRID specified as “L*”, and other fields CONNID, COUNTRYFR, CITYFROM, COUNTRYTO, and CITYTO set to NULL. The service provider34searches in the backend database24for all instances of the aspect SCOL_FLIGHTS_DETAIL matching the partially filled out instance of the aspect SCOL_FLIGHTS_DETAIL. This match includes all instances in the backend database24having CARRID beginning with an “L”. The service provider34then generates a first list of these instances and removes instances whose CARRID values are duplicated to generate a second list. That is, if backend database24stores two flights for CARRID=“LH”, resulting in a first list with the two flights, the second list only has one CARRID=“LH” entry. This second list follows the SCOL_DDIC_KEY_TEXT_LIST format with the TEXT field containing the CARRNAME text “Lufthansa”. The application program12then displays the CARRNAME text “Lufthansa”.

Referring toFIG. 6, another example value set request for CARRID values is displayed by menu screen160. A user types in “A*” in field122and the application program12sends a value set request for CARRID specified as “A*”. The service provider34then returns a list of airline carrier IDs beginning with “A” and corresponding text names in the SCOL_DDIC_KEY_TEXT_LIST format. The application program12receives this list and the CARRNAME fields are displayed in the drop-down-list box162.

EXAMPLE III

Referring toFIG. 7, a menu screen180, similar to the menu screen120, also allows a user to receive value set help for flight information. In this example, the user has already entered “Lufthansa” into the field122. The user wants to enter in a city of departure in the field126, but only knows that that the city name begins with an “N”. The results of the value set request are displayed in a drop-down-list box184. The list box184displays all cities starting with “N” where Lufthansa flights depart. This value set request is the CITYFROM value set request defined in the meta data table SCOL_VALUE_SET. For this example, the backend database24stores instances of the aspect SCOL_FLIGHTS_DETAIL that are listed in Table 3 (SPFLI) as follows.

For the meta data description of the value set request CITYFROM, the STRUCTURE is a string “SCOL_FLIGHTS_DETAIL” denoting the aspect SCOL_FLIGHTS_DETAIL. The FIELD is a string “CITYFROM” denoting the CITYFROM field in Table 3. Thus, the meta description of this value set request specifies that this value set request be intended to return possible values for the CITYFROM field. The INPARAM is SCOL_FLIGHTS_DETAIL so that the application program12is expected to send an instance of the aspect SCOL_FLIGHTS_DETAIL in order to receive the possible values for the CITYFROM field. This instance of the aspect SCOL_FLIGHTS_DETAIL specifies two fields, the CARRID field and the CITYFROM field. Since the value set request CITYFROM expects to receive an airline carrier ID in the CARRID field, the application program12first looks up the airline carrier ID “LH” corresponding to the airline carrier name “Lufthansa” in Table SCARR. The application program12then sends the airline carrier ID “LH” in the CARRID field of the value set request CITYFROM.

The OUTVALUES, or return index table, is the SCOL_DDIC_KEY_TEXT_LIST described previously for Example I. When an instance of the return index table SCOL_DDIC_KEY_TEXT_LIST is passed to the application program12from the service provider34, the FIELDKEY field contains the CITYFROM information for instances of the aspect SCOL_FLIGHTS_DETAIL matching the instance of the aspect SCOL_FLIGHTS_DETAIL sent by the application program12as part of the value set request. In this example, the TEXT fields are a replication of the FIELDKEY fields.

Specifically, the application program12sends to the service provider34a value set request with the CARRID specified as “Lufthansa” and the CITYFROM specified as “N*”, and other fields CONNID, COUNTRYFR, COUNTRYTO, and CITYTO set to NULL. The service provider34searches in the backend database24for all instances of the aspect SCOL_FLIGHTS_DETAIL matching the partially filled out instance of the aspect SCOL_FLIGHTS_DETAIL. This match includes all instances in the backend database24having CARRID=“Lufthansa” and the CITYFROM=“N*”. The service provider34then generates a first list of these instances and removes instances whose CITYFROM values are duplicated to generate a second list. This first list contains instances with CITYFROM={NEW YORK, NASHVILLE, and NASSAU}. In this example, the second list is the same as the first list. This second list follows the SCOL_DDIC_KEY_TEXT_LIST format with the FIELDKEY field containing the CITYFROM text.

EXAMPLES OF DATA REPRESENTATION

Referring toFIGS. 8,8A, and9, another example of the GUI28is represented by GUI210. The GUI210includes fields212,214,216,218,220, and222for input of data by a user. The fields212,214,216,218,220, and222belong to a data structure252and the fields correspond to data types212′,214′,216′,218′,220′, and222′, respectively. The fields218,220, and222belong to a subset224. Entered values of fields in the subset224establish a context for a user help request for choices for field216.

A display226of a list228shows appropriate data elements for the selected field216, the data elements being appropriate to the context of the displayed data elements in fields218,220, and222. The display226appears in response to the user clicking an icon229. The display226allows the user to select one of the appropriate data elements.

These appropriate data elements have a type216′ that corresponds to the selected field216. These appropriate data elements are read from a back end collection250of data in backend database24and transactional buffer50. The collection250includes data structure instances252,254,256,258,260,262,264, and266. These instances represent possible combinations of data elements that could be displayed in the fields212,214,216,218,220, and222. The list228is derived from these possible combinations.

In response to the user clicking on icon229, the application program12sends an INPARAMS specifying the structure230with types212′,214′,216′ not specified and types218′,220′, and222′ specified as “XXX”, “YYY”, and “ZZZ”, respectively. The STRUCTURE also specifies a type of the structure230. The FIELD specifies type216′. The OUTVALUES returned to the application program12is the list228or {“AAA”, “BBB”, “CCC”, and “DDD”}.

On the backend, the value set service provider48handles the request by the application program12by determining which of the possible instances of data elements in the collection250are appropriate to the context established by data set224. To do this, the service provider48determines that instances254,258,260,264, and266in data set268match the context of the data set224since fields218′,220′, and222′ of these instances match the data set224. From these instances, the service provider48determines that values in field216are repeated for instances264and266. The service provider48returns the list228as OUTVALUES to the application program12.

Referring toFIGS. 10,10A, and11, a GUI300is the GUI210in a different configuration. GUI300includes the context established by the set224but the user has also entered in a wildcard “A*” in field216. A different backend data collection302includes an instance304of the data structure defined by the fields212,214,216,218,220, and222.

In response to the user clicking on icon229, the application program12sends a value set request with an INPARAMS specifying a structure310with types212′,214′not specified and types216′,218′,220′, and222′ specified as “A*”, “XXX”, “YYY”, and “ZZZ”, respectively. The STRUCTURE specifies the type of the structure310. The FIELD specifies type216′. The OUTVALUES returned to the application program12is the list306or {“AAA”, “ABB”}.

On the backend, the value set service provider48handles the request by the application program12by determining which of the possible instances of data elements in the collection302are appropriate to the context established by data set224and the wildcard in field216. To do this, the service provider48determines that instances254, and304in the data set302match the context since fields216′,218′,220′, and222′ of these instances match the context. Specifically, the “AAA” and “ABB” matches the wildcard entry “A*”. The service provider48returns the list306as OUTVALUES to the application program12.

The invention has been described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.