Patent Application
20250103406
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
One increasing trend in computing is the use of software applications hosted at a location remote from the user. Such cloud computing offers convenience by not making access to the software dependent upon the user's physical location.
Another increasing trend in computing, is the use of services. That is, procedures not confined to one particular software application (a conversion between currencies, for example) may be implemented as an outside service, rather than being embedded within the software application itself. Such a service-based architecture can reduce cost by allowing the reuse of code across various different software applications.
Embodiments facilitate deployment of customized code at a local site, for reference by a service that is being called by a remote system. At a design time, a visual code editor (e.g., Blockly) is utilized to create and store customized code at the local site. During a subsequent runtime, in response to dispatched service call initiated by the remote system, the customized code is retrieved and executed at the local site. By maintaining the customized code locally, embodiments may confer security and avoid congestion associated with having the customized code stored remotely (with the remote system). This selective dispatch of a service call for handling by the local customized code, can be implemented based upon an extension scheme.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of various embodiments.
Described herein are methods and apparatuses that implement access to services in connection with cloud systems. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of embodiments according to the present invention. It will be evident, however, to one skilled in the art that embodiments as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
The software application includes logic 106 that is configured to reference 108 a cloud system 109 that is remote 111. The software application further includes a service 110.
During a design time 112, a developer 113 seeks to create code relating to the service, that is customized to the needs of a particular user 114. Accordingly, the developer interacts 116 with a visual coding interface 118 that is provided by a localization engine 120. As described below in an example, one possible visual coding interface that may be used, is the Blockly interface available from Google.
In particular, the developer creates customized code 124 that implements the service in a manner specifically desired by the user. The visual coding interface stores 125 the user-customized code within a database 126 that is present within non-transitory computer readable storage medium 128.
Next, during a runtime 130, the user seeks to instruct the software application to perform processing that involves the service. The application receives user instruction 132, and based upon the program logic references the remote cloud system.
The remote cloud system informs the application that the service is involved in the requested processing. Accordingly, the program logic executes the service.
The service in turn contacts a dispatcher 136. The dispatcher recognizes the service request 138 as implicating user customized code. This recognition may be based upon an extension 139 that identifies the particular service being called.
Accordingly, the dispatcher dispatches the service request to the localization engine. Based upon a context 142 including a timer 144, a loader 146 of the localization engine retrieves 147 the code from the underlying database.
Then, an executor 148 of the localization engine executes the customized code. The executor sends the outcome back to the service. The ultimate result 150 of processing of the user's instruction (e.g., by the service according to the customized code), is then ultimately returned to the user.
At 204, code is loaded at the first location. At 206, the code is executed at the first location.
At 208, an outcome resulting from execution of the code is communicated for processing with reference to a system remote from the first location.
Further details regarding service access by cloud systems according to various embodiments, are now provided in connection with the following example. In this particular example, access to a service is implemented with a number of components that are available from SAP SE of Walldorf, Germany, including but not limited to:
This specific example relates to implementation of the SAP Variant Configuration and Pricing Service (CPS) in connection with user-customized code that is executed locally. This CPS service offers a customized pricing procedure that is used to calculate prices while creating a sales quotation.
In particular, the SAP offers a library of predefined variant functions, which may be implemented on the front or back end without involvement by a customer. Examples can include but are not limited to:
However, in performing SAP CPS customers may seek to utilize one or more of their own, customized variant function(s)—rather than those predefined by SAP. Accordingly, this example offers a SAP customer the ability to generate customized code for local execution in conjunction with SAP CPS. Such local code execution improves performance, by reducing communication bottlenecks otherwise arising due to frequent attempted contacts with the remote SAP backend cloud system.
This particular example utilizes a No Code visual coding development environment based on the Google Blockly library. The example generates the custom Javascript code from the No Code editor.
The custom Javascript code is securely executed within a sandboxed JVM script engine. This example generates custom script/macros from a Visual Coding, and executes the generated code directly (with a scripting engine inside CPS).
The bottom of
Embodiments manage interaction with the graal.js engine and ensure proper and secure configuration. Various components of the localization engine are now described.
GraalVM Polyglot Engine 306. This provides at least the Scripting Engine and the Context API. The latter allows execution of evaluated code.
Context 308 with Timer 310. In order to enforce a runtime limit for the execution of No Overhead extension, the SAP Variant Configuration and Pricing service executes the evaluated code inside a Future Task with a timeout.
Bindings 312 between Java Service and Javascript runtime. These support the customer Javascript code calling the APIs provided by the Variant Configuration and Pricing service. Examples are:
Code Loader 318. This loads the code archive from the database and converts it into GraalVM Sources.
Extension API 320. This supports the execution of an extension function and can be called by the Dispatcher 322.
Details regarding the development environment according to this example, are now discussed in connection with
In order to ensure trusted code, in addition to secure Runtime environment, a low-code like modelling environment has been developed. This can be imported as .vsx extension into Microsoft vscode and BAS. BAS may be desirable insofar as it provides further capabilities like project wizard and a simplified git integration.
The extensions may comprise one or more components, including but not limited to:
The modelling extension in BAS and vscode can interact with the Variant Configuration and Pricing Service via dedicated endpoints. These endpoints allow the deployment of code/model onto the service (Deploy API) as well as performing tests by executing individual extension functions (Runtime API).
A technical description of the functional calls/flow for dispatching, is now provided. In the event that extensions are activated but detailed runtime specification for each extension function are not available, the dispatching process may exhibit a hybrid mode.
Therefore, if the customer actives both remote extensions and the localized custom code (e.g., if the remote extension is required because of limitations of the local extension), the service tries both runtimes, starting with the Scripting Engine. The service uses the first runtime that can process the extension function. A specific code may be provided to distinguish this circumstance from error situations.
As shown in
The highlighted columns show the mapping of steps in the price calculation to the different types and implementations of extension. For example, step 30 would execute BAS_990 in the SAP (Variant Configuration and) Pricing Service.
These extensions may be implemented either as an external webservice, or as a local extension. In
According to one example use case, a customer would like to overturn the condition value calculation in pricing and include a special rounding procedure. Under this customization, the given condition value is rounded and the value of 0.01 per given quantity is subtracted from it.
A performance comparison was made as follows. In order to improve the performance of the remote extensions, caching has been introduced into the Variant Configuration and Pricing Service. This caching caches identical calls to the remote service.
Since most of the extension implementations do not depend remote data but use the provided data only, identical calls can be detected by analyzing the input data for the extension.
Since caching would equalize the difference between local and remote extension, caching was disabled to be able to compare local vs. remote extensions only. The results are summarized in the table below.
More details are illustrated in the screenshots of
In the “Services” section of
By contrast,
It is noted that the enterprise edition of the GraalVM scripting engine provides various sandbox options useful for security. However, other editions (e.g., community) of graal.js (GraalVM Javascript) may only support limiting the number of statements.
Thus, this particular example applies a timeout to each script execution to protect the BTP service from misuse. This timeout involves a context and timer, as are shown in
Access to services afforded according to various embodiments, may offer one or more benefits. Specifically, one possible benefit is reduced communication/overhead, by allowing execution of custom code on/inside the service.
Another possible benefit is security. Embodiments may also address possible security challenges for at least one or more of the following levels:
For model development, in order to maintain control over the customer code, this example uses a visual programming approach. The visual programming editor is based on the Google Blockly library. This allows the addition of custom blocks, and can also be extended and modified with plugins.
Blockly provides a library of blocks that support the creation of general programs. This particular example further provides a supplemental library of blocks specifically for the creation of extensions for the Variant Configuration and Pricing Service.
These supplemental blocks ensure that the model fulfills the API contract (the specification re: how to create extensions). For example, there are specific blocks for the process_formula and collect_attributes methods, which are implemented by an extension with the required input and output values.
A possible advantage of the modelling approach (as compared to direct code upload to the cloud), is that the modelling approach follows a white-list approach (only the SAP Blocks are allowed and available). By contrast, a code upload approach would follow a blacklist (e.g., prevent inclusion of certain libraries are execution of certain statements).
Blockly also allows to limit the total number of blocks used in a model, as well as limiting the number of instances of a specific block. The latter is used by the Variant Configuration and Pricing Service to ensure that an extension model contains only one process_formula and one collect_attributes block.
Embodiments provides a model editor based on Blockly as an extension for BAS and the vscode from Microsoft as shown in
Code generation in this example is now discussed. The models are converted into code before execution by the scripting engine. The code generation belongs to the blocks, and is therefore delivered and under full control.
Since embodiments execute the code with the graal.js API, and Blockly already provides plain JavaScript code generators for it block library, the models for Variant Configuration and Pricing will be converted into JavaScript code as well.
Embodiments generate and manage the code internally, so that a customer cannot access and modify the generated code. To support testing on the developer's machine, embodiments may also provide specific generators that do not depend on functionality that is only available in the service environment.
The code generation of this example also allows including additional cross-cutting statements into the generated code. An example is statements that limit number of iterations in a loop and log information to improve supportability.
Runtime security is now discussed. This particular example uses the graal.js engine and also supports the JSR-223 Script Engine API.
Embodiments instantiate and manage the scripting engine. This allows the implementation of a timeout control mechanism as is described later below.
Embodiments allow the implementation of additional monitoring capabilities (e. g. number of calls or runtime measurement). These monitoring capabilities can be exposed to the administration of the Variant Configuration and Pricing Service
In the secure by default state, the generated JavaScript code cannot access the Java environment. However, graal.js supports a whitelisting approach for the Java-JavaScript interoperability. In this mode, only explicitly released methods of Java objects are accessible from within the scripting engine.
Returning now to
Rather, alternative embodiments could leverage the processing power of an in-memory database engine (e.g., the in-memory database engine of the HANA in-memory database available from SAP SE), in order to perform one or more various functions as described above, including but not limited to:
Thus
In view of the above-described implementations of subject matter this application discloses the following list of examples, wherein one feature of an example in isolation or more than one feature of said example taken in combination and, optionally, in combination with one or more features of one or more further examples are further examples also falling within the disclosure of this application:
An example computer system 1200 is illustrated in
Computer system 1210 may be coupled via bus 1205 to a display 1212, such as a Light Emitting Diode (LED) or liquid crystal display (LCD), for displaying information to a computer user. An input device 1211 such as a keyboard and/or mouse is coupled to bus 1205 for communicating information and command selections from the user to processor 1201. The combination of these components allows the user to communicate with the system. In some systems, bus 1205 may be divided into multiple specialized buses.
Computer system 1210 also includes a network interface 1204 coupled with bus 1205. Network interface 1204 may provide two-way data communication between computer system 1210 and the local network 1220. The network interface 1204 may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links are another example. In any such implementation, network interface 1204 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
Computer system 1210 can send and receive information, including messages or other interface actions, through the network interface 1204 across a local network 1220, an Intranet, or the Internet 1230. For a local network, computer system 1210 may communicate with a plurality of other computer machines, such as server 1215. Accordingly, computer system 1210 and server computer systems represented by server 1215 may form a cloud computing network, which may be programmed with processes described herein. In the Internet example, software components or services may reside on multiple different computer systems 1210 or servers 1231-1235 across the network. The processes described above may be implemented on one or more servers, for example. A server 1231 may transmit actions or messages from one component, through Internet 1230, local network 1220, and network interface 1204 to a component on computer system 1210. The software components and processes described above may be implemented on any computer system and send and/or receive information across a network, for example.
The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as defined by the claims.
