Think of Orchestrator as a "router", that will route information and workflows between SCOM, and [insert 3rd party product here]. Depending on your 3rd party product, there may be an "integration pack" for it that Orchestrator can use for out of the
box tasks.
So what's an integration pack? Well - think of it like a management pack, but for Orchestrator. SCOM does monitoring, but it doesn't know how to monitor something unless you install the relevant management pack. The management pack contains
all the rules/monitors for monitoring whatever it is you wish to monitor.
Well, an integration pack is similar in concept, except it tells Orchestrator how to interface and integrate with whatever it is you're trying to perform tasks with.
For what you want to do, there is a SCOM integration pack. This is a set of tasks that can get alerts and events out of Operations Manager (there are also tasks that can create and close alerts in Operations Manager).
From what I can imagine - you would want to get alerts out of SCOM when they happen (so you would use one of the SCOM orchestrator tasks to "get alert if status = new, and source = myapplication"), and then you can pass that alert to another task - such
as write it to a CSV file or something. You could then have another task that picks up that CSV file, and passes it to your application where it can be captured. Or you could use the CSV to populate variables in a powershell script, and then powershell
that information into your app.
There are many ways you could do this, but I do believe that Orchestrator would be the better option.