[Feature] Update a KPS table

[wsalembi]

User story Some APIs need updates in KPS tables. Swagger promote should support a generic way to specify a KPS table and properties so it can do the insertions/removals. (The key of the KPS table is always the api.id field.)

Additional context

[cwiechmann]

I think this is something which should be handled by a pluggable mechanism. It shouldn’t become are core-function of Swagger-Promote. Instead a plugin is created according to a defined interface, which is configured to be executed at the right times by Swagger-Promote. I’m thinking about multiple positions/times to hook in plugins, for instance at the beginning to do some additional validation, or in the middle (e.g. create an Org not present yet) or finally at the end to do some kind of post-processing (e.g. KPS-Update). The plugin itself declares at which positions/hooks it wants to be called.

Ultimately I would appreciate to see then plugins popping in into the Main-GutHub project so that other customers can leverage them.

What do you think?

[cwiechmann]

Created a dedicated feature-request Axway-API-Management-Plus/apimanager-swagger-promote#190 for Plugin-Support, which can be used to manage KPS-Entries

[cwiechmann]

With the next version I plan to add initial support to manage KPS in the same way as other entities. This means to provide the following features:

• get existing entries (Console, JSON, CSV, etc.) from a given table/alias
  • Filter support
• import/replicate KPS entries based on JSON desired state
  • to replicate the KPS-ID is used to decide if update or create an entry
  • the desired state may contain multiple KPS Tables/Aliases and entries for each
• delete entries based on the given filter

In the version after KPS-Dependencies can be added to an API. This dependency will be the KPS-Alias plus the Entry-ID. This kind of fragment will then be added to an API on the root level:

kps: [
  {“kpsAlias”:”tableABC”, “kpsKey”:”123456”},
  {“kpsAlias”:”tableXYZ”, “kpsKey”:”987654”}
]

With that, during replication of an API the CLI validates that the required KPS entries do exists. The required KPS entries must be imported before using the KPS import feature added with the next version. The KPS dependency information is planned to be stored in a custom property and based on that also exported.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.