Hi all,
I have a use case where we want to start a process (process model independent of parent process) in different Appian environments from its parent process model.
So we need to accomplish an action in appian environment 1 and appian environment 2 once certain actions are completed in appian environment 3.
PM in appian environment 3 should trigger PMs in Appian environment 1 & 2 upon its completion, we cannot use web API or integration here.
So I wanted to understand if we can make use of 'start process by email' option to start multiple process which are in different appian environments.
Also if we have any other better approach for this scenarios? Any suggestion here much appreciated.
Thanks,
Preji
Discussion posts and replies are publicly visible
That's easy. Just expose a process via a web API and call that form the other system.
As I mentioned in the problem statement, usage of web API isnt allowed/accepted.
What is the reason for that?
it is considered as anti pattern and hence have been requested to find another approach
API calls are an anti-pattern !?!?!? I would really like to know more about this.
Is this in context of message based architectures?
The problem with an email based approach is, that the reliability of email is ZERO. Nobody guarantees that the other system gets the email and does anything with it. And as this is completely asynchronous, you will not get any response. There is a reason for why people use APIs.
Appian calling Appian is considered an anti-pattern.In my usecase I need process from Appian Prod to invoke processes in Appian non prod regions, and establishing this via WebAPI is not encouraged.
I want to understand if any other approach is available and reliable.
Apologies if I have mislead you.
Who says that this is an anti-pattern? I would challenge that!
While there are other options, I would only consider an alternative if that alternative has a major benefit in terms of architecture and systems integration.
E.g. a messaging architecture requires new infrastructure and adds the problem that it is asynchronous. This is not a problem for sending data updates in a microservices architecture, but trying to run a business process on it can be challenging.
I don't get why its considered an anti pattern either. One could argue that having Appian environments talking to each other could be considered an anti pattern depending on what is being pushed and in which direction but that has nothing to do with the method (API, Email etc)
In any case, there may be some other options but the API option is the best one by far.
Agreed with what others have said, I don't think using a Web API to trigger a process is an anti-pattern. I am curious though why you are triggering something in non-prod sites based on a process from a prod site. Can you provide more context on what you're doing there and why? There may be other solutions we could provide based on the root problem.
The process we are looking to trigger is, around deactivation of users accounts.
Once we manually deactivate the user account in prod, we want to trigger the deactivations process in lower regions for this same email-id.
We do not want to wait for the system to deactivate the ids upon inactivity as well as we dont want to manually carry out the deactivation in lower regions.
We can achieve this by passing the emailid which is common in all the appian regions and with this we will be able to deactivate user's account as well as all the persona accounts which was created using this email-id(as the person is no longer gona use appian hence getting password reset mail on their email ids is on no use).
I'm assuming you've already done this but will ask just in case. Have you considered enabling SSO in the environments?
We have enabled SSO only in prod environment not in lower regions
Is there any particular reason for this?
You wouldn't need an API if that were the case.