Im doing an upgrade from 10.3 to 10.15 and I have tried to do Export and import of API/Applications but all the apis/applications are not coming as it is.
I have tried to use the promotion management but that did not work as well
Can someone please suggest the best and ideal way to deploy API’s from lower version to higher version.
The source and target API GW gateway need to be in the same version, or in very close versions.
You’d first need to upgrade your source gateway to 10.15. This is the process.
If you’re trying to use export/import or promotions to simplify your migration, then unfortunately this isn’t going to work. There are significant changes in the datastore object definitions between these two versions.
It is unfortunate how API GW manages it objects and relationships. It is incredibly fragile. Always proceed with caution when copying from one instance to another. And never define anything directly on a target that will be later copied from some source. It will not go the way you want due to its use of internal IDs. We broke an instance or 2 in our early days due to this and ended up needing to redo some things.
Ideal ways is by doing with cleaner approach is using deployer. Even though APIGateway provides service to import the API. Its good to move your source code via controlled deployment process.
The OP mentioned API/Applications – which is “code”/configuration. The decision to store those elements in Elasticsearch was unfortunate, IMO. Lots of material around indicating that storing code, config, using ES as the primary data store, etc. has some challenges. It’s “You Know, for Search!”
IMO, the API, application, et al definitions should not be stored in ES. But that’s well behind us and we get to live with the results.
In the next generation of wM APIM, APIs and policies will be managed in version control.
If you’ve heard about the wM API Studio, it’s what this new tool is going to do.
As long as there is better support for extracting and importing artifacts between API GW versions, that will certainly be welcomed. I sure hope there is no requirement to use a VCS, just support for it if one chooses to use a VCS.
Being a strong proponent of using VCS, I join @reamon in his “plea”.
My reason is that I think the use of a VCS should always be on top of the file system as persistence layer.
Mandating the use of VCS (and what about multiple VCS?) effectively makes the VCS the persistence layer instead of the file system. This comes with some very heavy problems. And I mean REALLY heavy on various levels.
We’ve talking about some sort of “Infrastructure as Code” approach here.
But as I am not a Product Manager I don’t want to talk too much about future products.
I just wanted to let you know that API configurations could be managed differently in the future, in a less “datastore centric” way.