Like reference numerals in the various drawings indicate like elements.
A product input box 108 allows the user to associate a particular product with the sales order quote. The product input box 108 may be an additional tokenizer for inputting or finding a product identification key, or it may be a standard input control. A save button 110 is used to create the new sales order quote once the customer key and/or product key have been submitted or obtained.
In
In this example, a single customer matches the string that the user enters in the customer tokenizer box 106. In
This method may be used, in another implementation, to modify or otherwise access an existing sales order quote. For example, the user may wish to make a change to the sales order XYZ and may therefore search for it using the GUI 102. When the user activates the button 110 (which may then have a different appearance), the existing sales order could be presented, e.g. within a pop-up window or other GUI implementation. The user may then be able to modify fields of the sales order. For example, the user may wish to add or remove products listed within the sales order quote.
A customer object and a product object are required to define a sales order quote object 206. One sales order object can be assigned to one or more customers; one customer can be assigned to any number of sales orders; one product can be assigned to any number of sales orders. Particularly, the sales order quote object is here defined as having an association 203 with the customer object 202. Also, the sales order quote object is defined as having an association 205 with the product object 204. For example, the customer key and the product key are fields within the sales order business object which create the association between the business objects. There may be any number of business objects related to the sales order quote object 206.
An instance is a unique instantiation of a business object created by populating the fields of the business object with information that is particular to an entity to be represented by the instance. A customer instance 208 may contain the name, address, phone number, etc of a specific customer. Similarly, each of several product instances 210 may contain the name, model number, price, etc. of a specific product. There can be many instances of each business object. Each instance is uniquely identified by a key. For example, a sales order quote instance 212 contains the key of the customer instance 208 and any number of key(s) of the product instance(s) 210.
To create the sales order quote instance 212 using the GUI 102, the customer tokenizer box 106 allows the user to submit either a customer key or a string which may be used to locate a customer key. The customer tokenizer box 106 uses associations to relate the user input to the customer object 202. A query is then defined to retrieve the customer key(s) of any customer instances which contain the information within the search string. In addition to the customer instance 208 and the product instance(s) 210, there may be additional instances linked to a sales order quote, such as a financing information instance, etc. Rather than a sales order quote, a similar GUI 102 could be used to create, for example, a repair order or a customer support request.
When the user activates the link, the object key or keys belonging to the matching object(s) is forwarded to a portal navigation module 310. In some implementations, a type of the sought business object (here a customer object) is also forwarded to the portal navigation module. When the portal navigation module 310 receives the object key(s), it causes the associated object page(s), such as the first object page 308a, to be displayed within the GUI 102. In
An Enterprise Services Repository (ESR) 412 contains associations and other metadata. These associations are used by the ESI service management/user interface 410 to verify which object the current (sales order) object is related to. Particularly, the association that will be selected is the one that the tokenizer control 406 is associated with. The associated metadata within the ESR 412 is then used to define a customer query 416 to locate the dependent object's identifier key (i.e. customer ID) that the independent object (i.e. sales order) should contain (step 414).
The customer query 416 is here performed in a secondary store 418 which includes the TREX repository and search engine available from SAP AG in Walldorf (Baden), Germany. The secondary store 418 contains multiple instances of business objects. A query is run against the contents of the secondary store 418 to locate the customer instances which match the string “SAP”. For example, one or more customer instance may be discovered in which “SAP” matches all or a portion of the name field. In another example, a search phrase may match different field types of different customer instances, i.e. the string “waverly” may match both the name “John Waverly” of one customer instance and the address “Waverly Lane” of another customer instance. In yet another example, a phrase composed of multiple terms may be submitted to the tokenizer control 406. The ESR 412 and secondary store 418, though visualized as separate storage entities in the diagram, may be located in the same repository in some implementations. Search results, in the form of the key field(s) of one or more customer instances, are returned to the ESI service management/user interface 410 (step 420).
If there are either no results or multiple results, the information in this example is propagated back to the sales order interface 402 through the tokenizer control 406 (step 422) to be presented to the user, because the tokenizer control 406 here accepts only a single customer. If there were no results, the user will be presented with a failure notification and prompted to enter a different string. In the case of multiple results, a search dialog is opened to allow the user to select a single result (step 424). The search dialog, for example, may be in the form of a pop-up window. All keys matching the query are listed within the search dialog. In other implementations, business information may be listed within the search dialog.
The user selects a row from the list of customer keys (step 426). The selection is sent through the tokenizer control 406 to a business configuration repository 430 (step 428). In the case of the query generating a single result (step 432), the result is instead forwarded directly to the business configuration repository 430.
The business configuration repository 430 contains information specifying which fields of the business objects are used to make up their human-readable tokens. Using the result key returned from the customer query 416, a token is generated to be viewed within the tokenizer control 406 of the sales order interface 402. The token contains information retrieved from the customer instance associated with the result key relating to one or more fields of a customer business object 434, e.g. for business object customer, the token may be a concatenation of customer id, customer name, customer address city, and customer address zip code. This information helps the user to verify that the correct customer key has been obtained. The result key and token are propagated back through the ESI service management/user interface 410 (step 436) and then via the tokenizer control 406 (step 438) to the sales order interface 402 (step 440). The sales order interface 402 will present the token to the user.
Not all of the steps within the sales order system 400 must be taken in this order. In addition, some steps may be combined. In another implementation, if more than one search results are found (step 422), a set of tokens may first be obtained from the business configuration repository 430 for all of the result keys, such that the user may be presented, within the search dialog (step 424), a set of descriptive tokens to aid in the selection of a final customer key.
The full process illustrated may be truncated. For example, in a multiple result scenario (step 422), the result set returned to the user (step 424) may not be the one desired (i.e. the user typed “Johnson” but had meant to type “Johnston”, so the wrong set of customer tokens was returned). The user may choose to close the search dialog and submit a new query (step 404) rather than selecting a row from the result list (step 426).
As shown in
The user may now select a save button 506 to accept the first row 504 as the desired match. Selection of the save button 506 may, for example, close the pop-up window 502 and return the user to the GUI 102 where the customer tokenizer box 106 would contain the customer key associated with the first row 504. Alternatively, rather than containing the save button 506, each result row within the pop-up window 502 could be a selectable control used to return the user to the initial GUI 102. The user may alternatively opt to select one of the other customer entries listed.
The presentation method is not limited to a pop-up menu. In another implementation, an expanded customer tokenizer box 106 has a drop-down menu capability. Multiple entries could be returned to the user within the drop-down menu. In addition, the information presented to the user is not limited to name and address. Any number of information fields may be provided to allow the user to discriminate which is the desired entry. Alternately, a hyperlink to the full customer instance, such as the one provided within the customer tokenizer box 106 of
In
The method involves checking the number of results obtained from the query (step 610). If there is a single result, the method creates a token with a hyperlink (step 612). A token is related to the identification key of the matching instance of the second business object. The text of the hyperlink (e.g., the token) uniquely identifies the second business object instance for the user. It may contain a descriptive string in addition to the key to allow the user to recognize which instance the key belongs to. The hyperlink connects the user to the application (e.g., a portal page) that is used to view or maintain the complete details of the selected instance of the second business object.
If, instead, there is not just a single result, the method checks whether there are zero results (step 614). If so, the method loops back to receive a different search string (step 604). In one implementation, the user will be informed of the lack of results and prompted to enter a new search string.
If there are multiple results, the system displays the result set to the user to resolve the ambiguity (step 616). The result set, in one implementation, may be formatted within a pop-up window as illustrated in
There may be more or fewer steps than those illustrated within the flow diagram 600, and the steps do not necessarily have to be in this order. For instance, in the case of multiple results (step 614), a token and hyperlink may be created for each one (step 612) before the results are displayed to resolve ambiguity (step 616).
The system 700 includes a processor 710, a memory 720, a storage device 730, and an input/output device 740. Each of the components 710, 720, 730, and 740 arc interconnected using a system bus 750. The processor 710 is capable of processing instructions for execution within the system 700. In one implementation, the processor 710 is a single-threaded processor. In another implementation, the processor 710 is a multi-threaded processor. The processor 710 is capable of processing instructions stored in the memory 720 or on the storage device 730 to display graphical information for a user interface on the input/output device 740.
The memory 720 stores information within the system 700. In one implementation, the memory 720 is a computer-readable medium. In one implementation, the memory 720 is a volatile memory unit. In another implementation, the memory 720 is a non-volatile memory unit.
The storage device 730 is capable of providing mass storage for the system 700. In one implementation, the storage device 730 is a computer-readable medium. In various different implementations, the storage device 730 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.
The input/output device 740 provides input/output operations for the system 700. In one implementation, the input/output device 740 includes a keyboard and/or pointing device. In another implementation, the input/output device 740 includes a display unit for displaying graphical user interfaces.
The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program canbe written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.
The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.
The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Although a few implementations have been described in detail above, other modifications are possible. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.