Thats right . But thats the whole thing i want to avoid when i started using dynamic invocations.
Say :-
So if i am extending say ... dbFlows to handle a new DB (say PostGreSQL) (taking an example).... it means to go to the original flow .... add a switch in multiple places whereever db interaction happens.
If the flow interacts with DB on multiple places say .... 10 interactions - we will need to add 10 switches.
Then when a new DB comes another option to each of those switches.
This is just 1 functionality on DB . And we are doing same across multiple areas.
Rather i would simply supply a plug in -
Oracle In ------ flow ---- Oracle Out
PostGreSQL IN ------ flow ---- PostGreSQL Out
And user can simply set the msg.db to OracleIN or PostGreSQLIN and his flows start working with a new DB.
No change the structure of the main flow to add deploy the plug in.
Deploying a change across environments becomes much better without having to worry of impact on on going productions. Nor do we need to maintain different versions of flows depending on when it was deployed.
Plus more importantly if someone else wants to extend he - just puts his own plug in and rest of the stuff continues.
Well, if you going to want to call the same set of possible link routines from several places then I'd wrap the switch and the link call nodes in a subflow and use that
But since Nick seems willing to change the link call mechanism then your in luck
Its not the same set of routines everytime i speak to DB.
Each of those interactions do something different with the DB.
Below is a more detailed near life example :-
We interact with DB in 10s of places say each for a different piece.
function node : dbGetDetailsFromTable1.
implemented using action flow invoke (msg.db + "dbGetDetailsFromTable1")
With msg.db = ORACLE
ORACLEdbGetDetailsFromTable1 In --- flow -- ORACLEdbGetDetailsFromTable1 Out.
function node dbGetDetailsFromTable2 -
implemented using action flow invoke (msg.db + "dbGetDetailsFromTable2"). It invokes.
ORACLEdbGetDetailsFromTable2 In --- flow -- ORACLEdbGetDetailsFromTable2 Out.
and so on for each interaction.
(Each interact with DB is a different need).
Now for another DB - all i have done is - implemented below :
PSQLdbGetDetailsFromTable1 In ---- PSQLdbGetDetailsFromTable1 Out
PSQLdbGetDetailsFromTable2 In ---- PSQLdbGetDetailsFromTable2 Out
So the same flow now does everything with this new db seamlessly.
I did not need to add switches in every part of the flow to achieve this.
And all user sees on the flow is dbGetDetailsFromTable3... some nodes .... dbGetDetailsFromTable2
Much cleaner and clearer.
Think of it if i now added switches then when i deploy i need to support both old version and new version of my flow. With above approach my flow structure did not change at all.
Env 1 can continue the same flow with ORACLE.
Env 2 can continue the same flow with PSQL.
(msg.db itself is part of env set up which is done via. configuration file. Flows reads at start.
I am able port in my flows across db without having to actually touching the basic structure of my flows.)
