There is a way to make it work with standard data processes, but with some limitations.
You'll need to create a new database table ("input table") where you'd insert your input parameters for a procedure. Plus some unique request identifier (String) to differentiate between multiple concurrent requests.
Then you'll need to create a SQL Server view that calls the procedure for every record in the input table, and returns its result, alongside the original request identifier from the source table. If I'm not mistaken, you may need to use the "OPENQUERY" function in the view (can't say exactly, i'm much more of Oracle guy than sql server).
In RTDM, you can then have a sequence of 3 Data Processes:
- Insert your input values to the input table, and use Event.Identity as a request identifier
- Read from the view, and filter on the request identifier = Event.Identity as criteria variables.
- Delete a record from the input table (again using Event.Identity as a request identifier).
The catch is that you need to make sure the procedure you are calling doesn't have any unsafe side-effects and is safe if sometimes called extra times repeatedly. With this solution, there will be situations where two or more requests are processed concurrently, and there will be more than one record in the input table - so the procedure will be called extra times. Depending on your use case and the nature of this procedure, it may or may not be OK.
If it's not OK, then the way to go develop is a DS2 or Groovy script process that will call the procedure with explicit SQL.
-------
Dmitriy Alergant, Tier One Analytics