Would it be possible to turn the process around and get your external application to check the model, then tell KMM to publish the model if the validation passes?

To publish the model you need to call the URL <<root kmm>/publihser/<model URI>/publish with two parameters:

config - the name of the publisher configuration file to be used (e.g. SpaceMissions/Semaphore-Publisher-Concepts.xml - note we have the label of the model in the path

environment - the environment to which the publishing should occur - you can get this using graphql on the studio instance

You will also need to provide an authentication header, https://documentation.progress.com/output/semaphore/kmm-api/doc/api-tutorial.html#header-authorisation documents how this can be done

In the worst case scenario, you could use a script to run the validator, then use cURL to publish the model if the validation is successful.

Thank you @Keith Atkins (Progress Software)​ for your assistance.

We were thinking about solution you proposed which looks more promising but to support that workflow we'll have to build separate UI outside semaphore and our business users are not likely want to maintain two different tools to maintain & publish different models. As you mentioned In worst case scenario we'll have to go ahead with the same, just before that we're trying to get answer for below query.

till semaphore version 5.8.2 we used to have CommandExecuter output processor which can be used to perform preprocessing actions, but that has been deprecated. So, do we have any replacement functionality for the same?

It was eliminated as a security measure.

I was wondering about making a product change to extend the callout notifier so that it could make a call earlier in the process so the external application would be able to respond with an error to that call if the validation failed. However, if the validation takes more than a little while, this is liable to fail with timeout exceptions. An asynchronous call might work, but would make the design of your system harder.

Another thought would be to replace the command executer with a simpler "run a fixed script on the server" processor. You would then need to have access to the server to change how this script behaved, so at least some of the security risk would be averted. I would need to run this by our security team for approval.

If you have any alternative suggestions, please let me know.

Extending HttpCalloutNotifier to make a call earlier in the publication workflow would be incredibly beneficial. This change would provide us with the flexibility to add additional parameters like model name, version or current profile.

Additionally, while running a fixed script on the server is a good alternative, but it will restrict our ability to provide additional parameters from the client side, which could be a significant drawback in certain scenarios.

Another suggestion could be to add version validation at the SES end to prevent the publication of the same or older versions, but in our case though it would solve most of the problems still we have business specific validations like pattern matching.

Here are the issues we encounter:

1. If we fail to update the version, it may overwrite the existing version in the SES, making recovery impossible.

2. When updating the version manually, if the alphabetical highest order is not maintained, SES will default to returning outdated data.

I feel first solution to extend HttpCalloutNotifier looks better and would be good to have feature.

Thank you for considering these suggestions. I look forward to your feedback and any further discussions.

A ticket has been raised for modifying the http callout notifier processor. It's not that big a piece of work so I'm hopeful that it will get implemented.

Thank you for the prompt replies and insightful workarounds :)