Automated Data Warehouse Capabilities for over 90 Data Sources

SANTA CLARA, Calif.Sept. 18, 2017 /PRNewswire/ — Santa Clara, CA-based Sesame Software today announced its Beta Program for its new Relational Junction Data Warehouse Builder, featuring automated data warehouse design and data replication of all data, including SaaS data, regardless of whether it’s stored in the Cloud or on local servers.

Relational Junction Data Warehouse Builder has its roots in Relational Junction for Salesforce, which builds a data warehouse of your Salesforce.com data in an on-premise relational database. Bi-directional replication provides the capabilities of loading data to Salesforce and recovering data from historical versioned backups to any point in time. Sesame is extending the data warehouse capabilities to nearly ninety new data sources, including traditional relational databases, many cloud application vendor products, and non-relational data sources. The first release will add warehouse builder capabilities to relational databases. Future releases will include Big Data warehouses as the target. Relational Junction Data Warehouse Builder will automate the creation of the target data warehouse schema and auto-discovery of new fields and tables or objects in the source system.

Prospective customers can sign up for the beta program at sesamesoftware.com.

About Sesame Software
Headquartered in Santa Clara, CA, Sesame Software is an Enterprise Application Integration/Data company whose Relational Junction products offer superior solutions for data integration, complete data recovery and data warehousing.

Media Contact:
Crystal Duarte
Chief Marketing Officer
Sesame Software
Tel:  408-838-8972
Crystal.Duarte@SesameSoftware.com                                                                                                        

 

SOURCE Sesame Software, Inc.

Related Links

http://www.sesamesoftware.com

Relational Junction will work on any web application server, including WebLogic, if the app server supports Java 1.8. Nearly all of our customers use Tomcat, since it provides all the services required for the web administration without any licensing costs. Relational Junction is primarily a batch system. You can fire off jobs in the web user interface, but stopping Tomcat does not kill the jobs. It is far better to have  a dedicated server for Relational Junction, because of the batch orientation, than use a web application server with many other transactional applications running.

Yes, but it would be naive to think that it doesn’t require carefully though out decisions and preparations to make so the new records fit into the target org, such as

  • Is the target org empty or does it contain existing users, products, and other slowly changing data? On professional service engagements, our team has used mapping tables to marry up the business keys in the source or with the target records by their Salesforce ID in the target org. Unique business keys are required to make this work smoothly.
  • How do you want to detect and handle duplicates? If you are merging business units, how do you determine if you have a common customer and which record “wins” in that event?

Yes. There is a button you can press in the user interface that will gracefully cancel any job with full two-phase of all transactions in Salesforce and status flags in the database. This makes restores fully restartable without creating duplicates in Salesforce.

We do not create foreign key constraints because it would prevent copying records if they were done out of order, as you would get constraint violations if the child was copied before the parent. Also, some of the relationships (such as the ParentID of Attachment) point to multiple objects.

Yes. The relationship fields are stored in the database. When records are restored, the relationship fields are updated for all the child records as the parent records get new Salesforce ID’s. This is a patented process that allows one-pass restore of related data, including recursive relationships.

Contact.AccountID –> Account.ID

Contact.ReportsToID — Contact.ID

Even multi-level relationships are supported (Account1 has Contact1 as its child, which has Account2 as its child in a custom relationship).

There is no limit. We have customers with terabytes of data.

Relational Junction uses patented and patent-pending technology to limit queries to manageable sizes, preventing fatal timeouts and staying within limits of the Salesforce API. Performance of the product is an order of magnitude faster than the Salesforce Bulk API and does not require intermediate landing files.

Yes. Content Version can also be backed up and restore, within reasonable limitations of your hardware to store the entire record in memory.

Yes. The only limitations are

  • The object must be “Createable” — a term which Salesforce means the Salesforce application allows an API user to create new records. For instance, AccountHistory and OpportunityHistory records are not Createable; they are created internally by Salesforce.
  • The user must have security permission to create records in Salesforce.