Abstract: A computer system monitors for a change in a first data output generated by execution of a predefined dataflow. In accordance with a determination that the first data output has changed and the first data output meets triggering criteria, the computer system triggers execution of a predefined second dataflow distinct from the first dataflow. The execution of the second dataflow is dependent on the change in the first data output generated by the first dataflow. In accordance with a determination that the first data output has changed and the first data output does not meet triggering criteria, the computer system forgoes triggering execution of the second data flow. In accordance with a determination that the first data output has not changed, the computer system forgoes triggering execution of the second dataflow.

Abstract: Database environments may choose to schedule complex analytics processing to be performed by specialized processing environments by caching source datasets or other data needed for the analytics and then outputting results back to customer datasets. It is complex to schedule user database operations, such as running dataflows, recipes, scripts, rules, or the like that may rely on output from the analytics, if the user database operations are on one schedule, while the analytics is on another schedule. User/source datasets may become out of sync and one or both environments may operate on stale data. One way to resolve this problem is to define triggers that, for example, monitor for changes to datasets (or other items of interest) by analytics or other activity and automatically run dataflows, recipes, or the like that are related to the changed datasets (or other items of interest).

Abstract: Database environments may choose to schedule complex analytics processing to be performed by specialized processing environments by caching source datasets or other data needed for the analytics and then outputting results back to customer datasets. It is complex to schedule user database operations, such as running dataflows, recipes, scripts, rules, or the like that may rely on output from the analytics, if the user database operations are on one schedule, while the analytics is on another schedule, User / source datasets may become out of sync and one or both environments may operate on stale data.

Abstract: Database environments may choose to schedule complex analytics processing to be performed by specialized processing environments by caching source datasets or other data needed for the analytics and then outputting results back to customer datasets. It is complex to schedule user database operations, such as running dataflows, recipes, scripts, rules, or the like that may rely on output from the analytics, if the user database operations are on one schedule, while the analytics is on another schedule. User/source datasets may become out of sync and one or both environments may operate on stale data. One way to resolve this problem is to define triggers that, for example, monitor for changes to datasets (or other items of interest) by analytics or other activity and automatically run dataflows, recipes, or the like that are related to the changed datasets (or other items of interest).

Abstract: Methods, systems, and devices supporting querying disparate data sources are described. Querying disparate data sources may include receiving an input for data stored at a first data source from a plurality of data sources, selecting a first data connector from a plurality of data connectors, wherein the first data connector corresponds to the first data source, and identifying a first query language corresponding to the first data source from a plurality of query languages. Querying the disparate data sources may further include generating a converted query based at least in part on the first query language and retrieving the data from the first data source using the first data connector based at least in part on the converted query.

Abstract: Database environments may choose to schedule complex analytics processing to be performed by specialized processing environments by caching source datasets or other data needed for the analytics and then outputting results back to customer datasets. It is complex to schedule user database operations, such as running dataflows, recipes, scripts, rules, or the like that may rely on output from the analytics, if the user database operations are on one schedule, while the analytics is on another schedule. User/source datasets may become out of sync and one or both environments may operate on stale data. One way to resolve this problem is to define triggers that, for example, monitor for changes to datasets (or other items of interest) by analytics or other activity and automatically run dataflows, recipes, or the like that are related to the changed datasets (or other items of interest).

Abstract: The technology disclosed relates to creating and frequently updating multiple online analytic processing (OLAP) analytic databases from an online transaction processing (OLTP) transaction updatable system that includes transaction commit, rollback, and field level security capabilities. It also relates to transparently decoupling extraction from rebuilding of frequently updated OLAP analytic databases from the OLTP transaction updatable system.

Abstract: Database environments may choose to schedule complex analytics processing to be performed by specialized processing environments by caching source datasets or other data needed for the analytics and then outputting results back to customer datasets. It is complex to schedule user database operations, such as running dataflows, recipes, scripts, rules, or the like that may rely on output from the analytics, if the user database operations are on one schedule, while the analytics is on another schedule. User/source datasets may become out of sync and one or both environments may operate on stale data. One way to resolve this problem is to define triggers that, for example, monitor for changes to datasets (or other items of interest) by analytics or other activity and automatically run dataflows, recipes, or the like that are related to the changed datasets (or other items of interest).

Abstract: DESCRIBED HEREIN ARE SYSTEMS, APPARATUS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR AGENT CONTROLLED DATA EXTRACTION FROM SECURE DATA SOURCES TO A MULTI-TENANT CLOUD SYSTEM AN ON-PREMISE AGENT OF A DATA SOURCE MAY RECEIVE COMMUNICATIONS FROM AN OFF-SITE DATA MANAGER. THE AGENT MAY DETERMINE WHETHER TO EXTRACT AND PROVIDE DATA BASED ON THE COMMUNICATIONS. IF THE AGENT EXTRACTS DATA, THE AGENT MAY THEN ACCORDINGLY PUSH DATA OFF-SITE.

Abstract: Methods, systems, and devices supporting querying disparate data sources are described. Querying disparate data sources may include receiving an input for data stored at a first data source from a plurality of data sources, selecting a first data connector from a plurality of data connectors, wherein the first data connector corresponds to the first data source, and identifying a first query language corresponding to the first data source from a plurality of query languages. Querying the disparate data sources may further include generating a converted query based at least in part on the first query language and retrieving the data from the first data source using the first data connector based at least in part on the converted query.

Abstract: A method for data processing is described. The method may include configuring a connection template that defines a data extraction flow for a first data source and transmitting from an analytics application server a controller application programming interface (API) call based on a query request for data stored at the first data source. The method may further include instantiating a connector microservice based on the controller API call and the connection template, where the connector microservice is configured with a first data connector with the analytics application server and a second data connector with the first data source that is specific to the first data source. The method may further include retrieving at the analytics application server the data from the first data source based on the connector microservice.

Abstract: The technology disclosed relates to creating and frequently updating multiple online analytic processing (OLAP) analytic databases from an online transaction processing (OLTP) transaction updatable system that includes transaction commit, rollback, and field level security capabilities. It also relates to transparently decoupling extraction from rebuilding of frequently updated OLAP analytic databases from the OLTP transaction updatable system.

Abstract: The technology disclosed relates to creating and frequently updating multiple online analytic processing (OLAP) analytic databases from an online transaction processing (OLTP) transaction updatable system that includes transaction commit, rollback, and field level security capabilities. It also relates to transparently decoupling extraction from rebuilding of frequently updated OLAP analytic databases from the OLTP transaction updatable system.

Abstract: The technology disclosed relates to creating and frequently updating multiple online analytic processing (OLAP) analytic databases from an online transaction processing (OLTP) transaction updatable system that includes transaction commit, rollback, and field level security capabilities. It also relates to transparently decoupling extraction from rebuilding of frequently updated OLAP analytic databases from the OLTP transaction updatable system.