WebMethods 61 Developer New User Frustrations

<quote>From Haithem Al-Salam:
I think a healthy balance of OO best practices mixed in with the straight forward linear/sequential nature of flow can produce great results.</quote>

If one could only use OO best practices I would be happy. As a Java developer I often want to apply OO practices but fail because of the way webMethods works.

I wish I could treat packages as classes and create subclasses in order to reuse common behaviour. If a package can be used for two separate instances of an end system but one end systems require minor modification to a mapping one needs to duplicate the whole package, which creates duplicated code for all the flows that do not need to be changed. Does anyone have an webMethods best practice for this kind of situation?

Furthermore it is not even possible to develop on two separate versions of the same package (e.g. head and a branch) because it can only exist once in an IntegrationServer.

Hello Ulf,
I think that is nice and I try to do this even with the linear environment.
When I work with flow mappings, I take a distributed approach to processing. I design a root flow map that does the initial settings to a canonical form for all possible instances. Then I create implementation flow maps that will call the root maps I need in any one particular case. I end the implementation map with a common solution flow map that will give the desired result for the implementation. It is somewhat like refactoring your flows. An example:
{{OLD}}
flow1forCompanyA

  • seq1
  • seqA
  • seq#

flow1forCompanyB

  • seq1
  • seqB
  • seq#

{{NEW}}
flow1

  • seq1

flow2

  • seq2

commonFlow

  • seq#

flowCompanyA

  • flow1
  • seqA
  • commonFlow

flowCompanyB

  • flow1
  • seqB
  • commonFlow

I have created more flows, but I don’t have duplicate code to run around and check for typos. The root and common portions are similar as one is for preProcessing and the other is for postProcessing. The commonFlow, as I have found, can stretch across a far wider base of maps than the roots so I distinguish it. Each implementation only worries about the code that uniquely transforms some data sets. Thank is my somewhat object approach on the data side.

One great thing is that because I standardize my inputs and outputs between each of the flow groups, They all have implicit variable mappings throughout the flow, I just plug in the need functions and set up one map step at the end that deletes lingering variables.

I would guess a similar approach could yield effective results for flows used for other purposes. This is not a framework though, so maybe poking around other places here or advantage may yield better results.

Quoting you Ulf:
Furthermore it is not even possible to develop on two separate versions of the same package (e.g. head and a branch) because it can only exist once in an IntegrationServer.

WM is quite usable with small teams and well-factored-out packages, but what you said is a drawback for large teams. However, this process might work for them:

  1. Multiple IS instances can be the answer – each developer working on his own instance.

  2. Changes automatically determined by a program that compared each instance to the SCM version.

  3. This program exports patch packages (reverse-engineering process used by ‘Packages > Publishing > Create Release’)

  4. When build needs to be created, patch packages are built and sent to a build server.

  5. A codemaster merges the changes to create the build.

  6. Build is tested.

  7. After testing the build, a similar process runs on the build server to generate packages for export to UAT and prod servers.

This needs some reverse engineering of the current WM process, but would work as developers make changes to different services and their changes are not co-dependent.

It all would be much easier if WM created SCM interfaces to CVS and the like, as well as tools to visually “diff” and “merge” IS services.

Correcting the second last paragraph of my post above, it should really be:

[this process] would work if developers make changes to different services and their changes are not co-dependent.

Hi
In the IS built in services whats the use of default and null values in the LABEL part of each of the built in services?
whats does that signify?

$default and $null are labels that you can use when working with BRANCH.

If you need to execute a service according to the value of a given string (str), you use BRANCH :

BRANCH /str

  • ‘a’ -> will be executed if str = ‘a’
  • $null -> will be execute when str = nulll
  • $default -> will be executed if no labels match str

Hi,

Following the try-catch discussion: If my flow generates an exception, and moves to the catch-sequence, how can 'n get the original exception message for me to relay the message, say to TN. Because the exception message is not stored anywhere in the pipeline as far as I can see.

Thanks

DJ

Never mind. pub.flow.getLastError was the answer.

In developer 6.5 I have written a DSP page which calls a service, I want to show the output of that service from one DSP to another DSP when I invoke the DSP.I have created one flow service and i invoked that service using the tag “%invoke%” and %endinvoke%.But i am not able to get the output.Can you tell the procedure?

“Agree. The concept is good. But we are also programmers,…” Hum? Are you sure?

how we can give runtime input through switch in branch flowstep in webMethods developer .