An enterprise may use applications to perform business functions. For example, cloud-based applications are increasingly used to process purchase orders, handle human resources tasks, interact with customers, etc. A cloud computing environment may have a Software Development Kit (“SDK” with scripts which can be used to create custom logic, such as the SAP® Advanced Business Script Language (“ABSL”). Using ABSL, a designer can implement, for example, events, validations, and actions that are defined for business objects in a solution. Note that such languages are not just for defining and describing objects but may also be used to create logic itself (and contain everything necessary to implement advanced functionality). Such tools, however, are not for business users or key users but rather professional developers who must learn the syntax of the language, learn the usage of SDK tool, study the underlying business objects and/or architecture, follow a complex deployment process, etc. Hiring external developers can be costly and thus increase the total cost of acquisition of the desired product behavior. Similarly, using external developers can be a time consuming and error prone process. These challenges apply to many existing vendors and/or products with custom logic capability.
It would be desirable to extend business logic for cloud application services in a secure, efficient, and accurate manner.
Methods and systems may be associated with a system to extend business logic for cloud application services. A custom logic user interface may receive, from a user via a flow-based editor, information creating a custom logic business expression (e.g., a determination or a validation) and information about the custom logic business expression may be stored in a custom logic metadata repository. A computer processor of an application service platform may access the custom logic business expression from the custom logic metadata repository and receive an Application Programming Interface (“API”) call from an API consumer. Responsive to the API call, the system may arrange for execution of the custom logic business expression in accordance with information in the custom logic metadata repository and invoke a pre-hook trigger event to call a custom logic service. Standard application logic may then be executed, and a post-hook trigger event may be invoked to call the custom logic service. A result can then be returned from the application service platform to the API consumer.
Some embodiments comprise: means for receiving, by a custom logic user interface from a user via a flow-based editor, information creating a custom logic business expression; means for storing the custom logic business expression in a custom logic metadata repository; means for receiving at an application service platform an API call from an API consumer; means for arranging, by a computer processor of the application service platform, for execution of the custom logic business expression in accordance with information in the custom logic metadata repository; responsive to the API call, means for invoking a pre-hook trigger event to call a custom logic service from the application service platform; means for executing standard application logic at the application service platform; means for invoking a post-hook trigger event to call the custom logic service from the application service platform; and means for returning a result from the application service platform to the API consumer.
Some technical advantages of some embodiments disclosed herein are improved systems and methods to extend business logic for cloud application services in a secure, efficient, and accurate manner.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.
One or more specific embodiments of the present invention will now be described. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
It is very common for customers to want to customize vendor provided cloud application solutions. For example, a customer might want to extend and/or customize vendor delivered entities based on business needs in simple way without getting overridden by subsequent vendor deliveries. Moreover, a business user should be possible to create simple custom logic in an intuitive way (with no or little technical knowledge). It should also be possible to create complex custom logic (e.g., by an expert developer), using any technology of choice, with the minimal overhead on standard delivery. Some embodiments described herein provide an easy-to-use, flow-based custom logic editor to extend business logic using simple modeling tools and expressions.
In some embodiments, a runtime service engine (a custom logic service) is created to evaluate the custom logic model and expressions. For vendor delivered services that provide for the customization and/or extension of business logic, two standard extension points and protocol are described for each microservice to call the custom logic service. The runtime service can also call external services (called external “hooks”) based on configuration information. For example,
According to some embodiments, devices, including those associated with the system 100 and any other device described herein, may exchange data via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The elements of the system 100 may store data into and/or retrieve data from various data stores (e.g., the custom logic metadata repository 110), which may be locally stored or reside remote from the application service platform 150. Although a single application service platform 150 is shown in
An operator (e.g., a database administrator) may access the system 100 via a remote device (e.g., a Personal Computer (“PC”), tablet, or smartphone) to view data about and/or manage operational data in accordance with any of the embodiments described herein. In some cases, an interactive graphical user interface display may let an operator or administrator define and/or adjust certain parameters (e.g., to set up or adjust various custom logic and/or mapping relationships) and/or provide or receive automatically generated recommendations, results, and/or alerts from the system 100. According to some embodiments, the operator may generate instructions to adjust cloud resources (e.g., a number of assigned servers) or set thresholds that, when triggered, may manually or automatically result in an adjustment of cloud resources.
At S210, a custom logic user interface may receive, from a user via a flow-based editor, information creating a custom logic business expression. Examples of such user interfaces are described herein in connection with
At S230, an application service platform receives an Application Programming Interface (“API”) call from an API consumer and arranges for execution of the custom logic business expression (e.g., in accordance with information in the custom logic metadata repository) at S240. Responsive to the API call, the system may invoke a pre-hook trigger event to call a custom logic service at S250. At S260, standard application logic is executed at the application service platform. At S270, the application service platform may invoke a post-hook trigger event to call the custom logic service and a result may be returned from the application service platform to the API consumer at S280.
Thus, embodiments may provide a custom logic tool is based on a flow-based editor, and any business users will be able use the tool. The tool may provide a low code or no code way to create in-application custom logic with no learning curve, no need to install new software, and no need to hire external partner developers to create the desired custom logic. Anyone can write custom logic using simple English phrases such as: total_tax=total_amount*18%, and the creation of such logic does not require a complete understanding of the application's underlying framework. Moreover, embodiments may be technology agnostic such that underlying microservices that need the extended or custom logic can be based on any technology. In addition, embodiments may provide flexibility and use an in-build approach for simple extensions (while also being open to allow for complex extensions based on any external tools or technologies).
According to some embodiments, custom logic is divided into two types of expressions: (1) determinations and (2) validations. For example:
According to some embodiments, key users may specify desired conditions for a determination using a condition block. For example,
If the defined conditions are satisfied, the statements in the determination assignment block will be executed.
{status}=(‘Open’)
According to some embodiments, all entity fields are enclosed in curly braces (e.g., {status}, {id}, etc.). Moreover, some embodiments may support automatic suggest and automatic completions to help users write assignments.
In addition to determination expressions, validation expressions may be used to implement a custom logic where key users can prevent a save (or issue a warning message to end users) during a save in accordance with certain conditions. For example,
According to some embodiments, there are two broad types of custom logic implementations that are supported in the cloud native stack:
Examples of custom logic trigger points may include:
According to some embodiments, there is a design time meta format for expressions that will be stored in the metadata repository service 1324. The custom logic service 1330 listens to the changes in the custom logic entities (via custom logic update events 1340) and transforms and/or pushes the runtime-expression to the business expression service 1350. The custom logic service 1330 abstracts an underlying runtime execution engine (the business expression service 1350 in this case). In some embodiments, it is possible to change the runtime execution engine depending on the need.
The custom logic service 1330 may store the validation and determination by replacing the expressions with an expression identifier (provided by business expression service 1350).
According to some embodiments, a custom logic service 1430 will be called by the application service 1420 at two points called “pre-hook” and “post-hook” points. The pre-hook point may execute the custom determination that would be executed before the standard application logic. The post-hook point may execute the custom logic that would be executed after the standard logic. In the post-hook phase, custom determinations may not be allowed to change any standard attributes (fields) and custom validations are also executed. At (3), the application service 1420 calls the pre-hook custom logic service 1430 API with the complete aggregate data (even if only a child entity, such as item, is changed) and the changed entity information.
At (4), the custom logic service 1430 and a business extension service 1440 execute the pre-hook determination for each changed entity, starting with the leaf entity and then the parent hierarchy. For example, if an item is changed, then first the custom logic is executed on the item and then on the root. At (5), the custom logic service 1430 returns to the applications service 1420 the changed (aggregate) data merged with the changes done by the pre-hook determinations. At (6), the application service 1420 executes the standard custom-logic (determinations and validations).
At (7), the application service 1420 calls the post-hook custom logic service 1430 API with the complete aggregate data (even if only a child entity, such as item, is changed) and the changed entity information. At (8), the custom logic service 1430 and the business extension service 1440 execute the post-hook determination for each changed entity, starting with the leaf entity and then the parent hierarchy. For example, if an item is changed, then first the custom logic is executed on the item and then on the root. At (9), the custom logic service 1430 and the business execution service 1440 execute the custom validations for each changed entities instances. At (10), the custom logic service 1430 returns to the applications service 1420 the changed (aggregate) data merged with the changes done by the post-hook determinations. Note that in
According to some embodiments, external API hooks provide an option where customers can implement custom validations and determinations externally using any external platform (e.g., SAP® AppGyver). From the application's point of view, there will not be any change to the custom logic hooks (pre-hook and po-hook) and custom logic API. However, there an additional message entity may be needed—to connect to an external system embodiments may use a connector service. For example,
The application microservices 1520 then execute post-hook custom logic causing the custom logic service 1530 to call post-hook API for determinations and validations via the connector service 1540 and the extension service 1550. A post-hook result is eventually returned to the application microservices 1520 which can provide a result to the application user interface 1510.
Some embodiments define an API message structure that is used by the external platforms to generate request and response structures for the API. The connector service 1540 may have a special mandatory header-structure that is part of this structure. In addition, the connector service 1540 may provide a unique entity for routing (to match to an external API path). In some embodiments, each application creates two additional message entities—one for the pre-hook and the other for the post-hook. These message entities may have the main entity as embedded object definition. In the metadata definition, a pre-hook message entity may have an attribute (called body) that refers to an SAP® Opportunity service entity. The pre-hook and post-hook message entities may also be defined in the same service (e.g., Opportunity). Such an approach may provide additional flexibility when an application wants to have reduced structure to pass to the external hooks (e.g., for security or data protection reasons). Also, this technique may not need special handling by the connector service 1540 and may have additional requirements associated with the repository service: the repository service should be able to provide the pre-hook and post-hook message entities based on the main entity; it should be possible to filter out the pre-hook and post-hook entities (e.g., when they should not be displayed); metadata to store an external API (e.g., trigger type, message entity, entity, API Path, communication configuration, etc.).
Other embodiments may use the main entity (e.g., Opportunity) to generate the pre-hook and post-hook messages on demand. In this case, the connector service 1540 may provide a customized method for the pre-hook and post-hook calls for specialized routing for the pre-hook and post-hooks.
Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 1610 also communicates with a storage device 1630. The storage device 1630 can be implemented as a single database, or the different components of the storage device 1630 can be distributed using multiple databases (that is, different deployment data storage options are possible). The storage device 1630 may comprise any appropriate data storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 1630 stores a program 1612 and/or custom logic engine 1614 for controlling the processor 1610. The processor 1610 performs instructions of the programs 1612, 1614, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1610 may receive, from a user via a flow-based editor, information creating a custom logic business expression (e.g., a determination or a validation). The processor 1610 may store information about the custom logic business expression and receive an API call from an API consumer. The processor 1610 may then arrange for execution of the custom logic business expression. Responsive to the API call, the processor 1610 may invoke a pre-hook trigger event to call a custom logic service. Standard application logic may then be executed, and a post-hook trigger event may be invoked by the processor 1610 to call the custom logic service. A result can then be returned from the application service platform to the API consumer.
The programs 1612, 1614 may be stored in a compressed, uncompiled and/or encrypted format. The programs 1612, 1614 may furthermore include other program elements, such as an operating system, clipboard application, a database management system, and/or device drivers used by the processor 1610 to interface with peripheral devices.
As used herein, data may be “received” by or “transmitted” to, for example: (i) the platform 1600 from another device; or (ii) a software application or module within the platform 1600 from another software application, module, or any other source.
In some embodiments (such as the one shown in
Referring to
The custom logic business expression identifier 1702 might be a unique alphanumeric label or link that is associated with logic define by a user via a user interface. The expression type 1704 might indicate, for example, whether the custom logic business expression is a determination or validation and the name 1706 might describe the purpose behind the logic. The trigger condition 1708 are the set of rules that define when the custom logic expression is satisfied, and the assignment or action 1710 indicates what steps will be performed when the trigger condition 1708 is satisfied.
Thus, embodiments may provide an easy to learn, intuitive, and interactive user interface and experience. Business users may use a simple, model-based editor to build conditions and/or expressions. Some embodiments also provide an advanced mode where one can freely type in the expressions. The model-based editor may offer field and/or attribute selection dropdown menus where one can select the desired field, an operator dropdown menu to select the desired operator, selection of a target constant value or field using the dropdown menus, etc.
Embodiments may also let a user bring external logic to make use of third-party tools and create custom functions and/or logic using any language. The system may invoke/call these third-party validations and/or determinations using external hooks. For example, a user might build a lambda function to calculate the pricings/discount based on complex conditions in a third-party tool and hook the same in the cloud using custom logic external hooks functionality. During normal business operations and instance save, a payload is sent to third party tool for execution of custom function—the returned result/payload is again processed by a custom logic service and sent back to the respective application. In this way, a customer can create custom logic using any third-party vendor tools and execute the synchronous custom logic outside the cloud infrastructure.
Some embodiments create in-application validations and determinations from external calls and/or create reusable packages. Embodiments may expose design time APIs to create these in-application custom logic expressions. Third-party tools having integrations/synergy can create these in-application validations and/or determinations out-of-the-box without making customers login and manually create the custom logic. This is also useful to create any reusable package which is common to a particular set of customers or the whole industry. For example, partners or third-party tools or vendors can create a set of custom logic expressions which common for many customers and deploy it to many desired customers and landscape with a single click and push operation.
Embodiments may also provide an immediate/instant application of custom logic. Unlike traditional custom logic tools (which has its own deployment process), custom logic created in accordance with some embodiments will be applicable instantly. One can test the changes almost immediately and can perform the desired corrections if required. This may reduce time provide agility during the custom logic creation process.
Moreover, some embodiments may execute in same Logical Unit of Work (“LUW”). The custom logic may run in the same LUW session (e.g., in a synchronous call) during a business instance save. This helps makes sure that consistency is maintained during the end user interactions with the business data and/or instance. Only those sets of business data which pass the custom validations are allowed to be saved (and others will be rejected with a custom message set by the administrator). Determinations can ensure that certain field values are pre-populated (or imposed) thereby enforcing certain business processes and/or decisions.
The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some of the data associated with the databases described herein may be combined or stored in external systems). Moreover, although some embodiments are focused on particular types of logic expressions, any of the embodiments described herein could be applied to other types of logic. Moreover, the displays shown herein are provided only as examples, and any other type of user interface could be implemented. For example,
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.