Replies: 1 comment
-
Mirth's OpenAPI definition is not what you want to expose. That API is the API for directly controlling Mirth (Start Channel, Stop Channel, etc). Sounds like what you want is Scenario 2 - Client app authorizes to API Management. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We are trying to develop a channel for a client who wants to use OAuth2 and POST json to us, where it will be imported via Mirth. We have never done an oAuth interface with Mirth before, but our infrastructure team runs and uses it with some of the Azure servers and we were hoping to piggyback of that token/verification Azure service, then post the json to a Mirth channel, with an Http Listener or Webservice Listener, not sure what to use.
Out team doesn't want to just use 1 mirth channel as a listern and route through that using the built in oAuth and verification dropdown in the a Mirth source, and instead do it the way described above, There options to set it up in Azure APi Management is to either use OpenAPI, WADL, or a WSDL. Does anyone know which would be easist to provide or does it just depend on what I plan/want to use as a source type?
I have exported Mirth's OpenAPI definition via a Curl command, but wasn't sure if this was the best approach, or if I should be looking to export as WSDL. I don't really want to use a Webservice, but will if need be or its easier. Any advice/tips would be welcome.
Beta Was this translation helpful? Give feedback.
All reactions