Patent Application
20130174181
This description is directed generally to metadata models, and in particular, to a frontend-backend communication decision based on business object metadata.
Business object models may define structure and behavior of one or more corresponding data objects. For example, a M1 model may define a specific structure (e.g., hierarchical nodes and associated fields or attributes) and behavior (e.g., one or more enabled services) for a specific type of business object.
Business objects are real world entities modeled as objects in an information system. Business objects encapsulate both data structures and the functions or services applied to the data, while hiding their full complexity from other objects. This encapsulation of data and functions/services makes it easier to modify program components by allowing one to program with the relevant entities without having to know all the implementation details. Business objects also allow for the reuse of existing functions.
In one general aspect, a computer program product is provided. The computer program product is tangibly embodied on a computer-readable storage medium and includes executable code that, when executed, is configured to cause at least one data processing apparatus to provide a user interface from a runtime user interface (UI) application running on a frontend server to a client application; receive, by the runtime UI application from a business application running on a backend server, a business object that includes metadata associated with the user interface; receive, by the runtime UI application from the client application, user input associated with a business transaction, the user input including an input of a first field for the user interface; determine, by the runtime UI application based on the business object, whether processing by the business application of the first field input is required to determine and output to the client application an updated second field of the user interface before completion of the business transaction; and trigger a round-trip communication between the runtime UI application and the business application to process the first field and determine the updated second field before completion of the business transaction if the processing is required by the business application to determine and output the updated second field before completion of the business transaction.
In another general aspect, a computer implemented method is provided that includes providing a user interface from a runtime user interface (UI) application running on a frontend server to a client application; receiving, by the runtime UI application from a business application running on a backend server, a business object that includes metadata associated with the user interface; receiving, by the runtime UI application from the client application, user input associated with a business transaction, the user input including an input of a first field for the user interface; determining, by the runtime UI application based on the business object, whether processing by the business application of the first field input is required to determine and output to the client application an updated second field of the user interface before completion of the business transaction; and triggering a round-trip communication between the runtime UI application and the business application to process the first field and determine the updated second field before completion of the business transaction if the processing is required by the business application to determine and output the updated second field before completion of the business transaction.
In another general aspect, an apparatus includes providing logic configured to provide a user interface from a runtime user interface (UI) application running on a frontend server to a client application; receiving logic configured to receive, by the runtime UI application from a business application running on a backend server, a business object that includes metadata associated with the user interface; the receiving logic further configured to receive, by the runtime UI application from the client application, user input associated with a business transaction, the user input including an input of a first field for the user interface; determining logic configured to determine, by the runtime UI application based on the business object, whether processing by the business application of the first field input is required to determine and output to the client application an updated second field of the user interface before completion of the business transaction; and triggering logic configured to trigger a round-trip communication between the runtime UI application and the business application to process the first field and determine the updated second field before completion of the business transaction if the processing is required by the business application to determine and output the updated second field before completion of the business transaction.
The subject matter described in this specification can be implemented as a method or as a system or using computer program products, tangibly embodied in information carriers, such as a CD-ROM, a DVD-ROM, a semiconductor memory, and a hard disk. Such computer program products may cause a data processing apparatus to conduct one or more operations described herein.
In addition, the subject matter described herein may also be implemented as a system including a processor and a memory coupled to the processor. The memory may encode one or more programs that cause the processor to perform one or more of the method acts described in this specification.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the following, a detailed description of examples will be given with reference to the drawings. It should be understood that various modifications to the examples may be made. In particular, elements of one example may be combined and used in other examples to form new examples.
According to an example implementation, both stateful and stateless communication or transactions are supported. In an example implementation, in a stateless communication or transaction, backend processing for the transaction is not typically performed during the transaction, while backend processing is or may be performed during a stateful communication or transaction. Also, frontend-backend communication may be performed during a stateful communication or transaction. Some applications may require a stateful communication or transaction, while other applications may not necessarily require stateful transaction or communication. In such cases, stateless communication may be sufficient. Processor, memory and network resources may be conserved where a stateless communication or transaction may be used. In an example stateless communication or transaction, backend processing may be delayed, and frontend-backend communication may be suspended until after the end of a transaction. Therefore, according to an example implementation, an application (e.g., runtime UI application) running on a frontend server may determine, based on a business object, whether frontend-backend communication may be suspended until after completion of the transaction.
Backend server 112 may include a business application 114 for processing data. Backend server 112 also includes a database (not shown) or other data structure for storing data models, such as M1 models. Data models may define structure and behavior of one or more corresponding data objects. For example, a M1 model may define a specific structure (e.g., hierarchical nodes and associated fields or attributes) and behavior (e.g., one or more enabled services, methods or actions) for a specific type of business object. In an example implementation, backend server 112 may store different types of M1 models or business objects. For example, different types of business objects may be stored by backend server 112, such as an invoice business object (e.g., defining structure and behavior for invoice instances), a customer business object (defining structure and behavior for customer instances), and a shopping cart business object (defining structure and behavior for shopping cart instances). Each M0 instance of a M1 model follows the structure and behavior of the corresponding M1 model. For business objects, each instance of a business object follows the structure and behavior defined by the corresponding business object.
As shown in
According to an example implementation, in a stateful process or stateful business transaction, communications may typically occur between the runtime UI application of the frontend server and the business application on the backend server before completion of the business transaction to allow the business application to perform various tasks or processing and to provide information back to the runtime UI application. The backend processing by the business application may be performed to allow the runtime UI application to provide updates to a client application for one or more fields of a user interface based on the backend processing, e.g., to check product inventory and provide an error message if a requested item is not in stock, to calculate and provide item subtotals, or to provide calculated shipping charges for a specific user shipping preference and zip code.
Business application 114 may perform various types of data processing for or on behalf of runtime UI application 118, such as validations and calculations, as examples. For example, after receipt of user input from client application 122 and before completion of a business transaction, the runtime UI application 118 may forward user input (e.g., product IDs and quantity of items to be purchased, user shipping preferences, etc.) to the business application 114. The business application 114 may then perform a consistency validation, such as a product validation, by confirming that the selected quantity of the identified product(s) are available in stock or inventory. Business application 114 may store or may have access to a database that stores product inventory information, including quantities of each product that are currently in stock. Other types of data validation may be performed as well. Runtime UI application 118 may also receive from business application 114 an error message that an item (having a specific product ID) is not in stock, and runtime UI application 118 may forward or output such error message within a field of user interface 150 to client application 122.
The business application 114 may also perform one or more calculations for the runtime UI application 118, such as, for example, calculating shipping charges (e.g., based on user shipping preference and user address or zip code), $ subtotals for each product (e.g., as quantity×price), and a total purchase amount including a sum of all product subtotals, shipping charges and taxes. The business application 114 may then provide this information to the runtime UI application 118 (e.g., confirming quantity in stock for each product ID, and the calculated shipping charges, subtotals, taxes and total amount due), and the runtime UI application may then provide this information to the client application via an updated user interface 150. Thus, for example, backend processing by business application 114 may be important when runtime UI application 118 needs to provide feedback (e.g., error messages) or other information, such as updated fields (e.g., taxes, shipping amount, total amount) to the client application 122, where such feedback or UI fields must be determined or calculated by business application 114.
However, providing one or more roundtrip communications between the frontend server 116 and backend server 112 during a business transaction may consume significant memory and processing resources on the backend server 112 and frontend server 116, and may consume significant network or communication resources. In addition, some types of business transactions may not require immediate processing by the business application 114, or may not require that immediate feedback be provided to the client application 122 prior to completion of the business transaction. In such cases where business application processing or associated feedback to the client application 122 is not required prior to completion of the business transaction, such business application processing may be delayed or deferred, and frontend-backend communication may be suspended, until after completion of the business transaction.
Therefore, according to an example implementation, frontend-backend communication between runtime UI application 118 on the frontend server 116 and the business application 114 on the backend server 112 is performed before completion of a business transaction when necessary, and such frontend-backend communication is suspended until after completion of the business transaction when it is not necessary for such communication to be performed before completion of the business transaction.
According to an example implementation, runtime UI application 118 may determine, based on nodes and/or attributes provided in a business object 124 corresponding to user interface 150, whether or not processing by business application 114 is required to update one or more fields of user interface 150 before completion of a business transaction. If processing is required by business application 114 to update one or more fields of a user interface before completion of a business transaction, then a round-trip communication may be triggered (e.g., by the runtime UI application 118) between the runtime UI application 118 and the business application 114 so that business application 114 may perform the requested processing and runtime UI application 118 may then output one or more updated fields of user interface 150 to client application 122.
On the other hand, if processing is not required by business application 114 in order to update a field within the user interface before completion of the business transaction, then the runtime UI application 118 may temporarily cease or suspend communications between the runtime UI application 118 and the business application 114 in order to conserve resources. In such case, communication between the runtime UI application 118 and the business application 114 may be resumed after completion of the business transaction (e.g., frontend-backend communication may resume after runtime UI application 118 receives a “submit” request or other request from client application 122 to complete the business transaction). For example, after completion of the business transaction is detected by the runtime UI application 118, the runtime UI application 118 may then forward data inputs received from the client application via the user interface to the business application 114 so that the order, as described by the completed shopping cart user interface 150 submitted to runtime UI application 118 from client application 122, may be processed by business application 114 so that, for example, items purchased by the user may be shipped to the user at the address listed on the user interface.
According to an example implementation, a user interface 150 may be provided from a runtime user interface (UI) application 118 running on a frontend server 116 to a client application 122. The runtime UI application 118 may receive from a business application 114 running on a backend server 112, a business object 124 that includes metadata (e.g., nodes, and fields/attributes) associated with the user interface. The runtime UI application 118 may receive from the client application 122, user input associated with a business transaction, the user input including an input of a first field for the user interface. The runtime UI application 118 may determine based on the business object, whether processing by the business application 114 of the first field input is required to determine and output to the client application 122 an updated second field of the user interface before completion of the business transaction. The runtime UI application 118 may trigger (or cause the occurrence of) a round-trip communication between the runtime UI application 118 and the business application 114 to process the first field and determine the updated second field before completion of the business transaction if the processing is required by the business application 114 to determine and output the updated second field before completion of the business transaction.
Referring to
As also shown in
As shown in
Each of the fields of user interface 150 may have a corresponding attribute within shopping cart business object 124. For example, Name 152, address 154 of user interface 150 correspond to name 132 and address 134, respectively, of shopping cart business object 124. Submit button 170 on user interface 150 corresponds to a submit action 130 of business object 150. Total amount 168 of user interface corresponds to total amount attribute 128 of business object 124. Product ID 156, quantity 158 and subtotal 160 of user interface 150 may correspond to product ID 138, quantity 142 and subtotal 146 of business object 124. Comments field 171 of user interface 150 corresponds to comments 135 of business object 124.
Referring to the business object 124 in
The validation sub-attribute 140 identifies in parentheses the attributes upon which the validation depends, e.g., product ID 138 and quantity 142 in this example, which may be referred to as dependent attributes. This means that validation of the product ID 138 is performed by business application 114 based on the two dependent attributes (product ID 138 and quantity 142). Thus, validation of product ID 138 should be performed if runtime UI application 118 receives (e.g., new or updated) user inputs for product ID 156 and quantity 158 via user interface 150. As noted, product ID 156 and quantity 158 of user interface 150 correspond to dependent attributes product ID 138 and quantity 142 in business object 124. For example, if a use changes a quantity 158 of a product, then validation should be performed again by business application to confirm that the quantity is in stock, for example. Likewise, the calculation sub-attribute 148 identifies in parentheses the dependent attributes upon which the calculation depends, e.g., quantity 142 and price 144. The calculation 148 of subtotal 146 should be performed or re-performed if runtime UI application 118 receives new or changed values for either of the dependent attributes (quantity, price) for the calculation 148. In other words, if a quantity of items or price of an item changes (or is received), the corresponding subtotal 146, 160 will need to be re-calculated.
According to an example implementation, business application 114 may be required to perform validation or calculation only if one of the respective dependent attributes is received or changed (e.g., by a user or by the business application), for example. For example, a user or client application 122 may change a quantity, while business application 114 may change the price of an item. In one example implementation, if a user input is received by runtime UI application 118 for one of the dependent attributes for validation 140 or calculation 148 in the business object, then a round-trip communication between the runtime UI application 118 and business application 114 is triggered to allow business application 114 to perform such validation or calculation. Otherwise, if no such validation or calculation is required before end of the business transaction, e.g., either 1) no validation or calculation sub-attributes present in business object 124, or 2) no inputs or changes have been received to any of the dependent attributes in the business object for such validation 140 or calculation 148 sub-attributes, or 3) user interface 150 does not display any of the validated or calculated values or attributes (e.g., product ID 156 and/or subtotal 160 are not displayed to the user via user interface 150), then communication between the runtime UI application 118 and the business application 114 may be suspended until end of the business transaction. A validation example and a calculation example will be briefly described.
Within the shopping cart business object 124, product ID 138 may include a validation sub-attribute 140 indicating that validation of the product ID 138 by the business application 114 is required prior to completion of the business transaction, according to an example embodiment. As shown in the validation sub-attribute 140, the validation is performed based on two dependent attributes including the product ID 138 and the quantity 142 of item subnode 136. Thus, if a user inputs or changes either quantity 158 (corresponding to quantity 142 in business object 124) and/or product ID 156 (corresponding to product ID 138 in business object 124) via user interface 150, then the runtime UI application 118 may examine the shopping cart business object 124 to determine if any business application processing is required prior to completion of the business transaction based on these changed or input attributes or fields.
Validation sub-attribute 140 indicates that the product ID 138 should be validated (based on input of quantity and/or product ID) or re-validated (e.g., if a new quantity was input by a user) to confirm that the requested quantity of the identified product (identified by the product ID) is in stock. Thus, to do this, a validation request is sent from the runtime UI application 118 to the business application 114, where the validation request may include at least the new or updated user inputs for product ID and quantity. The business application 114 may then search a database, for example, and determine if the quantity of the product is in stock. Business application 114 may then send a reply to the runtime UI application 118 indicating if the quantity of product is in stock or not. If the quantity of the requested product is not in stock, an error message may be forwarded from the business application 114 to the runtime UI application 118, and this error message may be output by the runtime UI application 118 via the user interface to the client application 122.
In a similar manner, a calculation sub-attribute 148 may be provided for subtotal 146, meaning that a calculation or recalculation of the item subtotal 146 by business application 114 should be performed if any of the dependent attributes for calculation 148 (quantity 142, price 144) are received from or changed by a user or client application 122 via the user interface (since the recalculated subtotal 160 is displayed to the user during the business transaction via user interface 150). If the recalculated subtotal 160 was not present in the UI 150 or was not displayed to the user before completion of the business transaction, the backend processing by business application 114 could be delayed until after completion of the business transaction (e.g., continue suspending frontend-backend communications). Thus, for example, if the quantity 142 of products has been changed for this item subnode 136, e.g., by a user inputting or changing the quantity in the corresponding displayed quantity field 158 of the shopping cart user interface 150, then this would cause runtime UI application 118 to determine if any business application processing should be performed based on this change. In this case, the runtime UI application 118 would detect the presence of the calculation sub-attribute 148, and that the quantity 142 is a dependent attribute for calculation 148. Thus, runtime UI application 118 would trigger a roundtrip communication from the runtime UI application 118 and the business application 114 to allow business application 114 to perform the requested calculation of the subtotal based on the received or changed quantity 142 and price 144 for this item subnode 136.
As noted above, changes or inputs by a user may for some fields of a UI may cause runtime UI application 118 to trigger a roundtrip communication with the business application, e.g., to perform processing such as validation or a calculation. However, other changes or input may not necessarily trigger a roundtrip communication between the runtime UI application 118 and the business application 114. For example, a user may input some text in the comments field 171 of the user interface 150. The comments attribute 135 of business object 124 does not have a validation or calculation sub-attribute, in the example business object 124 shown in
The method illustrated in
In the method of
In the method of
The method illustrated in
The method illustrated in
The method illustrated in
The method illustrated in
The method illustrated in
The method illustrated in
Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and 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. A computer program that might implement the techniques mentioned above might be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope of the embodiments.
