To move code from a development environment into a testing environment, I perform the following actions:

1. Execute a broker_save for my broker. This creates an ADL in the DEV environment.

2. Manually edit the ADL to reflect the parameters of the target environment. This includes changing the broker host parameters and database instances, setting the adapter processes’ “enabled” property equal to “true”, etc.

3. I check the ADL into my version control system and deploy to the target environment.

4. In the target environment, my webmaster performs a “broker_load” on my ADL and starts the Broker (and adapters).

Here is my question: Why do some components build in the new environment and others require manual intervention to be built?

Obviously, the integration fails if the components are not built. I am not comfortable using the Enterprise Integrator to affect the Broker once deployed. This discomfort will be much worse when I move from testing into production.

Any thoughts?

There is no reliable way to do this. Greg Frohring who used to be with webMethods PS wrote us a command line rebuild tool but we haven’t been able to get it working consistantly. We have resorted to just doing the rebuild after any promotion to a new environment.
We worked with webMethods on this issue and told us it was addressed in 5.0 and it would take almost a rewrite of the broker_load to fix the problem.

Hmmm… We are using Enterprise Server 5.0.1 with the latest patches and we face this issue with each broker_load nonetheless.

That’s disturbing to hear. We are repeatedly told that issues we are facing in 4.1 are fixed in 5.0 and that we should upgrade. Wonder if they actually are???

I got this response from webMethods support. Thank you to Sunil for getting the engineers to give such a thoughtful response.

[begin explanation]
Let’s say you have three objects, A, B, and C. A and B are Integration
Components and C is some support object like an event signature or an
operation. If you export A to A.adl and B to B.adl, both .adl files will
get a copy of C.

Load A.adl and you get A and C in the broker. So far so good. Now load
B.adl and the loader notices a dependency of A on C. The rule of thumb is that
unless you can prove that the change to C does not affect the built A, A gets
marked for rebuild.

Unfortunately the code is not at all aggressive in trying to determine if
the rebuild can be avoided, so lots of “extra” rebuilds get marked in all the
shipping versions. We looked at the price of an extra rebuild (click one
menu item) versus the price of not rebuilding something that needed it
(inconsistent run state) and let caution be our guide.

Over time the loading code will incrementally learn cases where not
rebuilding is safe. We’ll introduce these deliberately to ensure we never make the
opposite, much more damaging, error. Currently the only one it allows is a
perfect match, including all cross-references and dates.
[end explanation]

Support capped the email to me with a note that they are testing a new tool internally that forces all components to rebuild on a broker. The software is currently in Alpha, I think, and will be available as GA in due time.

I will try to get a hold of the “Build All” software and test it here for everybody.

Thanks Dan, We are continuing to pursue from our side as well so hopefully we will get something usable soon.

As an addendum:

We did get a hold of the Broker Build All tool from webMethods. It was largely experimental (read: buggy) when I used it although it is possible that webMethods has improved upon it in the past 10 weeks.

Rather than depend on the tool, we did manage to find a fairly quick workaround.

Note: You must make the “Script” tab visible for these steps. Use “Edit > Preferences > Expert” to make the tab visible.

For each component in each of your Integration Folders, select the Script tab and then add a plain space character to the first line of the component code. When you select the next component in the folder (or in another folder), the component prior will be marked with the Hammer icon.

After stepping through all of your components, select the “Build All” icon in the menu bar and the job will be complete.

The solution violates good programming techniques (i.e. not modifying code in Production) but I have not found a more reliable solution for ensuring the Build of all components.

Comments are appreciated from the group.

I will post this in the forums, too. Let me know if you need any more assistance, okay?

Best wishes and warmest regards,

Thanks for the great information!
Please tell me that we won’t have this issue with version 6…(?)

Regards,

Wayne

There is a utility that does a build of all components with ES 5.0.1. The syntax is broker_buildall -force Broker@hostname:port
You could add a -output to do it in verbose

my build tool did work btw. It recompiled all of the script java classes and put them into the runtime byte code infosets… Not sure what Entergy was doing with the tool. Worked 100% when i used it!