Hi DJ, The question here is why use ARIA's orchestrator at all? It sounds like you have your own orchestration engine. This is an intended use case for ARIA (and indeed was used in the OPEN-O project).
There are a few ways to use ARIA here: 1) You can use the ARIA's Python API and access all the data models directly. Of course this will only work if your own orchestration code is in Python. 2) You can use ARIA's CLI to emit the data models you need in either JSON or YAML format, for easy consumption by your code: aria services show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service. 3) You can access the database directly. ARIA uses a a normalized relational (SQL) database. There are some challenges and limitations to each approach. If you tell us what you're going to do we can help you move along in that direction. On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <d.jayachand...@ericsson.com > wrote: > Hi Team, > > We are looking at an execution point during a service execution through a > plugin. With this the execution will not go through the workflow runner > (install/uninstall) defined by the orchestrator but the services instance > context object will be provided to the plugin which will take care of the > complete service-execution. > This plugin is looked upon as a "service plugin" which will get the entire > service model object and will provide the details to the external workflow > engine. > We need this feature to enable the execution of workflows which some of > our users already have. Please let us know your thoughts on this as we have > already started our technical study on this. > > > Regards, > DJ >
