Yes indeed, your solution looks really cool.
From my experience with BizTalk, such visual tools really help move to the next level of developer experience.
Let me pass on some of my user experiences to help move BizTalk to the next level on the functionality aspects as well.
They are as follows:
1) Enhancements on Publish Subscribe Model. (PAS)
The success of any PAS based EAI/ESB product depends mainly on the flexibilities which can be incorporated within.
a) in case of the receive shape in the orchestration, where we filter, we need to have a "XPATH" based filter option, wherein we can filter on exact XPATH conditions in the UI.
CBR based Subscription is increasingly being done inside an orchestration, whereas it can be effectively handled at the receieve shape - namely - triggering of an orchestration itself.
b) when we have a straight forward flow, say from a receive port to a send port via filter subscription, there should be a capability of 'return subscription'.
Let me explain further:
when we have a send port subscribed to a receive port - via the receive port's name, in the Filter & Maps tab of the send port, if there is a successful send, there should be a possibility of returning an ACK back to the receive location. This can be a 'K' file with the same name as the original file.
E.g: if 'file123.txt' is polled for, the K file sent back is 'file123k.txt'
c) There should be options to programatically add filters to an orchestration via API calls. This will help as follows:
if we have a 'K' file which is the trigger file and there is this another data file. Now once we receive the K file, we should be able to subscribe for the actual data file, which again differs in its naming only by one letter as shown in the example above.
This way, there can be more flexibility within BizTalk to enable a cleaner handshake and in terms of reconciliation and strict process control.
d) subscription should also be extended to the receive port. In case of two distinct receive locations, linked to two different receive ports, port A, if it is receives a message, should be able to trigger a subscription on port B and if required be able to pass some macros like %SourceFileName% etc.
With regard to point d) - the way i look at it, BizTalk should be able to create subscriptions for all artifacts including receive ports and also pipelines.
It would be really amazing to have a GUI as you have shown in your video and a way to subscribe one component to another via the GUI.
- I understand GUI is an essential part, but going by the way the industry is evolving, BizTalk needs to have a highly flexible and robust PAS model to emerge as the market leader.
Hope this helps in some way. Please provide your inputs to firstname.lastname@example.org