Best Practice regarding calling data of Application A for Application B?

Certified Senior Developer

Hello together,

as I didn't found something suitable in Appian Playbook or documentation. (perhaps i am just blind, then please provide suitable links)
I want to ask for your experience regarding calling data of a second application.
Scenario: You have already applications A,B,C.... live.
Now you want to create another one (Application D) which likes to get some data from Application A.
What is the most elegant way in your opinion?

I think there a plenty possible ways to archive this technically. I am still thinking about the best one.

Reusing the same query rule of application A in applicaiton D regardless that its another application?
Copying/Dublicating query rules of application A to application D?
Creatin web services in application A and integration in application D?
Two data stores which use the same DB scheme?
.......


What would be your favorite one and mostly: WHY? ;)
Looking forward to read your input there.

Kind regards to you all!

  Discussion posts and replies are publicly visible

Parents
  • Certified Lead Developer

    As you say, there's no one "right" answer to this.  I've had some team leads in the past who insist that different applications on a platform should be so disconnected in terms of application precedents, that they could be moved to whole other environments and still work together the same.  I usually don't go to that extreme unless I have specific reason up-front to expect the applications might someday need to migrate to separate production environments. 

    My preference is usually to form a "parent child" hierarchy, where one application is considered the "parent" and whose artifacts we assume can be freely used by "child" application(s), and thus the only queries / tools / etc we'd need to create for the child application(s) would be those which apply exclusively to that application.  [This is also in addition to a "global tools" applicaiton which can exist separately, be used by all, and not refer to any artifacts outside its scope.]  In general this method works pretty well, though it can get a little hairy in the face of a super strict deployment regimen (depending on how many developers there are and how active development is).

Reply
  • Certified Lead Developer

    As you say, there's no one "right" answer to this.  I've had some team leads in the past who insist that different applications on a platform should be so disconnected in terms of application precedents, that they could be moved to whole other environments and still work together the same.  I usually don't go to that extreme unless I have specific reason up-front to expect the applications might someday need to migrate to separate production environments. 

    My preference is usually to form a "parent child" hierarchy, where one application is considered the "parent" and whose artifacts we assume can be freely used by "child" application(s), and thus the only queries / tools / etc we'd need to create for the child application(s) would be those which apply exclusively to that application.  [This is also in addition to a "global tools" applicaiton which can exist separately, be used by all, and not refer to any artifacts outside its scope.]  In general this method works pretty well, though it can get a little hairy in the face of a super strict deployment regimen (depending on how many developers there are and how active development is).

Children
No Data