Appian offers several tools and services that let business applications connect to one another. The following article will help designers choose the right things to use in Appian in order to connect with other systems.
When integrating with Appian, there are two scenarios that require an integration. This article focuses on these two scenarios as a starting point to choosing the right integration:
Another system initiates the interaction with Appian - This sections covers the objects and features to use when a third-party system is getting data from Appian or causes Appian do something.
Appian initiates the interaction with another system - This sections covers how to choose the appropriate objects and features to use when Appian needs to reach out to other systems get or write data.
Instead of covering every possible scenario, in this article, Designers are directed to focus one of two simple flow charts to help determine the appropriate feature to use.
If you are unsure about everything that’s involved in creating an integration, check out Why Integrate.
Once you’ve identified that a third-party system will need to interact with Appian, the next question should be, what does that system need Appian need to do? Either that system will be (1) querying Appian data, or (2) tell Appian to do something. The following diagram breaks down this these two scenarios into separate workflows.
If the purpose of the integration is for the third-party system to get data from Appian, a Web API should be built. When another system makes a HTTP request to that Web API, the associated expression is executed and the result is returned to the system.
If you’re trying to get data that’s normally exposed through a data store entity, create a Web API that uses a!queryEntity. For information about getting data from processes, a web API built with a!queryProcessAnalytics will provide results from specified processes.
If the 3rd-party system requires Appian to do something, most of the time the request is best handled through an Appian process or smart service. There are several ways another system can tell Appian to do something. This can come in the form of starting a process or invoking a smart service function. We can call an Appian process via a RESTful service (HTTP), as a WSDL (SOAP), JMS, or through e-mail. If possible, we recommend you interact with Appian via a RESTful web service.
If the integration can be handle through an HTTP request, Designers should consider building a Web API configured to take the desired action through Smart Service Functions. Alternatively, a!startProcess() can be invoked by a web API to complete more a more complex business model.
a!startProcess() is a useful smart service function where more than one thing needs to happen. Workflows that require more than one thing to happen, a!startProcess can call a model, which can include multiple smart service nodes. If the API only needs to perform a single-step, like removing someone from a group or updating values in a relational database, those web APIs could be built to directly call that smart service.
If it is not possible to to use a REST service to connect a third-party system to Appian, Designers can publish a process model as a web service. The will create a WSDL for other systems to invoke. While not as flexible as Web APIs, which can essentially be configured as broadly as the Appian expression language support, process models published directly as WSDL offer an easy to configure option for systems needing to connect via WSDL.
Simple Mail Transfer Protocol (SMTP) and Java Message Service (JMS) are two completely different protocol types, but both can be used to kick off a process by using a receive message trigger within a start event.
Alternatively, the receive message event can be used by third-party systems to call an existing process.
To learn more about using e-mails to kick off an Appian process, check out the Sending an Email Message to a Process article. To learn more about JMS messaging, checkout the Working with the Java Message Service article.
If none of these connection types work, for example when sharing documents via HFS, a custom servlet plug-ins can be leveraged to connect between systems. For more common integrations, plug-ins may have already been built and offered on the Appian AppMarket. These resources are maintained by the Appian Community and are available to use on an 'as-is' basis.
The second scenario a Designer faces when creating an integration is when Appian needs to connect with another system. The following diagram covers the best features and objects to use when getting Appian to query or write data to another system.
If connector functions will not work for a particular scenario, we just have to figure out which protocol to use. Similar to before, we can connect via REST (HTTP), WSDL (SOAP), or other means.
Integrations should be the primary way to connect to REST services. Once created, Integrations can be call in a process using the Call Integration Smart Service or called directly within an expression or interface.
When connecting to a web service using SOAP, Designers should use, depending on the object, one of two web service features. If a process needs to call a 3rd party system, they can use the Call Web Service Smart Service.
If this is not being called in process, Designers have access to create expressions using webservicequery() or the webservicewrite() functions that will call the integration from an Appian rule or interface.
In either case, these web service features have the added benefit of creating a smart service page.
If you are unable to connect to another system via purpose-built, REST or WSDL service, custom plug-ins can be built to assist calls a third party system.
For more common integrations, plug-ins may have already been built and offered on the Appian AppMarket. These resources are maintained by the Appian Community and are available to use on an 'as-is' basis.