Hello All,

I would like to manage api calls (http example /test/v1/* and /test/v2/* ../test/v3/*) in message flow.

currently its using httpInput node for single uri as basic path(/test/v1/*).

If URI changes with with new version api URL(with changes in request parameters), then what is the best way to handle this ? 

Options
1) should we keep on adding new http input node in existing message flow to handle new url ? ( not feasible as it might be difficult to manage )
or
2) clone flow with and new url and implement new business logic as required
or 
3) any flow versioning ? kindly advice




------------------------------
Syed Hassan
------------------------------

Depends a little bit of how many changes in a year you expect and how many path you have to handle and what the growth rate of additional paths is..
I would put a parameter like the path into a CMDB
Something that can be changed without deploying a flow and without executing mqsiapplybaroverride

If you work with CMDB, something like Service Now could change the path without manual IT work.
It would be self-service for your message flow clients.


------------------------------
Matthias Jungbauer
------------------------------

Thanks for your response,

Scenario is :

Message Flow - TEST.msgflow has HTTP Input node with url (/test/v1/sample/) and we need to accommodate new API request which will be exposed by either new flow or same flow with new url(/test/v2/sample/).

Note: we need to keep untouched to existing url(keeping that url and flow functionality) as it is since it is still be used by clients.

So, creating new message flow say. TEST.2.0.0.msgflow with new url and copying most of functionalities from existing and implement new feature on it ?.

This way, we are not disturbing existing (/test/v1/sample/) request and adding new Message flow for (/test/v2/sample/) and it will he good for maintenance and trouble shoot.

If required, its easy to retire older version message flow with out disturbing new version.

Also Could you recommend adding version number like 1.0.0 or 2.0.0 in the end of the new Flow names as we progress with new api urls/versions ?

Example - TEST.1.0.0.msgflow, TEST.2.0.0.msgflow

Thanks.

------------------------------
Syed Hassan
------------------------------

Original Message:
Sent: Tue January 12, 2021 05:31 AM
From: Matthias Jungbauer
Subject: App Connect - Message Flow to handle mutli

Depends a little bit of how many changes in a year you expect and how many path you have to handle and what the growth rate of additional paths is..
I would put a parameter like the path into a CMDB
Something that can be changed without deploying a flow and without executing mqsiapplybaroverride

If you work with CMDB, something like Service Now could change the path without manual IT work.
It would be self-service for your message flow clients.


------------------------------
Matthias Jungbauer
------------------------------

Up to now I never made good experiences with putting the version number into flowname
I say no to, - TEST.1.0.0.msgflow, TEST.2.0.0.msgflow
Reason:
Whenever someone updates the message flow - you need to remember not to forget to change the name of the message flow.
If another developer calls TEST.1.0.0.msgflow - the other guy needs to change his CMDB whenever you rename your flow.

I would work with a CMDB and map between path, pathHandler and handlerType
$url, $handler, $handlerType
/test/v1/sample/ ; name of message flow to be routed to ; flow
/test/v2/sample/ ; name of ESQL ; esql
/test/v1/fish/ ; name of JavaComputeNode; java
/test/v2/fish/ ; name of JavaComputeNode; java

My assumption is, that you have to handle hundreds of incoming URLs and may not want to change your code whenever a consumer of your work wants something. Business Requirements tend to change over time.

Search Engine Topic : database driven url routing
​A CMDB based message flow will be able to handle routing, transformation and mapping at run time and not at engineering / deployment time.
From your Employers point of view, it reduces a dependency with Documentation, Engineering and Testing capacity.

In the http input node, I would work with /*
What I would do in the message flow to be called is different story.

There are of course employers who would copy and paste an existing flow into a new flow.
A few years later, you need to migrate hundreds of flows into the next version of WMB, IIB, ACE and regression test them

But, perhaps I would not use WMB, IIB, ACE for url routing and processing and do the work with another IBM tool like WAS or API Connect

If you just have to handle a few URL that do not change often - it does not matter what your solution looks like.
Then you can also enter version number in flow names.
Some employers are doing that, too. You would not be alone with that naming convention.

------------------------------
Matthias Jungbauer
------------------------------

Original Message:
Sent: Tue January 12, 2021 08:56 AM
From: Syed Hassan
Subject: App Connect - Message Flow to handle mutli

Thanks for your response,

Scenario is :

Message Flow - TEST.msgflow has HTTP Input node with url (/test/v1/sample/) and we need to accommodate new API request which will be exposed by either new flow or same flow with new url(/test/v2/sample/).

Note: we need to keep untouched to existing url(keeping that url and flow functionality) as it is since it is still be used by clients.

So, creating new message flow say. TEST.2.0.0.msgflow with new url and copying most of functionalities from existing and implement new feature on it ?.

This way, we are not disturbing existing (/test/v1/sample/) request and adding new Message flow for (/test/v2/sample/) and it will he good for maintenance and trouble shoot.

If required, its easy to retire older version message flow with out disturbing new version.

Also Could you recommend adding version number like 1.0.0 or 2.0.0 in the end of the new Flow names as we progress with new api urls/versions ?

Example - TEST.1.0.0.msgflow, TEST.2.0.0.msgflow

Thanks.

------------------------------
Syed Hassan
------------------------------


Original Message:
Sent: Tue January 12, 2021 05:31 AM
From: Matthias Jungbauer
Subject: App Connect - Message Flow to handle mutli

Depends a little bit of how many changes in a year you expect and how many path you have to handle and what the growth rate of additional paths is..
I would put a parameter like the path into a CMDB
Something that can be changed without deploying a flow and without executing mqsiapplybaroverride

If you work with CMDB, something like Service Now could change the path without manual IT work.
It would be self-service for your message flow clients.


------------------------------
Matthias Jungbauer

Thanks Mathias for your response.

Appreciate your suggestion with CMDB for multi url routing. we need to handle few URL( at least 2 to 3 ) at this stage.

Since new api request url comes with new changes in request body data( from v1 to v2), then we need to manage both versions as of now.

Is it good idea to create separate Flow Application with HTTP Input node(new version url) and provide its implementation separately ?

Example:
for V1 and V2 url and its implementation.
App Name     Flow Name
AppA_v1         Flow_A_v1
AppA_v2         Flow_A_v2

or 

Using same application(common ie AppA) and adding new flow for each url and its implementation as below in existing Application (App_A, no version name added here to application name but added to new flows created for each url implementation.)
Flow_v1
Flow_v2

?




------------------------------
Syed Hassan
------------------------------

Original Message:
Sent: Wed January 13, 2021 03:48 AM
From: Matthias Jungbauer
Subject: App Connect - Message Flow to handle mutli

Up to now I never made good experiences with putting the version number into flowname
I say no to, - TEST.1.0.0.msgflow, TEST.2.0.0.msgflow
Reason:
Whenever someone updates the message flow - you need to remember not to forget to change the name of the message flow.
If another developer calls TEST.1.0.0.msgflow - the other guy needs to change his CMDB whenever you rename your flow.

I would work with a CMDB and map between path, pathHandler and handlerType
$url, $handler, $handlerType
/test/v1/sample/ ; name of message flow to be routed to ; flow
/test/v2/sample/ ; name of ESQL ; esql
/test/v1/fish/ ; name of JavaComputeNode; java
/test/v2/fish/ ; name of JavaComputeNode; java

My assumption is, that you have to handle hundreds of incoming URLs and may not want to change your code whenever a consumer of your work wants something. Business Requirements tend to change over time.

Search Engine Topic : database driven url routing
​A CMDB based message flow will be able to handle routing, transformation and mapping at run time and not at engineering / deployment time.
From your Employers point of view, it reduces a dependency with Documentation, Engineering and Testing capacity.

In the http input node, I would work with /*
What I would do in the message flow to be called is different story.

There are of course employers who would copy and paste an existing flow into a new flow.
A few years later, you need to migrate hundreds of flows into the next version of WMB, IIB, ACE and regression test them

But, perhaps I would not use WMB, IIB, ACE for url routing and processing and do the work with another IBM tool like WAS or API Connect

If you just have to handle a few URL that do not change often - it does not matter what your solution looks like.
Then you can also enter version number in flow names.
Some employers are doing that, too. You would not be alone with that naming convention.

------------------------------
Matthias Jungbauer
------------------------------


Original Message:
Sent: Tue January 12, 2021 08:56 AM
From: Syed Hassan
Subject: App Connect - Message Flow to handle mutli

Thanks for your response,

Scenario is :

Message Flow - TEST.msgflow has HTTP Input node with url (/test/v1/sample/) and we need to accommodate new API request which will be exposed by either new flow or same flow with new url(/test/v2/sample/).

Note: we need to keep untouched to existing url(keeping that url and flow functionality) as it is since it is still be used by clients.

So, creating new message flow say. TEST.2.0.0.msgflow with new url and copying most of functionalities from existing and implement new feature on it ?.

This way, we are not disturbing existing (/test/v1/sample/) request and adding new Message flow for (/test/v2/sample/) and it will he good for maintenance and trouble shoot.

If required, its easy to retire older version message flow with out disturbing new version.

Also Could you recommend adding version number like 1.0.0 or 2.0.0 in the end of the new Flow names as we progress with new api urls/versions ?

Example - TEST.1.0.0.msgflow, TEST.2.0.0.msgflow

Thanks.

------------------------------
Syed Hassan


Original Message:
Sent: Tue January 12, 2021 05:31 AM
From: Matthias Jungbauer
Subject: App Connect - Message Flow to handle mutli

Depends a little bit of how many changes in a year you expect and how many path you have to handle and what the growth rate of additional paths is..
I would put a parameter like the path into a CMDB
Something that can be changed without deploying a flow and without executing mqsiapplybaroverride

If you work with CMDB, something like Service Now could change the path without manual IT work.
It would be self-service for your message flow clients.


------------------------------
Matthias Jungbauer