Patent Description:
Enterprise applications may be architected as distributed applications that leverage a mesh of software services called a service mesh. In such applications, each service is an independent software component that includes code and data used to execute complete and discrete functionality (e.g., record error logs). Services use common interface standards and can be communicated with over a network (e.g., Internet) using standard communication protocols. The services in a service mesh may be deployed on-premise and/or in the cloud. A service can be integrated into another service, which can be referred to as service integration. For example, a first service can consume data and/or functionality of a second service. Consequently, the second service can be integrated into the first service to provide, for example, a user interface (UI) of the second service within that of the first service and to enable automatic communication between the first service and the second service.

In some instances, services offered by a software vendor typically have pre-defined integration scenarios. In some examples, an integration scenario is a service integration that provides a desired combination of functionality and/or data of different services. Typically, pre-defined integration scenarios are provided by the software vendor in response to an analysis of common needs (e.g., among customers of the software vendor), competitive offerings, and/or product strategy considerations. While a number of service integrations can be pre-defined, not all combinations of service integrations can be contemplated and, in any case, may be impractical to pre-define given technical constraints. For example, some service integrations are not of broad interest to consumers of a service-based application, such that the technical expenditures in generating the service integrations are not worthwhile. In any case, it is infeasible to provide all potential integrations due to the exponential number of possible service integrations and overwhelming consumers to find the service integrations they need among so many theoretically possible service integrations.

On the consumer side, if consumers want to implement their own particular service integrations that are absent from the pre-defined service integrations, manual work and technical expense of the consumers are required. For example, the user interfaces (UIs) of multiple, non-integrated services are used independently and common data is written to each UI and/or is copied from one UI to another by the consumer. This not only reduces the overall perception of integration and user-friendliness; it increases consumption of technical resources. For example, a respective, independent session is required for each service and actions of copying and pasting data consume technical resources (e.g., memory, processing, bandwidth). Further, while a consumer may want to implement their own service integrations, this is a lengthy and costly process, in terms of technical resources, that can only be done by information technology (IT) integration experts.

Document <CIT> discloses a method, device and computer program product. The method is under control of one or more processors and includes program instructions to perform resource context awareness (RCA). The method accesses an active destination resource at a computing device, matches the active destination resource to a resource context of interest (COI) from an RCA transfer library and transfers an outbound resource advancement (RA) content segment stored in memory of the computing device to the active destination resource based on the resource COI from the RCA transfer library.

Document <CIT> discloses an apparatus and methods for extending services of a user device that include identifying a first application resident on a user device having a first service that utilizes a first data type. Further, the apparatus and methods include identifying a second application of a plurality of applications having a second service that utilizes a second data type. Additionally, the apparatus and methods include matching a compatibility of a selected one of the first service or the first data type of the first application with a respective one of the second service or the second data type of the second application.

Document <NPL>, relates to a technology that allows embedding and linking to documents and other objects.

The invention is defined by the method having the features disclosed in claim <NUM>, by the medium having the features disclosed in claim <NUM>, and by the system having the features disclosed in claim <NUM>.

Implementations of the present disclosure are directed to a service integration platform to automatically identify and suggest service integrations and to automatically integrate services. More particularly, implementations of the present disclosure are directed to a service integration platform that monitors user actions to detect potential integration of services, suggest a service integration to a user, and to automatically integrate the services.

In some implementations, actions include receiving, by an integration extension engine (IEE) and from a target service, user action metadata and target information, the user action metadata representing an action of a user to the target service, determining, by the IEE, that an integration recommendation is to be issued to the source service at least partially in response to the user action metadata, the integration recommendation recommending a service integration of the target service with the source service; and automatically executing, by the IEE, integration of the target service with the source service by calling an extension framework to generate an extension, the extension being installed in the source service, and calling a configuration framework to configure the source service having the extension installed therein, wherein, in response to the service integration, a user interface of the source service is populated with one or more fields of a user interface of the target service. Other implementations of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or more of the following features: the action of the user includes a paste action executed to paste data for processing by the target service, the data being copied from the user interface of the source service; at least a portion of the user action metadata includes a user identifier that identifies the user, a service identifier that identifies the source service, and at least a portion of the target information comprises a service identifier that identifies the target service; determining, by the IEE, that an integration recommendation is to be issued to the source service at least partially in response to the user action metadata includes processing at least a portion of the user action metadata through a set of rules that comprises one or more of a rule that triggers an integration recommendation in response to the user executing a number of actions that exceeds a threshold number, a rule that triggers an integration recommendation in response to the user executing a number of that exceeds a threshold number within a given timeframe, and a rule that triggers an integration recommendation in response to determining that the integration had not been previously presented to the user; actions further include notifying the user of the integration recommendation, and receiving, by the IEE, user input indicating acceptance of the integration recommendation, wherein automatically executing, by the IEE, integration of the target service with the source service is in response to the user input; actions further include notifying a set of users of the integration recommendation, the user being included in the set of users; and, in response to the service integration, the one or more fields of the user interface of the target service are automatically populated with data provided by the source service.

The present disclosure also provides a computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided herein.

The present disclosure further provides a system for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with implementations of the methods provided herein.

It is appreciated that methods in accordance with the present disclosure can include any combination of the aspects and features described herein. That is, methods in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

Implementations of the present disclosure are directed to a service integration platform to automatically identify and suggest service integrations and to automatically integrate services. More particularly, implementations of the present disclosure are directed to a service integration platform that monitors user actions to detect potential integration of services, suggest a service integration to a user, and to automatically integrate the services. In some examples, integration of the services results in a user interface (UI) of a first service having at least a portion of a UI of a second service integrated therein, and an extension being provided in the first service to enable direct communication between the first service and the second service. As described in further detail herein, the service integration of the present disclosure can be described as a no-code approach, in which services are integrated without coding being generated by a consumer (e.g., user) of the services and reduced consumption of technical resources relative to manually providing the service integration.

Implementations can include actions of receiving, by an integration extension engine (IEE) and from a target service, user action metadata and target information, the user action metadata representing an action of a user to the target service, determining, by the IEE, that an integration recommendation is to be issued to the source service at least partially in response to the user action metadata, the integration recommendation recommending a service integration of the target service with the source service; and automatically executing, by the IEE, integration of the target service with the source service by calling an extension framework to generate an extension, the extension being installed in the source service, and calling a configuration framework to configure the source service having the extension installed therein, wherein, in response to the service integration, a user interface of the source service is populated with one or more fields of a user interface of the target service.

To provide further context for implementations of the present disclosure, and as introduced above, enterprise applications may be architected as distributed applications that leverage a mesh of software services called a service mesh. In such service-based applications, one or more services can be integrated into another service, which can be referred to as service integration. For example, a first service can consume data and/or functionality of a second service. Consequently, the second service can be integrated into the first service to provide, for example, a UI of the second service within that of the first service and to enable automatic communication between the first service and the second service.

In view of the above context, implementations of the present disclosure provide a service integration platform that monitors user actions to detect potential integration of services, suggest a service integration to a user, and to automatically integrate the services. The service integration of the present disclosure can be described as a no-code approach, in which services are integrated without coding being created by a consumer (e.g., user) of the services and reduced consumption of technical resources relative to manually providing the service integration (e.g., through coding by an IT integration expert).

<FIG> depicts an example architecture <NUM> in accordance with implementations of the present disclosure. In the depicted example, the example architecture <NUM> includes a client device <NUM>, a network <NUM>, and a server system <NUM>. The server system <NUM> includes one or more server devices and databases <NUM> (e.g., processors, memory). In the depicted example, a user <NUM> interacts with the client device <NUM>.

In some examples, the client device <NUM> can communicate with the server system <NUM> over the network <NUM>. In some examples, the client device <NUM> includes any appropriate type of computing device such as a desktop computer, a laptop computer, a handheld computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or an appropriate combination of any two or more of these devices or other data processing devices. In some implementations, the network <NUM> can include a large computer network, such as a local area network (LAN), a wide area network (WAN), the Internet, a cellular network, a telephone network (e.g., PSTN) or an appropriate combination thereof connecting any number of communication devices, mobile computing devices, fixed computing devices and server systems.

In some implementations, the server system <NUM> includes at least one server and at least one data store. In the example of <FIG>, the server system <NUM> is intended to represent various forms of servers including, but not limited to a web server, an application server, a proxy server, a network server, and/or a server pool. In general, server systems accept requests for application services and provides such services to any number of client devices (e.g., the client device <NUM> over the network <NUM>).

In some implementations, the server system <NUM> hosts a set of services, each service is an independent software component that includes code and data used to execute complete and discrete functionality (e.g., record error logs). Services use common interface standards and can be communicated with over a network (e.g., Internet) using standard communication protocols. In some examples, the user <NUM> interacts with multiple services through the client device <NUM>. For example, the user <NUM> can interact with a first service through a first UI that is displayed by the client device <NUM> and can interact with a second service through a second UI that is displayed by the client device <NUM>. In some examples, the first service and the second service are not integrated and the user <NUM> interacts with the first service and the second service as independent services.

In accordance with implementations of the present disclosure, the server system <NUM> can host a service integration platform to automatically identify and suggest service integrations and to automatically integrate services. For example, and as described in further detail herein, the service integration platform monitors interactions of the user <NUM> with the first service and the second service and, in response to one or more interactions, also referred to herein as user actions, the service integration platform recommends a service integration to integrate the first service and the second service. In some examples, in response to user acceptance of the service integration, the service integration platform automatically executes integration of the first service and the second service. In some examples, and as described in further detail herein, integration of the services results in a UI of a first service having at least a portion of a UI of a second service integrated therein, and an extension being provided in the first service to enable direct communication between the first service and the second service.

<FIG> depicts an example conceptual architecture <NUM> in accordance with implementations of the present disclosure. The example conceptual architecture <NUM> is representative of a service-based application that leverages functionality of one or more services in the execution of one or more processes. In the example of <FIG>, the example conceptual architecture <NUM> includes a service integration platform <NUM>, an application user interface (UI) <NUM>, a first service UI <NUM>, a first service <NUM>, a second service UI <NUM>, and a second service <NUM>. In accordance with implementations of the present disclosure, the service integration platform <NUM> includes an IEE <NUM> and an action metadata store <NUM>. As described in further detail herein, the IEE <NUM> is responsive to user actions to the second service <NUM> from the application UI <NUM> to trigger automated service integration.

In further detail, the application UI <NUM> enables users, such as the user <NUM>, to interact with a service-based application through a computing device, such as the computing device <NUM>. In the example of <FIG>, the service-based application leverages functionality of the first service <NUM>. For example, the application UI <NUM> includes the first service UI <NUM>, which enables the user <NUM> to directly input data to and/or receive data from the first service <NUM>. In the example of <FIG>, the user <NUM> interacts with the second service <NUM> through the second service UI <NUM>. In some examples, the user <NUM> establishes a first session with the first service <NUM> and a second session with the second service <NUM>, the first session being separate and distinct from the second session. In some examples, the first session and the second session are separately authenticated. In some examples, single-sign on (SSO) is configured, such that a shared security session is established by the browser with an identity management system, which is also used to log onto the second session. In the depicted scenario, the second service <NUM> is not integrated with the service-based application. For example, for certain functionality that the second service <NUM> provides, data from the first service <NUM> is required. Here, the first service <NUM> can be referred to as a source, because the first service <NUM> is the source of the data, and the second service <NUM> can be referred to as the target, because the second service <NUM> is to consume the data of the first service <NUM>.

The user <NUM> retrieves the data from the first service <NUM> through the first service UI <NUM>. In some examples, the data is displayed in the first service UI <NUM>, but the user <NUM> needs to perform some action to make the data available for use within the second service UI <NUM>. For example, the user <NUM> can view the data displayed in the first service UI <NUM> and re-type the data into the second service UI <NUM>. More commonly, however, users execute a copy action (or cut action) and a paste action for semi-automated copying of the data from one UI to another UI, in this case, from the application UI <NUM> (the first service UI <NUM>) to the second service UI <NUM>. In this manner, typographical errors that typically occur with re-typing data can be avoided and completeness of the data can be ensured.

In accordance with implementations of the present disclosure, and as described in further detail herein, actions that are executed to copy data provided from a source (e.g., the first service <NUM>) and paste data to a target (e.g., the second service <NUM>) can trigger automated service integration. For example, and as depicted in <FIG>, the second service <NUM> is not integrated with the service-based application. Instead, the user <NUM> interacts with the second service <NUM> in parallel with interacting with the first service <NUM>. In response to action of the user <NUM> (e.g., pasting data into the second service UI <NUM>), the IEE <NUM> is triggered to suggest that the second service <NUM> be integrated and, pending approval of the user <NUM>, automatically execute the service integration.

In further detail, in response to the action of the user to the second service UI <NUM>, the second service <NUM> notifies the IEE <NUM>. For example, the second service <NUM> includes functionality that is responsive to the paste action to send action data representative of the paste action to the IEE <NUM>. In some examples, the data pasted into the second service UI <NUM> (the pasted data) is associated with metadata that identifies the first service <NUM> as the source of the data. The second service <NUM> can include an application programming interface (API) end-point that can be used to automatically call the code behind the screen (e.g., the Open Data Protocol (oData) API used by the second service UI <NUM>).

In further detail, when the data is copied, the application UI <NUM> (the first service UI <NUM>) is configured to provide a data set that includes the data and metadata that represents the first service <NUM> as the source of the data. In some examples, the first service UI <NUM> interacts with a clipboard function of an operating system (OS) executed by the client device <NUM>. In some examples, the clipboard function enables selection of metadata to include with any data that is copied to the clipboard, which metadata can be read by a target service (if so configured) as described in further detail herein. In some examples, the metadata can include, without limitation, a data structure of the data, a path to the data (e.g., a uniform resource locator (URL) of the date) and a location of the first service <NUM>, which the data is copied from (e.g., a URL of the first service <NUM>). More particularly, the metadata can include a data model of the data, field-name(s) (e.g., of field(s), from which the data is copied), field-data-type(s), type of data object (DO) node (e.g., DO-node-type), and the selected data key (e.g., universally unique identifier (GUID) of the DO (DO-ID), set of key fields). In some examples, the data set also includes an identifier of the user (user-id) and an identifier of the first service <NUM> (service-id). The second service UI <NUM> is configured to be responsive to data sets that include such metadata. In some examples, in response to the data set being pasted into the second service UI <NUM>, the second service UI <NUM> is configured to determine that the data is associated with metadata, extracts the metadata, and stores the metadata. However, only the data that is copied from the first service UI <NUM> is pasted into respective fields of the second service UI <NUM> (i.e., the metadata is not pasted into any fields of the second service UI <NUM>).

In this example, the first service <NUM>, and thus, the first service UI <NUM>, and the second service <NUM>, and thus, the second service UI <NUM> are configured for automated service integration of the present disclosure. If the data is copied from a service UI that is not configured for automated service integration, metadata as described herein is not included in a data set with the data. If the data is pasted into a service UI of a service that is not configured for automated service integration, the metadata, if any, is ignored and data is pasted into respective fields of the service UI.

In some implementations, the second service <NUM> receives the metadata and transmits the metadata and information on the paste target to the IEE <NUM>. In some examples, the paste target is the second service UI <NUM> and/or the second service <NUM> or portions of each. In some examples, the information on the paste target includes, without limitation, the user-id, the service-id of the second service <NUM>, associated API/screen to call, and timestamp of paste action. In some examples, the second service <NUM> provides a data set that includes the metadata, the user-id, and the service-id resulting from the copy action within the first service UI <NUM>, and the paste information resulting from the paste action within the second service UI <NUM>.

In some implementations, the IEE <NUM> receives the data set from the second service <NUM> and processes the data set to determine whether an integration recommendation is to be provided. In some examples, the IEE <NUM> can execute a set of rules that define circumstances, under which an integration recommendation is to be provided. For example, the set of rules can include a rule that triggers an integration recommendation in response to a user executing a number of copy-paste-actions that exceeds a threshold number. As another example, the set of rules can include a rule that triggers an integration recommendation in response to a user executing a number of copy-paste-actions that exceeds a threshold number within a given timeframe (e.g., a session, X minutes within a session). In some examples, the set of rules can include a rule that triggers an integration recommendation in response to determining that the integration had not been previously presented to the same user (e.g., at all, within a threshold time since an integration recommendation had been made).

In some examples, one or more rules can also determine whether the received metadata is sufficient to actually generate an integration (e.g. that an API is provided, the URL to call is provided, metadata is sufficient to compute data extraction and mapping to the API demands). In some examples, the metadata is determined to be sufficient, if it includes at least user-id, DO-ID, field name of the DO displayed in the field of the US, and the API of the service to call to read the DO.

In some implementations, copy-paste actions of multiple users can be taken into consideration in determining whether to recommend a service integration. For example, copy-paste actions are recorded for multiple users across multiple source UIs and target UIs. For a given target UI (e.g., the second service UI <NUM>), the paste-actions are evaluated to compute a superset of fields copied per source UI (e.g., the first service UI <NUM>). Upon recommending a service integration, the superset of fields is shown in the recommendation, and which fields to pre-fill. In some examples, additional information can provided with the recommendation (e.g., how often each field had been copied by users in the user group). In some examples, a ranking can be provided for each field. For example, priority <NUM> - personally used by the user that the integration recommendation was triggered for, priority <NUM> - frequently used often (by many users), and priority <NUM> - not used often (e.g. because too short and can quickly be typed) but data type and domain matches (e.g. paste from factory ID to factory ID).

<FIG> depicts details of the IEE <NUM> in accordance with implementations of the present disclosure. In the example of <FIG>, the IEE <NUM> includes a wizard module <NUM>, a recording module <NUM>, a suggestion module <NUM>, and a generator module <NUM>. In some examples, each of the wizard module <NUM>, the recording module <NUM>, the suggestion module <NUM>, and the generator module <NUM> is provided as one or more computer-executable programs executed by one or more computing devices (e.g., servers). In the example of <FIG>, the action metadata store <NUM> is depicted and includes a paste action metadata store <NUM> and a generated integration metadata store <NUM>.

As described in further detail herein, the IEE <NUM> records user copy-paste actions by being notified by a target service (e.g., the second service <NUM>), in instances where a user pastes data that had been copied from a source service (e.g., the first service <NUM>). In response to a set of copy-paste actions, as triggered by the set of rules, the IEE <NUM> recommends an integration and notifies the source service to bring the integration recommendation to the attention of the user. The IEE <NUM> supports users with a guided learning approach to capture additional fields, if any, that are to be pre-filled as part of the service integration. In response to the user accepting creation the service integration, the IEE <NUM> configures the service integration by, among other actions, calling existing frameworks for extension and destination management.

In further detail, the wizard module <NUM> is configured to provide a set of prompts (e.g., in the first service UI <NUM>) to guide the user through the actions to specify fields that are to be pre-filled as part of the service integration. For example, a target service API (e.g., an API of the second service <NUM>) is specified to the user. As another example, a set of recommended fields can be provided, which includes the fields of the first service UI <NUM>, from which the user had copied data from. In some examples, a set of additional fields can be provided, which includes one or more fields of the first service UI <NUM>, which the user had not copied data from. For example, the wizard module <NUM> can prompt the user to add fields by executing a copy-paste action from the first service UI <NUM> to the second service UI <NUM> in parallel with using the wizard and the IEE <NUM> records the newly copied fields in the set of additional fields. In some examples, a set of fields can be defined and can include the set of recommended fields and the set of additional fields, if any.

In some examples, the recording module <NUM> is called by target services that are configured to service integration recommendation (e.g., the second service <NUM>). For example, the recording module <NUM> is called when data is pasted into a target UI (e.g., the second service UI <NUM>) that includes metadata annotated by another instrumented service (e.g., the first service <NUM>). In some examples, the recording module <NUM> stores the metadata together with the timestamp in the paste action metadata store <NUM>.

In some examples, the suggestion module <NUM> is triggered is response to a new paste record being stored by the recording module <NUM>. In some examples, the suggestion module <NUM> is triggered on a schedule (e.g., hourly, daily, weekly) to review paste records stored since the last trigger. In some examples, the suggestion module <NUM> determines whether an integration recommendation is to be made based on the set of rules, discussed herein. If the suggestion module <NUM> determines that an integration recommendation is to be made, the suggestion module <NUM> prompts the user, as described herein.

In some examples, the generator module <NUM> is triggered to implement the recommended integration in response to the user accepting the recommended integration. For example, the generator module <NUM> calls an extension framework (not depicted) that generates an extension in the source service (e.g., the first service <NUM>) to call the target service (e.g., the second service <NUM>) and populate the fields in the set of fields. In some examples, the extension framework automatically adds a custom field to a respective table in the database that stores the data of the DO in question. The extension framework automatically adds access code to read, write, and search data of this field by API, and extends the UI to show the custom field on the same UI as the DO that is extended. The generator module <NUM> calls a configuration framework (not shown) to configure the target service (e.g., the second service <NUM>) so it can be called by the source service (e.g., the first service <NUM>). In some examples, the configuration framework stores connection parameters (e.g., URL, authentication credentials) to a target service. The configuration framework enables a source service to connect to a target service by specifying the service name without the need to know about the connection parameters maintained by the configuration framework. The generator module <NUM> stores metadata representative of the generated integration in the generated integration metadata store <NUM>.

<FIG> depicts an example service integration trigger <NUM> in accordance with implementations of the present disclosure. In the example of <FIG>, example data is copied from the first service UI <NUM> and is pasted into the second service UI <NUM>. More particularly, data in UI elements 204a, 204b of the first service UI <NUM> is copied and pasted into UI elements 208a, 208b of the second service UI <NUM>. In this example, for each copy action, metadata is generated by the first service UI <NUM> (e.g., DO = D1, Field = F_Namel; DO = D1, Field = F_Name2) and is pasted to the second service UI <NUM> with each paste action. As described herein, the second service UI <NUM> parses the metadata and the data, pastes the data into the respective fields 208a, 208b, and provides the metadata to the second service <NUM>. The second service <NUM> provides the metadata to the IEE <NUM>, which selectively triggers an integration recommendation, as described herein.

In the example of <FIG>, the integration recommendation can recommend that the fields 208a, 208b be included in the service integration, because those were the fields that the data was pasted into, which triggered the integration recommendation. In some examples, and as described above, one or more additional fields can be selected. For example, the IEE <NUM> can prompt the user <NUM> to select a field 208c to be included in the service integration.

Referring again to <FIG>, and in some implementations, in response to determining that a service integration is to be recommended, the IEE <NUM> pushes recommendation information to the source UI of the service that the user copies the data from and the source UI will notifies the user of the integration recommendation. In the example of <FIG>, the IEE <NUM> transmits recommendation information to the first service UI <NUM>. In some examples, a notification is provided during a current session with the first service <NUM>. In some examples, a notification is provided at the start of a next session with the first service <NUM>. In some examples, another channel, such as a digital assistant, notifies the user of the integration recommendation. In some examples, the user can decline the integration recommendation (e.g., selecting a "not now" UI element). In some examples, the user can accept the integration recommendation (e.g., selecting an "accept" UI element).

In some implementations, in response to the user accepting the integration recommendation, a set of actions is triggered to implement the service integration. An example action can include requesting that the user enter a label, which can be used in a generated UI element to trigger a push of data from the first service <NUM> to the second service <NUM>. In some examples, the user can select to add more fields of the first service UI <NUM> for input to the second service <NUM> (e.g., fields of the first service UI <NUM> that were not included in the copy-paste action(s) that triggered the recommendation).

In some implementations, it can be determined whether the service integration is to be implemented only for the particular user (i.e., the user that accepts the service integration) or if the service integration is to be implemented more broadly. For example, the IEE <NUM> can request that the user <NUM> specify whether the service integration is only to be used for them or is to be used more broadly. In some examples, more broadly can indicate a set of users that includes the user <NUM> (e.g., a user group that the user <NUM> is a member of).

In some implementations, to enable implementation of the service integration for a larger audience multiple approaches can be considered. For example, a set of users can be defined and can include users with roles that have read-permission in the source UI (e.g., the first service UI <NUM>) and write-permission in the target UI (e.g., the second service UI <NUM>). Users having both roles are candidates for use of the service integration. As another example, a set of users can be defined and can include users with roles that have read-permission in the source service (e.g., the first service <NUM>) and write-permission in the target service (e.g., the second service <NUM>). Users having both roles are candidates for use of the service integration. As another example, a so-called power-user of the application and related Uls (e.g., administrator) can be notified of the service integration and can determine whether to publish the service integration to all users or a sub-set of users. In some examples, if the service integration is proposed to a group of users, a notification can be provided (e.g., in source UIs of respective users). In some examples, each user can opt-in and add the service integration extension to their UI. In some examples, a default of accepting the service integration can be provided and each user can opt-out (e.g., users can remove modified source Uls by opting out).

<FIG> depicts a modified portion of the example conceptual architecture of <FIG> after automated service integration in accordance with implementations of the present disclosure. In the example of <FIG>, an extended first service UI <NUM>' is provided by extending the first service UI <NUM>-<NUM> (by the extension framework) with at least one second service UI element (UIE) <NUM>. Further, the first service <NUM> includes a second service extension <NUM>. The second service extension <NUM> enables direct communication between the first service <NUM> and the second service <NUM>. For example, the second service extension <NUM> is invoked from the extended first service UI <NUM>'. In some examples, when the user <NUM> clicks on the corresponding UIE that triggers the generated integration (e.g., the second service UIE <NUM>), the second service extension <NUM> reads the fields that were determined relevant when the integration was created, and uses the destination framework to establish a connection to the second service <NUM>. In some examples, the second service extension <NUM> invokes an API to create a DO in the second service <NUM> and fills in one or more fields with data read from the first service <NUM>. The second service extension <NUM> navigates the user <NUM> to the second service UI <NUM> to complete data entry on the already pre-populated DO, if any. In some examples, SSO is configured across all services. Consequently, the OAuth token that was used in the first service <NUM> is exchanged to a token valid for the second service <NUM> representing the same user. For this, the destination framework was configured with credentials that are used to call the identity management system to fetch the token to be used when calling the second service <NUM>.

<FIG> depicts an example process <NUM> that can be executed in accordance with implementations of the present disclosure. In some examples, the example process <NUM> is provided using one or more computer-executable programs executed by one or more computing devices.

A paste data set is received (<NUM>). For example, and as described herein with reference to <FIG>, the user <NUM> executes a copy action (or cut action) and a paste action for semi-automated copying of the data from one UI to another UI, in this case, from the application UI <NUM> (the first service UI <NUM>) to the second service UI <NUM>. Here, the second service UI <NUM> receives the paste data set. When the data is copied from the first service UI <NUM>, the application UI <NUM> (the first service UI <NUM>) is configured to provide a paste data set that includes the data and metadata that represents the first service <NUM> as the source of the data. In some examples, the metadata can include, without limitation, a data structure of the data, a path to the data (e.g., a uniform resource locator (URL) of the date) and a location of the first service <NUM>, which the data is copied from (e.g., a URL of the first service <NUM>). In some examples, the paste data set also includes an identifier of the user (user-id) and an identifier of the first service <NUM> (service-id).

It is determined whether the paste data set includes metadata (<NUM>). For example, and as described herein, the second service UI <NUM> is configured to be responsive to data sets that include such metadata. In some examples, in response to the paste data set being pasted into the second service UI <NUM>, the second service UI <NUM> is configured to determine whether the data is associated with metadata, and, if so, extract the metadata and store the metadata. In some examples, a paste data set does not include such metadata (e.g., in cases where the a service, from which the data is copied, is not configured to provide such metadata). If the paste dataset does not include metadata, data is pasted into respective fields (<NUM>), and the example process <NUM> loops back. If the paste dataset includes metadata, data is pasted into respective fields (<NUM>) and the metadata is provided to the target service (<NUM>). For example, and as described herein, only the data that is copied from the first service UI <NUM> is pasted into respective fields of the second service UI <NUM> (i.e., the metadata is not pasted into any fields of the second service UI <NUM>).

Metadata and paste target information are transmitted to the IEE (<NUM>). For example, and as described herein, the second service <NUM> receives the metadata and transmits the metadata and information on the paste target (i.e., paste target information) to the IEE <NUM>. In some examples, the paste target is the second service UI <NUM> and/or the second service <NUM> or portions of each. In some examples, the information on the paste target includes, without limitation, the user-id, the service-id of the second service <NUM>, associated API/screen to call, and timestamp of paste action. In some examples, the second service <NUM> provides a data set that includes the metadata, the user-id, and the service-id resulting from the copy action within the first service UI <NUM>, and the paste information resulting from the paste action within the second service UI <NUM>.

It is determined whether an integration recommendation is to be made (<NUM>). For example, and as described herein, the IEE <NUM> receives the data set from the second service <NUM> and processes the data set to determine whether an integration recommendation is to be provided. In some examples, the IEE <NUM> can execute a set of rules that define circumstances, under which an integration recommendation is to be provided. If it is determined not to make an integration recommendation, the example process <NUM> loops back. If it is determined to make an integration recommendation, a user is notified (<NUM>). For example, and as described herein, the IEE <NUM> pushes recommendation information to the source UI of the service that the user copies the data from and the source UI will notifies the user of the integration recommendation. In some examples, a notification is provided during a current session with the first service <NUM>. In some examples, a notification is provided at the start of a next session with the first service <NUM>. In some examples, another channel, such as a digital assistant, notifies the user of the integration recommendation. In some examples, the user can decline the integration recommendation (e.g., selecting a "not now" UI element). In some examples, the user can accept the integration recommendation (e.g., selecting an "accept" UI element).

It is determined whether the integration recommendation is accepted (<NUM>). If the integration recommendation is not accepted, the example process <NUM> loops back. If the integration recommendation is accepted, an extension framework is called to generate an extension (<NUM>) and a configuration framework is called to configure the source service (<NUM>). For example, and as described herein, the generator module <NUM> of <FIG> is triggered to implement the recommended integration in response to the user accepting the recommended integration. For example, the generator module <NUM> calls an extension framework (not depicted) that generates an extension in the source service (e.g., the first service <NUM>) to call the target service (e.g., the second service <NUM>) and populate the fields in the set of fields. In some examples, the extension framework automatically adds a custom field to a respective table in the database that stores the data of the DO in question. The extension framework automatically adds access code to read, write, and search data of this field by API, and extends the UI to show the custom field on the same UI as the DO that is extended. The generator module <NUM> calls a configuration framework (not shown) to configure the target service (e.g., the second service <NUM>) so it can be called by the source service (e.g., the first service <NUM>). In some examples, the configuration framework stores connection parameters (e.g., URL, authentication credentials) to a target service. The configuration framework enables a source service to connect to a target service by specifying the service name without the need to know about the connection parameters maintained by the configuration framework.

In some examples, one or more additional users are notified of the service integration (<NUM>), and the example process <NUM> loops back. For example, and as described herein, it can be determined whether the service integration is to be implemented only for the particular user (i.e., the user that accepts the service integration) or if the service integration is to be implemented more broadly. For example, the IEE <NUM> can request that the user <NUM> specify whether the service integration is only to be used for them or is to be used more broadly. In some examples, more broadly can indicate a set of users that includes the user <NUM> (e.g., a user group that the user <NUM> is a member of).

Referring now to <FIG>, a schematic diagram of an example computing system <NUM> is provided. The system <NUM> can be used for the operations described in association with the implementations described herein. For example, the system <NUM> may be included in any or all of the server components discussed herein. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. The components <NUM>, <NUM>, <NUM>, <NUM> are interconnected using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. In some implementations, the processor <NUM> is a single-threaded processor. In some implementations, the processor <NUM> is a multi-threaded processor. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM> to display graphical information for a user interface on the input/output device <NUM>.

In some implementations, the memory <NUM> is a computer-readable medium. In some implementations, the memory <NUM> is a non-volatile memory unit. In some implementations, the storage device <NUM> may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. In some implementations, the input/output device <NUM> includes a keyboard and/or pointing device. In some implementations, the input/output device <NUM> 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, 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.

Elements of a computer can include a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer can 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.

Examples of communication networks include, for example, a LAN, a WAN, and the computers and networks forming the Internet.

Claim 1:
A computer-implemented method for automatic integration of services (<NUM>, <NUM>) in service-based applications, a service being an independent software component that includes code and data used to execute complete and discrete functionality and that uses common interface standards, wherein a service can be communicated with over a network (<NUM>) using standard communication protocols, the method being executed by one or more processors (<NUM>);
characterized by
receiving, by an integration extension engine (<NUM>) and from a target service (<NUM>), user action metadata and target information, the user action metadata representing an action of a user (<NUM>) to the target service (<NUM>);
determining, by the integration extension engine (<NUM>), that an integration recommendation is to be issued to the source service (<NUM>) at least partially in response to the user action metadata, the integration recommendation recommending a service integration of the target service (<NUM>) with the source service (<NUM>); and
automatically executing, by the integration extension engine (<NUM>), integration of the target service (<NUM>) with the source service (<NUM>) by:
calling an extension framework to generate an extension (<NUM>) to enable direct communication between the source service (<NUM>) and the target service (<NUM>), the extension (<NUM>) being installed in the source service (<NUM>), and
calling a configuration framework to configure the source service (<NUM>) having the extension (<NUM>) installed therein;
wherein, in response to the service integration, a user interface (<NUM>) of the source service (<NUM>) is populated with one or more fields (<NUM>) of a user interface (<NUM>) of the target service (<NUM>).