Web services
You can use the web services in the BMC Atrium Orchestrator product to remotely trigger BMC Atrium Orchestrator workflows and return a Simple Object Access Protocol (SOAP) response with the workflow output. The BMC Atrium Orchestrator product uses the ORCA web service, RESTful (REST) web service, and legacy web service.
The legacy web service was used in the earlier releases of the BMC Atrium Orchestrator product. The ORCA web service was introduced with version 7.5.00 of the product and the REST web service is available in version 7.8.00. The ORCA and REST web services provide many improvements over the legacy web service. You can also use the ORCA and REST web services in conjunction with the legacy web service.
RESTful web service
The BMC Atrium Orchestrator REST API enables you to leverage the important properties of RESTful web services, such as uniform interface, addressability, statelessness, and connectedness. In RESTful web services, these properties are embodied in resources, URIs, representations, and the links between them.
The REST API web service is available on the CDP and activity peer (AP) (only supports Execute Process for a job).
The new REST API web service addresses some of the limitations of the ORCA and/or legacy web services, such as the following:
- Using JSON and JSONP (to avoid the need for proxies and avoid cross-domain issues) support
- Using token-based authentication, enabling the user to log into the API server, get an authentication token, and use it for subsequent API calls so that the user is not required to include credentials in every request
- Querying for details about all installed modules or their constituent workflows
- Executing single workflows synchronously or asynchronously
- Terminating or canceling workflows
- Pausing or resuming workflows
- Requesting the operational status of workflows
ORCA web service
The ORCA web service is powerful and flexible. You can use the queries and other operations to solve programmatic use cases. For example, using the ORCA web service, you can create a query to retrieve a list and descriptions of activated modules and workflows on a grid. Using the information retrieved from the queries you can build a robust web service interface.
The ORCA web service enables you to programmatically trigger workflows from other applications. The ORCA web service uses a fixed Web Service Definition Language (WSDL) for the web service.
The ORCA web service is available on the configuration distribution peer (CDP).
The ORCA web service offers you flexibility when performing the following activities:
- Querying for various information about installed modules or their constituent workflows
- Executing single workflows synchronously or asynchronously
- Terminating or canceling workflows
- Pausing or resuming workflows
- Executing multiple workflows asynchronously
- Requesting the operational status of workflows
- Optionally, registers with registries that are Universal Description, Discovery and Integration (UDDI) v3 compliant
Legacy web service
The legacy web service exposes a WSDL that matches the exposed workflow. You must set the Expose as SOAP workflow property to expose workflows to the WSDL.
The legacy web service is available on the CDP and activity peer (AP). Users who have View Grid Status, Grid Administration and Admin permission can use the legacy web service to execute workflows. For more information about assigning permissions, see Assigning grid permissions.
You can execute workflows synchronously.
Comments
If I require a structured WSDL with specific parameters for my service, I have to use the Legacy web service instead of the Orca service.
Assuming that I'm looking to execute a synchronous process, is there any downside to using the Legacy web service? For example, I have heard that the Legacy web service is single threaded while the Orca service is multi-threaded, meaning if I have high traffic on the Legacy service I could expect to run into performance problems and delays in processing?
Hi Lotan,
One of our team members responded. Please let us know if you need any other assistance.
" I have heard that the Legacy web service is single threaded while the Orca service is multi-threaded, meaning if I have high traffic on the Legacy service I could expect to run into performance problems and delays in processing?"
Where did you hear this? Is there a specific problem you or anybody else has encountered and is there an issue registered against this?
FYI -
ORCA also provides a WSDL and it also provides information on specific inputs required for a given workflow using a query mechanism, albeit, the input format is either a string or an XML.
I have heard this from discussions with other solution architects, not from any specific documentation. Since it is not mentioned in this documentation, I wanted to verify whether this is true and I should take it into consideration when designing a solution.
Regarding Orca, I am aware that it provides a WSDL, I have two issues with it so far:
I have not encountered any issues with the performance of the Legacy service, I'm asking the questions for a solution design so I know if I should deal with the security limitations I have in Orca schema verification or with potential performance limitation on the Legacy service (if that is even a risk).
Thanks for the quick replies.
Engineering is not aware of any performance difference between legacy and orca web service. So, you are free to choose any one that suits your needs. Orca is not available on APs. Legacy is available on CDPs and APs.
Hello Team,
What is the input language does BAO understands ? If i want to pass the input values as json , how does bao consumes it, for example, i want to trigger a workflow and and i want to pass the generic details like changedescription from external source like git or stash, then how to pass that value to bao (not gui ) using api.
Thanks Vasanth
For a quick answer:
BAO workflows have input parameters. BAO workflows determine how to treat an input parameter ; as a string, as an XML, as a numeric or as a date.
A parameter can be treated as a string or as an XML. Internally data is enclosed in XML tags. You will be in trouble if you want to process an non-XML input as input.
So, an input like 'Hello World' is enclosed using <value> tags as <value>Hello World</value>, but BAO knows that it is actually a string.
If you pass a string, like a JSON string, you need will need to process it as a string. To perform any XPATH/XSLT transformation, you need to convert that into XML first. This can be done out of the box workflows that help you to convert JSON to XML. You can also convert XML to JSON later on.
Log in or register to comment.