Patent Application
20160316038
An application server may let multiple users and/or application session access information in a database simultaneously. For example, a user might access a Grapical User Interface (“GUI”) that displays purchase order information from the database in substantially real time. In some cases, the application server might use a shared memory portion to locally store information (e.g., an object or table) and improve performance. For example, a shared memory infrastructure, such as in an Advanced Business Application Programming (“ABAP”) engine, may be used to cache and/or buffer ABAP entities (e.g., structures, tables, and/or objects) at the application server to speed up the read-access for those entities from an ABAP session residing on the application server. Note that a number of applications may exist that use shared memory entities to exchange data. Moreover, these applications may run on the same or different servers and try to synchronize their content, such as master data, material data, or order entries.
However, an application that has retrieved information from the shared memory infrastructure may be unaware when the information is subsequently updated by another application. That is, the typical exchange of shared memory between different applications is generally based on a kind of “push-and-pull” mechanism. Because the content of shared memory entities can change at any time, and the determined and displayed data based on those entities may be altered frequently, issues may arise wherein both calculated business data and applied functions by end-users to that data (e.g., calculating a total for certain data) are not up-to-date and do not reflect the current data. In an attempt to solve this problem, the affected shared memory entries may be rechecked/re-read frequently. This, however, can lead to increased shared memory and application server access times and loads.
In addition to data inconsistency scenarios, such a limitation may result in an inability to implement new business use-cases (e.g., to display the latest business information on a screen or to initiate a subsequent process or workflow). As a result, improved systems and methods to accuratelly and efficiently access shared memory entities in an application server may be desired.
The following description is provided to enable any person in the art to make and use the described embodiments and sets forth the best mode contemplated for carrying out some embodiments. Various modifications, however, will remain readily apparent to those in the art.
The system 100 may be associated with any query-responsive data source or sources that are or become known, including but not limited to a Structured-Query Language (“SQL”) relational database management system. The system may also be associated with a relational database, a multi-dimensional database, an eXtendable Markup Language (“XML”) document, or any other data storage system storing structured and/or unstructured data. Note that in some embodiments, the system 100 may be distributed among several relational databases, dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources.
Presentation of information to the users 110, 112 may comprise any degree or type of rendering. For example, the system 100 may execute a Web browser to receive a Web page (e.g., in HTML format) from a data server, and may render and present the Web page according to known protocols. The system 100 may also or alternatively present user interfaces by executing a standalone executable file (e.g., an .exe file) or code (e.g., a JAVA applet) within a virtual machine. Note that the system 100 may include any number of clients of one or more types according to some embodiments.
There are a large number of applications that may use the share memory 180, i.e. via export and import ABAP entities to the shared memory 180, or shared objects, to exchange information and to synchronize content. This category includes applications that need fast access to the application server 150 based cache containing entities, i.e., structures, tables, and/or objects. This type of fast access cache may be implemented via the shared memory 180 or shared objects infrastructure.
The typical exchange of shared memory 180 content between different applications, which may even reside on different application servers 150, is usually based on a kind of “push-and-pull” mechanism Because the content of shared memory entities can change at any time, and the determined and displayed data based on those entities may be altered frequently, issues may arise wherein both calculated business data and applied functions by end-users to that data (e.g., calculating a total for certain data) are not up-to-date and do not reflect the current data. In an attempt to solve this problem, the affected shared memory entries may be rechecked/re-read frequently. This, however, can lead to increased shared memory and application server access times and loads.
Further, known infrastructures based on re-checking (using repeated checks) of the status and/or value of the shared memory entities (like shared objects) may establish a status based on a time stamp and/or a version number. As soon as changes are detected, the ABAP messaging channel could be used to notify the sessions and subscribers to the event. With this strategy, the session and application will not get an active notification from shared memory, which still leads to outdated data in a session depending on the frequency of the repeated checks of the shared memory access. This also leads to unnecessary increased consumption of system resources (e.g., network traffic in case of an access to a distributed file system or application server). Note that the total cost of ownership for a polling technology may be much higher as compared to an event-driven technology.
To avoid such a result, some embodiments described herein may include a shared memory messaging channel broker 190 for the database application server. Note that it may be desirable to only re-read the shared memory 180 data when the affected shared memory 180 entities have been modified. Embodiments may provide an event-driven solution, in ABAP, to subscribe to actions, i.e., create, update, and/or delete actions, that are applied to the shared memory 180 entities. According to some embodiment, “shared memory messaging channels” may be provided. In this case, applications may be able to subscribe to future changes that are applied to any shared memory 180 entity. According to some embodiments, each shared memory entity is associated with a channel, e.g., a shared memory entity for “orders” or “catalogs” may assigned to a channel named “/orders” or “/catalogs.” When any action, update, or change occurs to this entity, an event and message with the appropriate meta-data information (e.g., the name of the entity and the applied action) may be transmitted to the sessions that are subscribed to the channel (such as “/catalogs”). After receiving this message, the application can either trigger further actions to process the shared memory 180 entity or trigger an event (such as via an ABAP push channel or a GUI push channel) to display to the end-user 110, 112 the altered status of the affected UI elements (that is, the displayed content from shared memory 180 entity). The changes to a shared memory 180 entity may also lead to changes to the database entities which are in use in different processes, sessions and/or UI elements. Using ABAP channels, some embodiments may combine the shared memory messaging channels with the database messaging channels, the ABAP push channel, the ABAP messaging channel and/or the GUI push channel to expose the shared memory 180 changes to other event technologies in ABAP. Moreover, embodiments may pipe and/or forward the event to other event channels that are subscribed and consumed in session or user interfaces.
Initially, at S210, a shared memory messaging channel broker of a database application server (e.g., an ABAP application server) may receive a first subscription request from a first application session. The first subscription request may be associated with, for example, a first shared memory entity. The first shared memory entity might be associated with, for example, a shared object area, a shared structure, and/or a shared table.
At S220, it may be “automatically” determined that the first shared memory entity has been updated. As used herein, the term “automatically” may refer to an action that is taken with little or no human intervention. The update might be associated with, for example, a read event, a write event, an update event, and/or a delete event. Responsive to the determination at S220, a notification associated with the update may be automatically transmitted to the first application session at S230. According to some embodiments, the notification includes metadata such as a name of the first shared memory entity and/or an action associated with the update.
Note that the process 200 of
The process 200 of
Referring now to
At step 1, the GUI 320 executes transaction <xyz> for the first session 350. As a result, the first session 350 reads <SMx> from a shared memory infrastructure 330 at step 2. Moreover, the first session 350 indicates to a shared memory messaging channel broker 340 that it wants to subscribe to channel </SMx> at step 3, and the shared memory messaging channel broker 340 establishes an active trigger for channel </SMx>at step 4. Note that an affirmative acknowledgement may be returned for both steps 3 and 4. The <SMx> that was read at step 2 may then be used by the first session 350 to create screen output for the GUI 320 at step 5 (showing the business data containing the content <SMx>).
Referring now to
That is, in steps 1 through 5 during execution of the GUI transaction, the content of the shared memory entity <SMx> is read the same shared memory that is then accessed by the browser application in steps 6 through 10. In both cases, the shared memory entity <SMx> is read and either part or the complete shared memory entity <SMx> is accessed in the associated session. In steps 3 and 8, each application subscribed to the shared memory messaging channel “</SMx>” in order to receive notification from the framework as soon as any change is applied to the shared memory entity <SMx>.
Based on the underlying business logic and the represented screen, the end user may be able to update screen elements (such as, for example, by placing an order), that will leads to an update to the shared memory entity <SMx>. For example, referring now to
Beside the scenario of
The apparatus 600 includes a processor 610 operatively coupled to a communication device 620, a data storage device 630, one or more input devices 640, one or more output devices 650, and a memory 660. The communication device 620 may facilitate communication with external devices, such as a reporting client, or a data storage device. The input device(s) 640 may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an Infra-Red (“IR”) port, a docking station, and/or a touch screen. The input device(s) 640 may be used, for example, to enter information into apparatus 600. The output device(s) 650 may comprise, for example, a display (e.g., a display screen), a speaker, and/or a printer.
The data storage device 630 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while the memory 660 may comprise Random Access Memory (RAM).
The data server 632 may comprise program code executed by the processor 610 to cause the apparatus 600 to perform any one or more of the processes described herein. Note that embodiments are not limited to execution of these processes by a single apparatus. The data 634 may include database data and shared memory objects as described herein. As also described herein, such database data (either cached or a full database) and/or shared memory objects may be stored in volatile memory such as the memory 660. The data storage device 630 may also store data and other program code for providing additional functionality and/or which are necessary for operation of the apparatus 600, such as device drivers, operating system files, etc.
Thus, some embodiments may provide a “shared memory messaging channel” is such that a transfer of events and messages from a shared memory infrastructure may be transmitted to sessions or user-agents based on a “publish-subscribe” model. Each shared memory entity may be associated with a channel similar to ABAP messaging channels, e.g., a shared object area “sales_order_entry” may be assigned to a channel named “/sales_order_entry.” As soon as any action is applied to the shared memory entity (e.g., read, write, update, or delete) an event and message with the appropriate meta-data information (e.g., the name of the entity and the applied action) may be transmitted to the sessions or user-agent that are subscribed to that channel.
To achieve this goal, three steps may be taken:
1) For each shared memory entity (e.g., shared object area), a dedicated “shared memory messaging channel” may be defined. For example, changes to the entity “master_data” may be associated with a channel named “/master_data.” The subscription and publication may take place based on the defined “shared memory messaging channel.” Thus, each application can subscribe to Create, Read, Update, Delete (“CRUD”) activities on a specific shared memory entity “master_data” and to its associated shared memory messaging channel (“/master data”).
2) In the shared memory infrastructure, a registration for access (create, read, update, delete) notification to the shared memory entity (“master_data) is established. After successful registration, a message including meta-data, (the applied actions (create, read, update, delete) and the name of the entities) may be sent to the shared memory messaging channel broker.
3) Finally, the shared memory messaging channel broker may forward messages to the subscribers of the shared memory messaging channel (such as the sessions or user-agents who are subscribed to channel “/master data”).
The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein.
All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.
Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.
