Ariba, Inc.

Sap Se

Dinesh Shahane

Kiran Gangadharappa

Harshad Chavan

Sushant Prasad

Ketan Bengali

Prashant Bhagat

Kshitij Dayal

Jennifer Chen

Jagdeep Shetty

John Lark

Ridwan Tan

Pankaj Khandelwal

Dennis Lee

Raj Vuppala

Dennis Tunglin Lee

Robert Wells

In an example embodiment, primary data is received from a first tenant in a computer network. Then auxiliary data relating to the primary data is received from the first tenant. A first index is created for the primary data and the auxiliary data from the first tenant. Then the first index is stored as a first shardlet. The first shardlet is bundled with one or more other shardlets for the tenant in a shard group. The shard group is packed with one or more other shard groups in a first shard. Then the first shard is stored in a first instance of a distributed database, the distributed database comprising a plurality of instances, each instance operating on a different logical or physical device.

Elastic sharding of data in a multi-tenant cloud

In an example embodiment, zone information is received from a distributed database, the zone information including a mapping between each of a plurality of client applications and a corresponding zone. Then a first adapter is assigned to a first client application based on the mapping. A second adapter is then assigned to a second client application based on the mapping. When data is received from the first client application, the data from the first client application is parsed using the first adapter, producing output to a search core and an indexing core associated with a zone corresponding to the first client application.

Multi-adapter support in the cloud

Methods and apparatus, including computer program products, are provided for flow control. In one aspect, there is provided a method, wherein the method may include monitoring, by an external flow controller, a workflow at a first cloud application to determine whether at least one condition is satisfied to extend the workflow to a second cloud application external to the first cloud application; diverting, by the external flow controller, when the at least one condition is satisfied; handling, by the external flow controller, a request to divert the workflow to the second cloud application by at least formatting the request in accordance with configuration information at the external flow controller; sending, by the external flow controller, the workflow to the second cloud application; receiving, by the external flow controller, a result to incorporate into the workflow at the first cloud application; and/or proceeding with the workflow at the first cloud application.

Flow extension controller

In an example embodiment, a method for indexing data is provided. Primary data and auxiliary data is received from a first tenant in a computer network. A first index is then created for the primary data and the auxiliary data from the first tenant. The first index is stored in a first shard. Then primary data and auxiliary data are received from a second tenant in the computer network. A second index is created for the primary data and the auxiliary data from the second tenant. The second index is then stored in the first shard. The first shard is then stored in a first instance of a distributed database, the distributed database comprising a plurality of instances, each instance operating on a different logical or physical device.

Indexing heterogeneous searchable data in a multi-tenant cloud

In an example embodiment, a first data change and a second data change to data stored in a distributed database are received. The first data change and the second data change are batched in a communication to an index manager. The distributed database is reindexed based on the first data change and the second data change by creating a revised first shard index for a first shard in the distributed database and a revised second shard index for a second shard in the distributed database. The first shard and the second shard are instructed to update respective shard indexes. Confirmation that the first shard index has been updated is received. Then confirmation that the second shard index has been updated is received. In response to both of the confirmations, both the first shard and the second shard are instructed to commit their respective updates.

Updating distributed shards without compromising on consistency

In an example embodiment, identifications of user actions are received from a first user device, the user actions being actions related to identifying data from a multi-tenant database to view. A portion of a first search query is received from a first user device corresponding to a first tenant in a multi-tenant architecture. A list of permissions for the first user device is then obtained. A plurality of fields is retrieved from a multi-tenant database based on the portion of the first search query, the fields obtained from data stored by multiple different tenants in the multi-tenant database, the plurality of fields retrieved being limited to fields for which the first user device has permission to view. Then a plurality of autocomplete suggestions are identified from the plurality of retrieved fields, the identifying based on the user actions.

Autocomplete of searches for data stored in multi-tenant architecture

In an example embodiment, a listing of factors to evaluate during calculating of an index score for documents in a database is received, as well as a ranking of each factor in the listing of factors. A relevance multiplication factor is also obtained. Then a document to index in the database is received and the document is indexed. An index score is calculated for the document based on the listing of factors and the ranking of each factor. Then a search query on the database is received. A search score for the document is calculated based on the search query. Then an overall relevance score is calculated for the document for the search query by combining the index score and the search score using the relevance multiplication factor.

Customizable ranking of search engine results in multi-tenant architecture

In an example embodiment, primary data is received from a first tenant in a computer network, the primary data formatted based on a first version of a schema. Then a schema definition for the first version of the schema is obtained. The primary data is then parsed, the parsing including storing a schema version number for the first version of the schema. The primary data is indexed, by obtaining, using the schema version number for the first version of the schema, a schema definition for a most recent version of the schema; applying schema evolution to the primary data by applying one or more transforms to the primary data, the one or more transforms created using the schema definition for the first and most recent versions of the schema, causing the primary data to be converted to the most recent version of the schema; and indexing the converted primary data.

Schema evolution in multi-tenant environment

In an example embodiment, data to be indexed in a distributed file system is received via a near real time publish application program interface (API). A shard responsible for the data to be indexed is determined. Then a message is generated in a shard queue corresponding to the shard responsible for the data to be indexed, the message indicating that data needs to be urgently indexed, the detection of the message in the shard queue by a near real time manager corresponding to the shard responsible for the data to be indexed causing the near real time manager to cause the data to be indexed.

Shard aware near real time indexing

In an example embodiment, a disaster is detected at a primary data center and, in response to the detection, a system switches over from the primary data center to a secondary data center such that searches from one or more client applications are routed to the secondary data center. Then, for each document stored in a search core of the secondary data center: a count is requested for the document from a first client application, it is determined whether the count for the document from the first client application matches a count for the document from the search core of the secondary data center, and, in response to a determination that the count for the document from the first client application does not match a count for the document from the search core of the secondary data center, a full publish for the document is requested from the first client application.

Growing community of inventors

Cupertino, CA, United States of America

Dinesh Shahane