I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

The question I asked before was strictly for how to initialize global configurations required for every API. We ended up with a UDP "init-config" which hard codes very few global variables by using context.set(key, value) without a json file. These global variables are stable but different for each environment. It may not follow the best practice but works effectively for my use case. Hope this helps. Zhifeng

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

The question I asked before was strictly for how to initialize global configurations required for every API. We ended up with a UDP "init-config" which hard codes very few global variables by using context.set(key, value) without a json file. These global variables are stable but different for each environment. It may not follow the best practice but works effectively for my use case. Hope this helps. Zhifeng

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Hi Pratap,

Catalog properties as noted in an earlier post are resolved at publish time.  As far as the gateway is concerned, it receives configuration that has a static value, the value of the catalog property.  I can't speak to what you are doing with a JSON file, but the file needs to be pushed to the gateways although I've seen some clients do that directly and not within the context of an API publish.  I believe I also noted earlier that once the file is one each gateway's filesystem, for performance it could be cached so the file isn't read every time the API executes, but then that of course would require a mechanism to expire the cache, forcing the file to be re-read and re-cached with hopefully updated values.  I believe I also mentioned distributed variables as another mechanism where each variable would have its own expiration, and the distributed variable would be shared across all Gateways in the cluster whereas document cache would have values and expirations unique to each Gateway instance.

Best Regards,

Steve

The question I asked before was strictly for how to initialize global configurations required for every API. We ended up with a UDP "init-config" which hard codes very few global variables by using context.set(key, value) without a json file. These global variables are stable but different for each environment. It may not follow the best practice but works effectively for my use case. Hope this helps. Zhifeng

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?

Hi Pratap,

Catalog properties as noted in an earlier post are resolved at publish time.  As far as the gateway is concerned, it receives configuration that has a static value, the value of the catalog property.  I can't speak to what you are doing with a JSON file, but the file needs to be pushed to the gateways although I've seen some clients do that directly and not within the context of an API publish.  I believe I also noted earlier that once the file is one each gateway's filesystem, for performance it could be cached so the file isn't read every time the API executes, but then that of course would require a mechanism to expire the cache, forcing the file to be re-read and re-cached with hopefully updated values.  I believe I also mentioned distributed variables as another mechanism where each variable would have its own expiration, and the distributed variable would be shared across all Gateways in the cluster whereas document cache would have values and expirations unique to each Gateway instance.

Best Regards,

Steve

The question I asked before was strictly for how to initialize global configurations required for every API. We ended up with a UDP "init-config" which hard codes very few global variables by using context.set(key, value) without a json file. These global variables are stable but different for each environment. It may not follow the best practice but works effectively for my use case. Hope this helps. Zhifeng

Hi Zhifeng,

I am exploring with the same requirement and had few queries, hope you could you put some info here. 

1. I am assuming you are pushing the Json file(config) using the UDP from APIC and does some changes on the file in Data Power, does the changes persist in the APIC lifecycle?
2. Another case You just placed the config json file in DataPower directly and the UDP only does the calling this file for data, in this case if you do the changes on the file does the data persist the apic lifecycle?

Or if your approach is otherwise, could you pls share some info or sample to view.  Thanks.

Steve, thanks for your advice. That makes sense. Best regards, Zhifeng

Hi Zhifeng,
You could have your json file added to your API Gateway document cache policy so it would not need to be read from the file system each time.  That would require a gateway extension override json file to persist this change to the API Gateway object across all of your DataPower appliances in the service.  Another approach would use distributed variables which was introduced in DataPower 10.6.0.0.  Using an xslt you could store the file with an expiration, and when you attempt to read the file from the distributed variable, if you don't get a response you can read it from the file system and save the json object back to the distributed variable.  Your json file updates would be made live the first time you read the file from the file system.  You could also set your context variables in the xslt, just know that in xslt the JSON will need to be converted to JSONx so you can XPath properly to get the values.  Unfortunately, although you can use distributed variables from GatewayScript too, it does not have the expire argument on the set function which is why the xslt is the recommended approach for distributed variables.

Best Regards,
Steve Linn

I have a question how to manage catalog or domain wide properties which are shared by all APIs in the same domain.

Initially I tried to use the catalog properties and set-variable policy so that these properties become context variables for each API. But I read the note from IBM APIC Documentation that if the catalog property changes we have to re-publish each API.

Then I decided to develop a UDP which reads key value pairs from a json file and sets these properties as context variables. This UDP is used by all APIs which depend on these properties. If there is a requirement to change the properties we can simply update the json file without re-publishing each API. But I am concerned now with the potential performance impact. With this UDP approach, in run time does each incoming request trigger the process of reading the file and loading properties into the context? These properties are constants and do not change most time.

Is there any better way to manage the domain or catalog wide properties which can be accessed by each API and properties can get updated without requiring each API?