Hi,

I’m on version 9.9 and Deployer Fix2.

When I create a BPM Deployment Map for a new BPM process, its dependency check fails, which is expected as I have not yet deployed the corresponding package.

However, after deploying the package, the dependency check still signals the same error and the deployment cannot go through as it will not find the process services it needs (although they have been deployed a few minutes before).

If I reload WmDeployer, the dependency check now passes without errors and the process can be deployed without issues.

There is no mention of this error in the Knowledge base or the readme of new Fix3.

Has anyone seen this error before?

Best regards,

If this is consistently reproduced and by reloading you don’t see this happening, it could be a bug. Pls log a SI with support…

Regards
Senthil

Hi,

I have seen this behaviour on 9.5 SP1 too.

Workaround:
create map for services
create candidate for services
deploy it
create map for bpm
creatce candidate for bpm
deploy it

I usually have two packages when it comes to bpm models:
one for the service implementation and one for the bpm-generated wrapper services.
these wrapper services just call the services in the first package.
the bpm package should have a dependency on the first one to maintain load order of these.

The first package is then deployed as a regular IS&TN set and the second one will be part of the bpm deployment by setting the package to add while resolving dependencies.

This procedure eases maintenance as it is not always required to deploy bpm when there are just some small chnages in underlying logic. Additionally if the bpm generated package gets corrupted ot deleted accidentally, just rebuild the model in designer and the package will be recreated/repaired without losing implementation details.

Regards,
Holger

Hi,

@Holger, yes that is also my strategy.

I find more secure to have just one build with all the elements and then, several deployment maps.

In my project’s current development phase it ensures all the elements are in sync (even if it implies some duplication and unnecessary deployments).

@Senthilkumar, I’ll be gathering more data before submitting this issue.

Thank You all,

Best Regards