Sap Se

Gopalkrishna Kulkarni

Sripad J

Bhagyesh Hede

Sumanth Kempegowda

Shankara Prasad K

Deepak Govardhanrao Deshpande

Sapreen Ahuja

Appala Naidu Uppada

Daniel Ritter

Parthasarathy Menon

Sabarish T S

Bhupender Singh Rathee

Andreas Quenstedt

Mrutyunjay Padmasali Sidda

A tenant data store contains information associated with tenants of a cloud computing environment, including an indication that a first customer subscribed to an exclusive tenant that receives an upcoming version of runtime software. A notification system pushes a notification about the upcoming runtime to an integration service for the first customer. A tenant preview service may contain the upcoming version of runtime software, and a software update store may contain new integration scenario content (created and tested by the first customer) in connection with the upcoming version of runtime software. An integration content mapper determines, based on old and new integration scenario content metadata, if an automatic port of the new integration scenario content in the software update store should be automatically provided to a runtime node. If it should be automatically provided, the integration content mapper may use a software update tool to automatically deploy the new integration scenario content.

Software updates without downtime via an integration content mapper for integration services

According to some embodiments, methods and systems may be associated with a cloud computing environment having an integration service (e.g., associated with a Software-as-a-Service or a Platform-as-a-Service). A design microservice may have a User Interface ('UI') framework and UI components for a first integration developer. A configuration framework may determine a set of configuration values for an integration component of an integration scenario defined by the first integration developer. The configuration framework may then receive, from the first integration developer, a publication indication associated with the integration component. Responsive to the publication indication, the configuration framework may arrange for the set of configuration values for the integration component to be made available to a second integration developer (e.g., via a marketplace platform).

Re-usable integration component configuration in a microservice based integration service

According to some embodiments, methods and systems may be associated with a cloud computing environment having an integration service (e.g., associated with a Software-as-a-Service or a Platform-as-a-Service). The system may include a build automation tool and a build-independent software framework coupled to the build automation tool. The build-independent software framework may access, via an implementation registry, information from the build automation tool that represents a custom adapter for the integration service. The build-independent software framework may then automatically create the custom adapter via a build Application Programming Interface ('API') and automatically validate the created custom adapter via a validation API. The system can then arrange to deploy a concrete implementation of the custom adapter in the cloud computing environment. According to some embodiments, the software framework is 'build-independent' because it does not require that an adapter designer use a particular Integrated Development Environment (&#x201c;IDE&#x201d;).

Build-independent software framework for creating custom adapters

According to some embodiments, methods and systems may be associated with a cloud computing environment having an integration service (e.g., associated with a Software-as-a-Service or a Platform-as-a-Service). A design micro service may have a User Interface ('UI') framework and UI components in a domain specific language for an integration developer. A custom flow step development kit may receive, from the integration developer via a browser-based graphical UI, information to build logic for a custom flow step associated with a microservice-based integration service. In some embodiments, a new integration component is embedded into an existing set of components for a tenant, and the new custom flow step is deployed in, and re-usable by, other integration services (e.g., via a marketplace).

Custom integration flow step for integration service

According to some embodiments, methods and systems may be associated with a cloud computing environment. A unified provisioning service may include a plan configuration data store that contains information associated with a combined service representing a plurality of multi-tenant cloud applications. A cloud platform provisioning framework may receive an indication of a subscription request for the combined service from a consumer via a Software as a Service ('SaaS') marketplace and access, responsive to the received indication, a dependent service framework of the unified provisioning service. The cloud platform provisioning framework may then receive dependency subscription data from the unified provisioning service, and, based on the dependency subscription data, arrange for the consumer to be subscribed to each of the plurality of multi-tenant cloud applications.

Provisioning set of multi-tenant cloud applications with unified service

According to some embodiments, methods and systems may include a data storage device that contains user identifiers and associated entitlement values for a plurality of tenants of a cloud computing environment. A provisioning application platform processor may receive a user request for an integration service and access the data storage device. The provisioning application platform processor may then transmit at least one entitlement value to a platform resource manager processor to facilitate creation of a plurality of microservices resulting in implementation of the integration service for the user.

Provisioning multi-tenant, microservice architecture-based integration service in a cloud computing environment

According to some embodiments, methods and systems may be associated with a microservice-based cloud computing environment. Model integration content may be received from an integration developer in connection with the cloud computing environment and at least one integration service may be determined associated with the received model integration content. A provisioning application platform may then automatically and dynamically instantiate the at least one integration service on demand during a provisioning process. Moreover, the provisioning application platform may also automatically subscribe the at least one integration service during the provisioning process. Similarly, at least one integration service to be consumed for received model integration content may be determined. The provisioning platform may then automatically instantiate that at least one integration service on demand during a consumption process. In this case, the provisioning application might automatically subscribe the at least one integration service during the consumption process.

Dynamic service creation for microservice-based integration service

The present disclosure involves systems, software, and computer implemented methods for principal propagation. One example method includes deploying a token service to a first cloud platform. A first token request is received from an integration component for a token to be included in a message sent from the first cloud platform to a second cloud platform. A user information request is generated and sent to an identity provider associated with the first cloud platform. User information is received from the identity provider in response to the user information request. A second token request is generated and sent to a token service provider associated with the second cloud platform. The second token request includes the received user information. The requested token is received from the token service provider. The received token is sent to the integration component to enable the integration component to send the message to the second cloud platform.

Oauth2 SAML token service

Techniques are described for constructing a query associated with different data sources. In one example, a method includes identifying a particular data source associated with at least one entity. Obtain a set of data source information defining each entities and a set of metadata associated with the particular data source. Then, provide at least a portion of the defined entities for selection associated with the query builder framework for presentation. In response to identifying a selection of a particular entity, the query builder UI provides for presentation a set of attributes associated with the particular selected entity for selection. In response to identifying a selection of a subset of the presented set of attributes, construct a query based on the particular selected entity and the selected subset of the presented set of attributes in a specified query format associated with the custom adapter associated with the particular data source.

Integration query builder framework

According to some embodiments, methods and systems may be associated with an integration computing environment for an enterprise. An integration modeling design platform may receive, from an integration developer via a modeling notation, an indication that a retry component should be associated with an integration task. The integration modeling design platform may then configure the retry component for the integration task in connection with at least one of an integration adapter and an integration component (e.g., a selection of a messaging component, a quality of service, a retry period, an exponential back off option, etc.). According to some embodiments, an integration generation framework, coupled to the integration modeling design platform, may automatically construct an appropriate runtime retry representation based on the configured retry component (e.g., by creating a domain-specific language software component).

Configuration based generation of retry component for integration adapter

Methods and systems may be associated with a cloud computing environment. A provisioning application data store may contain information associated with services representing a plurality of multi-tenant cloud applications including, for a first SaaS application, indications that a first tenant qualifies for early software updates and has opted to receive early software updates. A cloud platform provisioning framework may determine that a new software update to the first application is available and is scheduled to be installed within a pre-determined time period (e.g., one day or week). The framework may then access the provisioning application data store to verify that the first tenant qualifies for early software updates and has opted to receive early software updates. As a result of the verification, the cloud platform provisioning framework may automatically install the new software update to the first application for the first tenant prior to the scheduled installation.

Early software updates for multi-tenant integration service

According to some embodiments, methods and systems may include a provisioning application platform processor to receive a user request for an integration service. The provisioning application platform processor may then transmit information to a platform resource manager processor to facilitate creation of a plurality of microservices resulting in implementation of the integration service for a tenant associated with the user. A multi-tenant keystore management service, automatically deployed upon implementation of the integration service, may automatically call a trusted authority platform. The multi-tenant keystore management service may then receive a signed security certificate from the trusted authority platform and add the signed security certificate to a keystore deployed to the tenant.

Provisioning initial keystore for multi-tenant, microservice architecture-based integration service in a cloud computing environment setup

Deployment of computing environment is initiated. The computing environment includes at least one integration scenario and at least one adapter providing an interface to a backend computing system. Thereafter, a runtime component prevents activation of the at least one integration scenario until such time that the at least one adapter is fully deployed. Integration flows within the at least one integration scenario are subsequently enabled to utilize the at least one adapter. Related apparatus, systems, techniques and articles are also described.

Integration process to integration adapter connector

According to some embodiments, methods and systems may be associated with a cloud computing environment having a plurality of integration tenants. An independent usage measurement component (e.g., a microservice or module) may periodically calculate measurable meter units for a particular integration tenant of the cloud computing environment. Examples of measurable meter units include a static analysis of integration artifacts, outbound calls from components, message bandwidth, a number of messages, a static count of integration content connections, etc. A central cloud performance metering service may receive the calculated measurable meter units from the independent usage measurement component and arrange for billing data to be generated based on the calculated measurable meter units in connection with creation of a plurality of components resulting in implementation of an integration service for the particular integration tenant.

Growing community of inventors

Bengaluru, India

Gopalkrishna Kulkarni