Abstract: A multi-tenant system, comprises a main storage system including: a monolithic database storing global records associated with global objects, each global object including global fields common for all tenants; a monolithic application configured to process a particular global record storage request by instructing the monolithic database to store particular global field values of the particular global record for a particular tenant, and to process a particular global record fetch request by instructing the monolithic database to retrieve the one or more particular global field values; a custom object storage system including: a custom object database configured to store custom records associated with one or more custom objects, each custom object including one or more custom fields for a tenant; a custom object record service configured to process a particular custom record storage request by instructing the custom object database to store one or more particular custom field values for the tenant, and to proce

Abstract: A data sync cache is maintained to facilitate syncing of child data objects between a first computing system and a second computing system. Responsive to successful syncing of a parent data object of a child data object by a first sync engine, parent object data sync information indicating that the parent data object was successfully synced is written to the data sync cache. Prior to initiating a sync of the child data object by a second sync engine different from the first sync engine, a cache lookup of the data sync cache is performed to determine if the sync information is contained therein. If the data sync cache includes the sync information, the child data object sync is initiated. In this manner, failed syncs of child data objects are reduced along with the expensive API calls to the second computing system that would otherwise be required to retry failed syncs.

Abstract: Systems and methods for providing tenant-defined event notifications in a multi-tenant database system are provided. The method may include receiving a first event definition from a first tenant, defining a first business event trigger based on one or more first business object changes occurring to the tenant data of the first tenant; receiving particular database change events from a change data capture service, wherein each of the particular database change events represents a particular change to the tenant data for the plurality of tenants in the database; identifying one or more particular business object changes based on the particular database change events; comparing the first event definition against the one or more particular business object changes to determine whether the first business event trigger has been satisfied; and when the first event trigger has been satisfied, emitting a first business event.

Abstract: A self-healing data synchronization process includes an initial stage in which a collection of data change events is received, a set of data record(s) corresponding to the data change event(s) is identified, and a syncing of the set of data record(s) is initiated. Data that indicates which data record(s) successfully synced and which failed is stored. During a subsequent stage of the self-healing process, data change events that occurred during a preceding time horizon are identified, a corresponding first set of data record(s) are identified, a difference between the first set and a second set of data record(s) that successfully synced during the time horizon is determined as a third set of data record(s), and any data record that was attempted to be synced during the time horizon but failed is excluded from the third set. A sync of any data record remaining in the third set is then initiated.

Abstract: A multi-tenant system comprises a monolithic database storing global records, each including global fields common for all tenants; a custom field database storing custom records, each including custom fields for a tenant; a custom field record service processing a custom record storage request by instructing the custom field database to store custom field values of the custom record for the tenant, and processing a custom record fetch request by instructing the custom field database to retrieve the custom field values; a monolithic application configured to receive a record storage or fetch request, configured to partition the record storage request into the global record storage request and the custom record storage request, configured to send the custom record storage request to the custom field record service, configured to partition the record fetch request into the global record fetch request and the custom record fetch request, and configured to send the custom record fetch request to the custom field r

Abstract: Systems and methods providing authentication in a microservice system. In some embodiments, the method comprises receiving, from the user interface application, a user interface response corresponding to the user interface request; and sending the user interface response to the client computer. Some embodiments comprise when no cache entry corresponding to the user interface session token is present in the user interface session cache, directing the user interface request to a login service. Some embodiments comprise when the login service receives valid login credentials from the client computer, sending a new user interface session token to the client computer. Some embodiments comprise invalidating the cache entries in the user interface session cache according to a cache expiry policy; and determining whether the cache entry corresponding to the particular user interface session token is valid. In some embodiments, the user interface request session token consists of a single value.

Abstract: Shown is single sign-on support access to tenant accounts in a multi-tenant service platform involving a proxy user account in an identity provider for a tenant account on the service platform having security metadata associated therewith, mapping in the identity provider maps a support user to a proxy user identifier, a corresponding security endpoint in the service platform and mapping of the proxy user account identifier to the tenant account and security metadata. The identity provider authenticates a request to access the tenant account on the service platform, obtains the security credentials for the proxy user identifier, and sends a security assertion with the proxy user identifier and the security metadata to the security endpoint. The endpoint receives and validates the security assertion against the mapping for the proxy user identifier to the tenant account and the security metadata in the service platform, and permits access by the support user to the tenant account in the service platform.

Abstract: Shown is single sign-on support access to tenant accounts in a multi-tenant service platform involving a proxy user account in an identity provider for a tenant account on the service platform having security metadata associated therewith, mapping in the identity provider maps a support user to a proxy user identifier, a corresponding security endpoint in the service platform and mapping of the proxy user account identifier to the tenant account and security metadata. The identity provider authenticates a request to access the tenant account on the service platform, obtains the security credentials for the proxy user identifier, and sends a security assertion with the proxy user identifier and the security metadata to the security endpoint. The endpoint receives and validates the security assertion against the mapping for the proxy user identifier to the tenant account and the security metadata in the service platform, and permits access by the support user to the tenant account in the service platform.

Abstract: A method receives start commands for starting end-to-end testing of a live multi-tenant system that hosts shared services for multiple tenants; executes multiple test scripts for generating controller commands in response to the start commands, the executing the test scripts generating respectively synthetic transaction inputs; provides the synthetic transaction inputs to the live multi-tenant system, the live multi-tenant system configured to use the synthetic transaction inputs to perform respectively multiple synthetic transactions involving multiple destinations in the live multi-tenant system, the live multi-tenant system configured to generate respectively multiple test results in response to the multiple synthetic transactions; receives and evaluates the test results generated by the live multi-tenant system to test end-to-end performance conditions of the multi-tenant system; and generates one or more alerts upon recognizing an alert trigger condition based upon the evaluating of the test results.

Abstract: Systems, apparatuses, and methods for the recognition and allocation of revenue generated by a subscription based pricing model or plan that is applied to a product or service. Embodiments respond to customer needs for a flexible and powerful revenue allocation engine to permit correct revenue distribution within a subscription economy and effectively trace changes to a revenue schedule and the resulting revenue recognition. Embodiments can efficiently react to changes to a subscription agreement and calculate a new distribution for a revenue schedule and its impact on revenue recognition and future revenue projections. In one embodiment, the systems and methods includes a revenue recognition/allocation engine that operates to evaluate the impact of “charge events” on revenue generation, taking into account relevant business rules and revenue recognition principles.

Abstract: Receive, by a price calculation microservice, tenant user input from a particular tenant of a multi-tenant system. Generate, by the price calculation microservice, a particular charge model based on the tenant user input. Detect, by a usage microservice, a usage event associated with a customer of the particular tenant of the multi-tenant system. Receive, by a rating microservice, a rating request, the rating request being received in response to the detecting the usage event. Calculate, by the price calculation microservice in response to the receiving the rating request, a usage charge for the usage event based on the particular charge model. Store, by the rating microservice, the usage charge. Generate an invoice based on the usage charge stored by the rating microservice. Provide the invoice to the customer of the particular tenant of the multi-tenant system.

Abstract: Systems, methods and media are shown for equitable job processing of asynchronous messages for multiple tenants in a multi-tenant platform that involve receiving messages of a given message type in an input buffer from at least one front end tier (FET) device, providing messages of the given message type from an output buffer to at least one back end tier (BET) device, determining a priority weight W for each message in the input buffer based on a tenant identifier and message type for the message, and evaluating the priority weight W for the message and delaying the message if the priority weight W is below a priority threshold and moving the message to the output buffer if the priority weight W is not below the priority threshold.

Abstract: Receive, by a central controller engine, a user request to perform one or more operations associated with user data, wherein the user data includes first data and second data. Select, by the central controller engine based on the user request, a first service provider interface (SPI) integrated into a first service, the first SPI being configured to operate on the first data in a first datastore associated with the first service. The first SPI including a first service interface component configured based on a uniform access specification. Obtain, by the first SPI, the first data, the first data being formatted according to a first service data specification. Transform, by the first SPI based on the uniform access specification, the first data, thereby generating transformed first data formatted according to the uniform access specification. Provide, by the first SPI, the transformed first data to a target service.

Abstract: Receive a first order, the first order being associated with a subscription, and the first order being associated with one or more first order actions. Generate, based on the first order and the one or more first order actions, one or more first order metrics. Generate a multi-tiered subscription data object, a first tier of the multi-tiered subscription data object including the first order, a second tier of the multi-tiered subscription data object including the one or more first order actions, and a third tier of the multi-tiered subscription data object including the one or more first order metrics. Receive a first request for a first report. Generate, based on the one or more first order metrics of the multi-tiered subscription data object, one or more first multi-tiered subscription object reports. Present the one or more first multi-tiered subscription object reports.

Abstract: Receive, by an arbitrary query user interface, a user request to perform a query associated with user data, wherein the user data includes first data and second data. Partition, by a coordinator node of an arbitrary query engine, the query into at least a first sub-query and a second sub-query. Assign, by the coordinator node of the arbitrary query engine, the first sub-query to a first query node of the arbitrary query engine.

Abstract: Store a subscription dataset for each tenant of a multi-tenant system, each of the subscription datasets having a common data format native to the system, the subscription datasets including billing data and not behavioral data. Determine primary features from a particular subscription dataset. Derive secondary features from the primary features. Generate a churn prediction model based on the primary features and the secondary features. Obtain a second subscription dataset, the second subscription dataset comprising billing data that is more recent than the particular subscription dataset. Identify, using the particular churn prediction model and the second subscription dataset, one or more subscribers as a churn-risk. Report the one or more subscribers identified as a churn-risk.

Abstract: Receive a user request to perform a service request associated with user data. Select, based on the user request, a first service provider interface (SPI) integrated into a first service, the first SPI being configured to obtain and buffer the user data from a datastore associated with the first service into a first buffer of the first SPI. Obtain, by the first SPI, a first page of records of the user data from the datastore. Buffer, by the first SPI, the first page of records in the first buffer of the first SPI as the records of the first page of records are being obtained from the datastore. Provide, by the first SPI, the first page of records to a central controller engine. Store, by the central controller engine, the first page of records. Provide the first page of records to a user.

Abstract: Embodiments of the present methods and systems are directed to a system and method for managing and editing accounting periods. Particularly, the embodiments are directed to a financial management system that allows for the recordation of financial transactions without first requiring the creation of a user-defined accounting period, and that further allows for the creation, modification, and closure of defined accounting periods.

Abstract: Systems, apparatuses, and methods for the recognition and allocation of revenue generated by a subscription based pricing model or plan that is applied to a product or service. Embodiments respond to customer needs for a flexible and powerful revenue allocation engine to permit correct revenue distribution within a subscription economy and effectively trace changes to a revenue schedule and the resulting revenue recognition. Embodiments can efficiently react to changes to a subscription agreement and calculate a new distribution for a revenue schedule and its impact on revenue recognition and future revenue projections. In one embodiment, the systems and methods includes a revenue recognition/allocation engine that operates to evaluate the impact of “charge events” on revenue generation, taking into account relevant business rules and revenue recognition principles.

Abstract: A system synchronizes change-data in a multi-tenant system with one or more external service provider systems.