[BUG] Product for multiple APIs are not getting deployed through publisher pipeline

[nehaapr28]

Release version

v4.1.0

Describe the bug

in my DEV environment, few APIs are associated with the same "product" when I am doing the deployment for higher environment, its considering only the given API in "artifact folder" and in target environment, others APIs not showing up to connect with this product.

Please see the atta

ched image of dev environment where product "cxp" is associated with multiple APIs

See the attached image for QA when we deployed the APIs

then in QA, under this product only one API is displaying

Expected behavior

like dev, in QA also under the product all associated APIS should be displayed

Actual behavior

in QA, under product only one API is displaying

Reproduction Steps

if needed I can attach the config file here.

[guythetechie]

Hi @nehaapr28 - this behavior is expected.

If you tell ApiOps to only export specific APIs, the extractor will only extract product/api associations that contain the listed APIs.

When the publisher then runs, it sets the product API association to what's defined in the extracted JSON. That means APIs not associated with a product in code will be removed from the product in APIM.

I can see why this behavior is not ideal. We'll discuss internally whether it should change. Keep in mind though, the ApiOps philosophy has Git as the source of truth. Our tool is designed to make your environment mirror what's represented in code.

[DSpirit]

This issue just happened in a scenario with more than 100 API's losing their product - almost a disaster if it wouldn't have been noticed on TEST already.
I know the gitops philosophy here, but unless I explicitly delete something (on commit level) I don't want things to be removed. One simple and logical alternative could be to switch the API Products assignments to API level and not on product level.

[hscheffert]

+1! I had a similar close-call as @DSpirit last week and I'm now struggling to figure out how to manage the APIs within the Product for upper environments.

[trdrake-tw]

I think there's a pattern of usage (which i believe was suggested by MS to the team i work with) where we have one API per-branch. This definitely breaks this, because the product.json file in one branch is considered to have the complete set of APIs assigned to a product, and it performs a replace, not a merge. We've somewhat solved this by having a separate "Product" branch where the product-API mapping is extracted to. This, of course, is now a cyclical dependency, which is it's own - but more manageable - drag.

[guythetechie]

Thanks for the feedback. After internal deliberations, we've landed on this approach.

Current behavior

• Product APIs are stored in products/productA/apis.json, where apis.json looks like

[
  {
    "name": "apiA"
  },
  {
    "name": "apiB"
  }
]

• If products/productA/apis.json was modified in the commit, the publisher
  • Associates APIs in apis.json with the product. In the example above, apiA and apiB will get associated with productA.
  • Removes any associations to the product for APIs that are NOT in apis.json. In the example above, if apiC is currently associated with productA, that association is removed.

New behavior

• Product APIs are stored in products/productA/apis/apiA/fileNameTBD.json. fileNameTBD.json will be an empty JSON object for now.
• When the publisher runs
  • If products/productA/apis/apiA/fileNameTBD.json was added in the Git commit, apiA is associated with productA.
  • If products/productA/apis/apiA/fileNameTBD.json was deleted in the Git commit, the association is removed.

This is a BREAKING CHANGE, but the behavior will be more consistent with that of other ApiOps resources. Would love to hear any feedback.

[guythetechie]

@trdrake-tw - Could you elaborate on your scenario? We've seen ApiOps used with various branching strategies, but one API per branch can get unwieldy very quickly.

[trdrake-tw]

I would agree, but it's the approach we've been asked to take. @mihirsurting, in the linked issue (#295), might could comment.

[shawnmurtagh]

This is a problem for teams with operator repositories because APIs have to be deployed before the products can be deployed. It forces this:

1. deploy the operators repo: resources like namevalues

2. deploy the api repo: with no product

3. deploy the operator repo again: product with an api assignment
   This requires a costly ceremony to release new APIs and products that we don't have to do with other resources that deploy like this:

4. deploy the operators repo: * service-level resources

5. deploy the api repo: with the product assignment

While I understand it may make more sense to match the management API in terms of maintainability, the consumer of APIOps doesn't use the management API. We consume the APIOps tools. I will say it is painful to remember and teach my team "it works one way unless it's a product, then you have to do a special thing."

[seilorjunior]

@guythetechie do you have any news about that?

[vinilka8]

Hi @guythetechie,

How long will take to release this feature, I can see it's been under review since the 30th of April,

Thanks,
Regards

[waelkdouh]

we just tested under v6.0.0-rc1 and the issue has been resolved. Please test and let us know.

[username-anonymous]

I have to associate products with Apis in APIOps and using "APIOps Toolkit for Azure APIM v6.0.1.1" latest version hoping it contains fix for this issue and Product APIs are being stored in /artifacts/products/productName/apis/apiName/productApiInformation.json. After running publisher it's successful but products don't get associate with Apis.Can someone share the fix if this has been resolved and does v6.0.1.1 contain fix for this issue?