Programatic generation of the flow

Hi all,
This may be one of those SNQ (stupid newbie question):

We have a inhouse utility developed in JAVA. This utility generates JavaBeans that can be utilized by web-applications for legacy data access. The objects generated by this utility will be used in future in WebMethods. We dont want to lose the investment we have made in this utility SO we plan to extend this utility to generate the webmethods flow components that will be imported into the webmethods environment and used by the developers to create new flows.

Good idea , Bad idea - wrong direction - please comment.

Alternatives ? Please note that we have budgetry & time constraints.

Thanks in advance for your response,
Rajeev Sakhuja

I think you answered your own question here. Although you could use webMethods to get the data from the legacy application, it seems that you are already using a tool that creates an API to the legacy data, and seem to have no plans of changing the solution.

The only (minor) downfall I see in this solution is simply the management of documents across two solutions as opposed to one.

Anyone else see something?

Thanks for the response.

My main question is :

Is it a good/bad idea to generate the Flow (XML) externally and import into the webmethods environment ? In other words, the programmer will not use the developer to generate webmethods components accessing the legacy data, instead they will execute a tool that will generate the webmethods-component (package) that will be pulled into webmethods. The input and output for the execute flow services (legacy data access) would be WM-native in-document & out-document resp.



From my point of view it is not really a good idea to generate flow (XML) externaly because i guess there is no documented standard way to do that. Which means XML definition can change any time which could create some problem. Also you need to understand the XML yourself and set lot of assumption which is not good.