Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

Correct, for your use case the "Online" toggle is irrelevant.

What I would do to troubleshoot your "Backside URL Invalid" error is either check DataPower logs or make use of Tracing feature in Test tab as I mentioned earlier.

As for your use case, I would explore alternatives to creating multiple catalogs for this pattern, as they are going to be nightmare to manage in the future. For differences between back-end applications I would leverage API assembly to know which back-end to route the request to. For different front-side applications - APIC Applications and Subscriptions to relevant products. That being said, I don't know all your requirements, so it's up to you to decide how to better address them.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

Hi Thanks again for the quick reply. Do you have any documentation pointing to the API assembly routing ? I am still very new to APIC and didn't realize it had something like this. Thanks !

Correct, for your use case the "Online" toggle is irrelevant.

What I would do to troubleshoot your "Backside URL Invalid" error is either check DataPower logs or make use of Tracing feature in Test tab as I mentioned earlier.

As for your use case, I would explore alternatives to creating multiple catalogs for this pattern, as they are going to be nightmare to manage in the future. For differences between back-end applications I would leverage API assembly to know which back-end to route the request to. For different front-side applications - APIC Applications and Subscriptions to relevant products. That being said, I don't know all your requirements, so it's up to you to decide how to better address them.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

There's no single way of achieving this. It all depends on specific requirements and what is the differentiator of the requests. Simplest way would be to leverage switch policy, provided that differentiator of the back-end is already available in the message (i.e. in a header).

You can read more about assembly policies in general here:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=definitions-api-policies-logic-constructs

Switch policy:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=constructs-switch

Basics of using context variables:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=aplc-using-context-variables-in-gatewayscript-xslt-policies-datapower-api-gateway

List of available context variables (for selecting routing differentiator):

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=reference-api-connect-context-variables

Hi Thanks again for the quick reply. Do you have any documentation pointing to the API assembly routing ? I am still very new to APIC and didn't realize it had something like this. Thanks !

Correct, for your use case the "Online" toggle is irrelevant.

What I would do to troubleshoot your "Backside URL Invalid" error is either check DataPower logs or make use of Tracing feature in Test tab as I mentioned earlier.

As for your use case, I would explore alternatives to creating multiple catalogs for this pattern, as they are going to be nightmare to manage in the future. For differences between back-end applications I would leverage API assembly to know which back-end to route the request to. For different front-side applications - APIC Applications and Subscriptions to relevant products. That being said, I don't know all your requirements, so it's up to you to decide how to better address them.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

There's no single way of achieving this. It all depends on specific requirements and what is the differentiator of the requests. Simplest way would be to leverage switch policy, provided that differentiator of the back-end is already available in the message (i.e. in a header).

You can read more about assembly policies in general here:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=definitions-api-policies-logic-constructs

Switch policy:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=constructs-switch

Basics of using context variables:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=aplc-using-context-variables-in-gatewayscript-xslt-policies-datapower-api-gateway

List of available context variables (for selecting routing differentiator):

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=reference-api-connect-context-variables

Hi Thanks again for the quick reply. Do you have any documentation pointing to the API assembly routing ? I am still very new to APIC and didn't realize it had something like this. Thanks !

Correct, for your use case the "Online" toggle is irrelevant.

What I would do to troubleshoot your "Backside URL Invalid" error is either check DataPower logs or make use of Tracing feature in Test tab as I mentioned earlier.

As for your use case, I would explore alternatives to creating multiple catalogs for this pattern, as they are going to be nightmare to manage in the future. For differences between back-end applications I would leverage API assembly to know which back-end to route the request to. For different front-side applications - APIC Applications and Subscriptions to relevant products. That being said, I don't know all your requirements, so it's up to you to decide how to better address them.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.

You just opened up a whole new world for me. Yes, the differentiator can be made available via client application on the request header. So, is there a way to dynamically construct target url based on it ? for example, in my api.yaml:

assembly:
  execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $({edit this to something like https://blah.blah.differentiator:8080})$(api.operation.path)

Can I hardcode parts of URL here and append the differentiator ? how does that work ?

 

There's no single way of achieving this. It all depends on specific requirements and what is the differentiator of the requests. Simplest way would be to leverage switch policy, provided that differentiator of the back-end is already available in the message (i.e. in a header).

You can read more about assembly policies in general here:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=definitions-api-policies-logic-constructs

Switch policy:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=constructs-switch

Basics of using context variables:

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=aplc-using-context-variables-in-gatewayscript-xslt-policies-datapower-api-gateway

List of available context variables (for selecting routing differentiator):

https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=reference-api-connect-context-variables

Hi Thanks again for the quick reply. Do you have any documentation pointing to the API assembly routing ? I am still very new to APIC and didn't realize it had something like this. Thanks !

Correct, for your use case the "Online" toggle is irrelevant.

What I would do to troubleshoot your "Backside URL Invalid" error is either check DataPower logs or make use of Tracing feature in Test tab as I mentioned earlier.

As for your use case, I would explore alternatives to creating multiple catalogs for this pattern, as they are going to be nightmare to manage in the future. For differences between back-end applications I would leverage API assembly to know which back-end to route the request to. For different front-side applications - APIC Applications and Subscriptions to relevant products. That being said, I don't know all your requirements, so it's up to you to decide how to better address them.

Thank you very much for the response ! I have checked the target url and it is valid. So, it looks like what you are saying is the "online" toggle switch is irrelevant for my use case since I am using my own catalog of my choosing correct ?

Also, we have somewhat of an atypical use case where where there are some environments on demand that gets spun up via Jenkins env up. So, each of those instances need to communicate with separate instances of another application via APIC. Therefore, the need to create catalogs "on demand" and publish api (with different target urls) and products to each of them. The catalogs are just a way to namespace this mapping between the 2 instances. 

What you are saying makes sense though because when I go into the catalog and browse my product and APIs they all say "active". Not sure why I am getting "Backside URL Invalid" error when invoking via postman.. I will look into debugging this. Thanks !

Hi Srini,

When you are creating a draft api and draft product, they are always created as offline and when you activate them, they will by default always be published to Sandbox catalog. If your goal is to just publish the API in the catalog of your choosing, then your product should already be active in that catalog, therefore step 5 is not needed.

That being said - when you develop your APIs/Products, "Develop APIs and Products" is the perfect place for troubleshooting. By default it uses auto products and Sandbox catalog with default consumer org and automatic subscription. When you use Test tab, it gives you the ability to see the trace of your API call execution, which is helpful in troubleshooting.

The error "Backside URL invalid" might be due to invalid URL in invoke policy, so you would want to check that URL in the first place.

If you want to troubleshoot this issue further in the target catalog, you would either need to go through DataPower logs, or set up an API probe to get the same level of information as in "Test" tab in "Develop APIs and Products".

I'm also curious about your scenario for steps 2,3 and 4. Usually you would want to have a single catalog that is exposing your APIs to Consumers in a single Developer Portal.