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

    To my mind there's one key question that needs to be addressed before we can assess what anyone should do, more like 2.

    How stable is the data in Application A?  How much work is being done on Application A?  Is it still having features added, or still having bugs fixed routinely?  If it is, using A's objects poses a problem, as another team will have ownership and could edit things your application depends on without warning you about it.

    What you can do:

    Use A objects such as A query entities and accept risk, especially if you inform A's team that you'll be using them or if work on A is minimal.

    Meet with A, establish ownership of objects and require that proposed changes have to be approved by owner or both teams before they're allowed to go forward.

    Offload objects you both need onto a Common or Universal or Utilities application, give it an owner, make all teams go through approval to change things, and hope that objects there are almost never modified.

    Copy paste is your friend:  Duplicate from existing all the A objects you want, then attach your own application prefix to them and use them all you want.  Then you can even tweak the queries if you want to.  Both teams are insulated from each other's changes until someone on A changes the data model itself without warning anyone. (However, in this model you also won't get the fixes to horrible catastrophic bugs with the same objects that they fixed without telling anyone about them, either)

Reply
  • Certified Lead Developer

    To my mind there's one key question that needs to be addressed before we can assess what anyone should do, more like 2.

    How stable is the data in Application A?  How much work is being done on Application A?  Is it still having features added, or still having bugs fixed routinely?  If it is, using A's objects poses a problem, as another team will have ownership and could edit things your application depends on without warning you about it.

    What you can do:

    Use A objects such as A query entities and accept risk, especially if you inform A's team that you'll be using them or if work on A is minimal.

    Meet with A, establish ownership of objects and require that proposed changes have to be approved by owner or both teams before they're allowed to go forward.

    Offload objects you both need onto a Common or Universal or Utilities application, give it an owner, make all teams go through approval to change things, and hope that objects there are almost never modified.

    Copy paste is your friend:  Duplicate from existing all the A objects you want, then attach your own application prefix to them and use them all you want.  Then you can even tweak the queries if you want to.  Both teams are insulated from each other's changes until someone on A changes the data model itself without warning anyone. (However, in this model you also won't get the fixes to horrible catastrophic bugs with the same objects that they fixed without telling anyone about them, either)

Children
No Data