Hello tech community,

I’m using webMethods 10.5 and Cloudstreams for Google Cloud Storage, with a customer license, but ran into an issue in Deployer.

When promoting code to a test environment, Deployer has reported an error with the Cloudstream Adapter Services because they are unchanged. ?
Deployer then rolled back the update.
The deployment package was successfully deployed to two lower environments before this error occurred trying to reach the UAT environment.

Deployer output:

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/0b93b16b37e231ac352866a195968d6dc3131482_2_1035x316.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/0b93b16b37e231ac352866a195968d6dc3131482.jpeg 2x" data-dominant-color="DFD7D0">

image1319×405 199 KB

I’d like to identify if this issue is something I can control in the build or deployment process, or if the problem is in the deployer IS or target Integration Server?

Any and all help is appreciated.

Cheers,
Graham.

Hi Graham,

is this the first time the code should be deployed to ther target instance or is this an update to existing code?
From the messages I assume the second variant.
Were the lower environments fresh deployments or update deployments?

Please check if you have applied the latest Fixes for Deployer as well as updating the WmDeployerResource package(s) afterwards.

When these parts are unchanged code you can omit these parts during define phase of the deployment and only deploy those parts which were definitely changed.

Regards,
Holger

Hi,

This wasn’t the first deployment to this environment, but I also retried today by deleting the package before re-deploying. The result was the same.
The lower environments have been deployed multiple times without issue.

After the error is captured, deployer rolls back the “new” package, saving a copy in replication/archive directory.
I copied that zip file into replication/incoming and through the UI, installed the inbound release which loaded the package successfully.

I believe this narrows it down to something specific in deployer.

No Deployer fixes have been applied. Both the deployer IS and target IS
I checked SAG site and found DEP_10.5_Fix7 is the latest. The release notes don’t mention any fixes that correlate to this issue, but I’ll see if we can test this next week.
I wasn’t able to find the WmDeployerResource package - could you point me to a link, search term or page title?

Lastly, our deployment is for the whole package as this is a new package not yet in Production. It’s receiving updates in the testing environments prior to final release.

Cheers.

Hi Graham,

WmDeployerResource package is not installed by default, but you install it through Deployer from the IS Server page.
Select the server to which it should be deployed and click the “Install” button.
This package is at least required when you plan to use Runtime-based deployments which were the default before Repository based deployments were introduced.

The version of the WmDeployerResource package needs to match the FixLevel of the Deployer itself when it is used.

Regards,
Holger

Thanks, Holger, it’s been a while since I configured deployer - turns out the wmDeployer pkg was up to date.

I was pointed to a cloudstream fix - WST_10.5_Fix26 - to solve this. The fix notes include:

WST-5430
Deployment of packages with Cloudstreams components are failing.
Deployment of connector services without any changes specified in variable substitution will not log an error any more in target server.

So far I have gone with a workaround - following the failed deployment, the new package is in replication/archive and I can copy it out to incoming and then install inbound release from the IS web GUI. I’m doing full package releases at the moment, so this works for me - not sure if it would work if deploying a service based / incremental release.
I will apply the above Cloudstream fix to resolve the issue properly.

I believe if you have the CloudStreams Deployer Package installed in IS this will occur. It was happening for us in v10.7 and once we deleted the CloudStreams Deployer package the errors went away. It’s not needed.