We have a use case where Creatio co-exists with a legacy application which is SQL heavy - A lot of logic is written using SQL Stored procedures. There are certain custom objects on Creatio that needs to be populated and read by the legacy app on a weekly basis. Integration via APIs is not an option (owing to all the business logic being already available in Stored procedures). Using Excel Import/Export is also not an option.
We are considering an ongoing ETL via SQL where a stored procedure is used to directly write/read info from Creatio's custom tables. Assume that the Legacy application has a good understanding of the schema and relationships and transformation/mapping to/from Creatio tables is not an issue.
Pls comment on the following -
1. Is this feasible? - In my view, this should definitely be feasible as at the end of the day, It is an SQL DB. Any data read out of Creatio's DB does not disturb the state of the data in the DB. Any data modified (correctly) in the DB should reflect correctly in the Creatio application. Can you confirm?
2. Is this recommended? - Apart from ease of use and need for SQL development, Are there any reasons from a Creatio product/architecture stand point why this might not be recommended? The load on the WebServer is a negligible factor as these SQL import/export will only be done during low usage periods weekly.
Can you please check this Marketplace add-on, I believe it can help you with your business task.
But still, if you decide to use your approach, then:
1. Yes, that is feasible. The data will be available in the Application but you need to understand that if you miss to insert something, the data might be corrupted. Also, this kind if data transfer won't trigger BP as this will be considered to be direct data insert into the DB.
2. I can not say that this approach is recommended but it is possible. And again, you need to perform a lot of testing before real data transfer just not to lose data.
Can you please check this Marketplace add-on, I believe it can help you with your business task.
But still, if you decide to use your approach, then:
1. Yes, that is feasible. The data will be available in the Application but you need to understand that if you miss to insert something, the data might be corrupted. Also, this kind if data transfer won't trigger BP as this will be considered to be direct data insert into the DB.
2. I can not say that this approach is recommended but it is possible. And again, you need to perform a lot of testing before real data transfer just not to lose data.
Yes, We did consider the plugin. But our use case needs to migrate data from a few custom SQL databases and on an ongoing ETL for 2 weeks. Also, We mostly have custom objects on Creatio and it is not a typical Creatio CRM that we are building.
#1 Yes, I understand that this won't trigger BPs. We are only doing this as a 1 time migration activity as our client is migrating an existing custom application to Creatio.
We have workflows & business logic configured at the Application layer (Via business processes, entity event listeners & incoming API integrations). However, we need to transfer some data into our Database only via direct SQL. Is there any way at all of triggering application level logic on some Database level triggers?
I can think of a few round about/hacky ways of achieving this. Want some input wrt support for DB to Application layer execution flow from a Creatio product stand point and any clean ways of doing this.
We have workflows & business logic configured at the Application layer (Via business processes, entity event listeners & incoming API integrations). However, we need to transfer some data into our Database only via direct SQL. Is there any way at all of triggering application level logic on some Database level triggers?
I can think of a few round about/hacky ways of achieving this. Want some input wrt support for DB to Application layer execution flow from a Creatio product stand point and any clean ways of doing this.
In case you need to interact with the database directly you need to use either stored procedures or triggers that could trigger additional actions upon some actions on the application level. This will be the easiest way to achieve your target.
I was referring to use cases like the following - When a SQL Trigger gets activated, Run a business process at the Application layer. There is no direct way to do this I would presume?
Also, the dbExecutor class will help perform operations unidirectionally from the Application layer to the DB layer. I don't think something like this is available - When a trigger runs at the DB layer, it is available as an Event to catch or subscribe to at the Application layer. Is this right?
A very distant example would be something like this -
You can call stored procedure using dbExecutor, but not visa versa (trigger calls a process). You can use another approach: insert data to the database and then call the process manually for all the records by their CreatedOn date value. As a result data will be inserted to the system and processed by a business process.
Thank you Oscar for your response. Yes, the final approach you have suggested is one of the ways I also thought about. It is still round about and non optimal. Appreciate your answer nevertheless.
