Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Update a KPS table #6

Open
wsalembi opened this issue Sep 18, 2019 · 4 comments
Open

[Feature] Update a KPS table #6

wsalembi opened this issue Sep 18, 2019 · 4 comments
Assignees
Labels
enhancement New feature or request pinned
Milestone

Comments

@wsalembi
Copy link

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
Copy link

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
Copy link

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 cwiechmann transferred this issue from Axway-API-Management-Plus/apimanager-swagger-promote Jun 15, 2020
@cwiechmann cwiechmann added the enhancement New feature or request label Jun 29, 2020
@cwiechmann cwiechmann added this to the 1.3.0 milestone Jul 24, 2020
@cwiechmann
Copy link

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.

@cwiechmann cwiechmann modified the milestones: 1.4.0, 2.0.0 Sep 30, 2021
@stale
Copy link

stale bot commented Apr 19, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pinned
Projects
None yet
Development

No branches or pull requests

2 participants