Deploying a new version of a backend carbonApp which packages the same Data Service and Sequences as currently deployed fails due to matching the DSS and Sequence keys in the Service Catalog.
Is the correct approach to split the Data Service and Sequences into their own carbonApps. Then deploy the API endpoints into API spec versioned carbonApps referencing the DSS and Sequences from the other apps? Or must all the components, DSS + Sequences + API endpoints, all be packaged up into the same carbonApp for deployment?
In which case, how would multiple versions of the backend carbonApp be deployed and exposed in the service catalog simultaneously if DSS and/or Sequences are not uniquely named without having to recreate everything in a new project?
I have not been able to find any documentation from WSo2 discussing more complex MI deployments and versioning examples.
Recommended approach is to split the portions of the project into their own carbon applications, in this case DSS, Sequences and Endpoints.
Having a mix of DSS, sequences and specific version of endpoints packaged and a separate specific version of the endpoints was likely running into scope issues - there are no errors visible in the logs to indicate this, just a 404 return.
The fully separated out applications can then be deployed to the carbonapps directory and communicated to the service catalog. The alignment between Publish API version and backend version can be handled in the API endpoint configuration between API-M gateway and the MI node.