products versions - {webMethods.io Integration 10.16.5.0}
Introduction
A colleague and I are on-site at a Software AG customer. We did a webMethods.io deployment on December 4th, 2023, into the customer’s target wM.io environment.
To deploy our wM.io Integration solution, we used the built-in Project deployment feature.
An issue occurred that took us awhile to figure out. The article summarizes how we did the deployment, the issue we ran into, and the solution.
wM.io Integration Project Deployment Feature
The feature is available from within wM.io Integration to copy/deploy Project assets from one environment to another.
The Publish / Deployment is done in two steps. In the source environment, you Publish Project. This enables you to select assets to deploy to the target environment.
Once you are done this step, you need to login to the target environment and finish the deployment. If there are Projects ready for deployment you will see them with the text “Deployment available from << source environment>>”. For example:
Click the tile to finish the deployment. The deployment wizard (UI) will let you configure assets for the target environment (e.g. connector account info, parameters, etc…)
In our case, the Publish was successful, but the deployment to the target environment failed.
The Error
Our Project is made up of multiple wM.io Integration FlowServices. Some services call other services in the Project.
In our case, this is the error we saw trying to deploy to the target:
The error says “The Flow service ‘getOutputFileFormat is not available in the zip file but it is referred to in other Flow services”.
A zip file is mentioned since under the covers when you do a publish a zip file is generated and used to deploy. In the Publish / Deployment capability, you don’t have to deal with these files since the UI/application takes care of it.
The Investigation
In our case, we have a Flow Service called getEmpData that calls getOutputFileFormat.
We couldn’t figure out why getOutputFileformat was not in the zip for deployment, since we selected it to be deployed and it is in the same wM.io Integration project.
The deployment was almost completed but without getOutputFileFormat the solution could not function.
The Problem and Solution
Since the error said the zip file was missing, we decided to manually export getEmpData and investigate the zip file contents.
That produced a zip file in my Downloads folder called getEmpData.
This zip file contents are very similar to what you would see if you archived a webMethods IS package in the on-premise world since under the covers, the Flow Service source code is in flow.xml files.
One of the differences you’ll notice is unique identifiers for the exported namespace, including Project a project reference identifier.
This is important as we discovered later.
Here is our getEmpData Flow service:
You may have noticed in the screen shot above, there is no folder for getOutputFileFormat. It should have been there since getEmpData depends on it.
We continued to scratch our heads.
We then opened flow.xml for getEmpData since it contains “INVOKE SERVICE” steps for each service it will invoke.
Notice the invoke steps?
Do you also see the reference to the project location for the service? They are all the same except for getOutputFileFormat.
The reference should be the same since the Flow Service is within the same Project. On the import of the zip file, the deployment was confused since the reference numbers were different.
How did this happen? After discussing with Software AG they indicated it could be the code that was copied and pasted. We aren’t sure how it happened but we had to fix it.
Somehow the reference ID to that getOutputFileFormat was wrong in the XML file
To solve the problem, we
Edited the getEmpData FlowService
Deleted the call to getOutputFileFormat.
Saved getEmpData.
Added the call to getOutputFileFormat back into getEmpData.
Saved the change.
To verify, we exported getEmpData again, and this time the zip file contains getOutputFileFormat.
And, if you look at the flow.xml for getEmpData you will see the invokes all have the same project reference ID.
Finally, we deployed getEmpData again and this time it included getOutputFileFormat, and the deployment was completed.
Keep this in mind if you run into issues like this during a wM.io Integration deployment.
Regards
Wayne
Senior Integration Architect
Persistent Systems
Software AG Business Unit
