Skip to main content
Open

Add 'Execute Procedure' as process action type for Process Flows

Related products:Software FactoryIndicium Service Tier

Harm Horstman
Superhero

Since process flows can be scheduled it would be valuable to have this feature available.

Especially for environments that use AzureSQL, because they don't have an Agent to schedule jobs.

Personally I prefer to use Procedures for scheduled jobs, instead of tasks. I only use tasks where in case  only where user interaction is applicable.

Did this topic help you find an answer to your question?

11 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hey Harm,

Is the DB Connector (Database connector) not something you could use for that? In the DB connector you have the option to execute a SQL command. You could put in something like 'Exec dbo.procedure’ and add some parameters if needed.

Would that suffice?

EDIT: I do have to add that the DB connector less optimal than a dedicated Process action, for instance when the procedure name changes. Then you should change the SQL code too.

Kind regards,
Mark Jongeling


Harm Horstman
Superhero
Forum|alt.badge.img+21
  • Author
  • Superhero
  • 499 replies
  • March 30, 2020

Hello Mark,

This sounds like the solution I am looking for.

I will try it.

Thanks for the suggestion!

Best regards,

Harm

 

 


Harm Horstman
Superhero
Forum|alt.badge.img+21
  • Author
  • Superhero
  • 499 replies
  • March 30, 2020

I would like to leave the connection string empty and the SQL command to be executed on the end database.

With a Connection String containing username and password, we introduce a security issue. 

Another challenge is to make connection strings flexible for multi tenant application scenarios.


Mark Jongeling
Administrator
Forum|alt.badge.img+23

For my tests I used the following connection string: 
Driver={SQL Server};Server=SERVERNAME;Database=DATABASENAME;Trusted_Connection=Yes;

I understand the concerns and difficulties it may bring. Your wish would eliminate this :wink: You got my vote.


Harm Horstman
Superhero
Forum|alt.badge.img+21
  • Author
  • Superhero
  • 499 replies
  • March 30, 2020

The problem is, that trusted connections cannot be used on AzureSQL databases.

 


Mark Jongeling
Administrator
Forum|alt.badge.img+23
Harm Horstman wrote:

The problem is, that trusted connections cannot be used on AzureSQL databases.

 

Didn't know that but now I do. Even more reason to have an ‘Execute Procedure’ Process action.


Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi Harm,

We currently (from 2021.1) support the Application connector. This Process action is supported in System Flows and can run a SQL query on an application named in IAM. Does this solve the problem?


Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Administrator
  • 3958 replies
  • February 26, 2025
The following idea has been merged into this idea:

All the votes have been transferred into this idea.

Robert Jan de Nie
Thinkwise blogger
Forum|alt.badge.img+6
Mark Jongeling wrote:

Hey Harm,

Is the DB Connector (Database connector) not something you could use for that? In the DB connector you have the option to execute a SQL command. You could put in something like 'Exec dbo.procedure’ and add some parameters if needed.

Would that suffice?

EDIT: I do have to add that the DB connector less optimal than a dedicated Process action, for instance when the procedure name changes. Then you should change the SQL code too.

Kind regards,
Mark Jongeling

No the database connector is not what we are looking for. We want an easy way to manage our code and pass parameters in and out. 
(Ab-)using the db connector is not the way forward. Your code is in a weird spot and you open yourself up to implementing all logic there. 

Having the logic encapsulated in a procedure, managed by a control procedure and templates is a lot better. 
 

I think a db connector should only be used for cross database communication where no (rest) api is available. So almost never.


 


Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Administrator
  • 3958 replies
  • February 26, 2025

I think a db connector should only be used for cross database communication where no (rest) api is available. So almost never.

Agreed, nowadays we have much more options to use luckily, for example, the Application connector. My reply was of almost 5 years ago 😅


Robert Jan de Nie
Thinkwise blogger
Forum|alt.badge.img+6
Mark Jongeling wrote:

I think a db connector should only be used for cross database communication where no (rest) api is available. So almost never.

Agreed, nowadays we have much more options to use luckily, for example, the Application connector. My reply was of almost 5 years ago 😅

I know. You old man. But my feedback remains. We need a clean way to call a stored procedure from a process flow. Including input and output. 
A (system) task has got all sorts of UI stuff you don’t need. 



Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings