[BUG] Operation IDs are not identical in SOAP service deployment

[davidliuhca]

Release version

v2.X

Describe the bug

Once deployed a SOAP service to another APIM instance (say Stage), the operation IDs are different from the original APIM(say Dev). This will cause errors when Publisher try to deploy the operation level policies.

The root cause is: the Extract creates operation folders under the API folder by using the operation IDs (for Soap service, operation id is GUID), and puts the policy files to these folders. When publishing, the operation IDs will be different as they are GUID. So publishing operation policy will fail because it's based on the operation ID.

Expected behavior

Publish the whole API along with the policies in each operation.

Actual behavior

Failed to publish operation policy because the operation ID doesn't exist.

Reproduction Steps

1. In the APIM DV, pickup a SOAP service, add some policies to some operations.
2. Extract and Publish

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[waelkdouh]

Please update to the latest release and let us know if the issue persists.

[davidliuhca]

I downloaded the newest version and tried, unfortunately I got the same error

[waelkdouh]

Did you search the issues (both open and closed)? I recall seeing something related to soap.

@guythetechie any thoughts?

[guythetechie]

See #399. If you import a SOAP specification file, APIM generates new operation IDs. We don't control this behavior, and there's unfortunately no clean solution.