• Replies 5 replies
  • Subscribers 13 subscribers
  • Views 2641 views
  • Users 0 members are here
Related Discussions
Home » Discussions » Best Practices

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

Richard Michaelis
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
  • Appian Employee

    I believe there are 3 possible patterns here:

    1. Make Application D and A the same Application. Now you have no reason not be to able to access the same data
    2. Refactor Application A so that its Datastore and dependent datatypes sit outside in their own Application package, and (as Mike describes) make this new "Application" a child of Applications A and D. That is, the new (data only) Application functions like a shared "library" but instead of serving up functions/rules it provides data services
    3. Expose Application A's data via WebAPIs. So Application D has to call those WebAPIs to CRUD the data that is shared with Application A

    (there may be others that haven't occurred to me)

    There are all sorts of pros and cons for each of the above (a pro of keeping the Applications separate is different Development teams can develop concurrently and trip each other up less than if it was the same application. At the same time, encapsulating your data objects means both parties have to be aligned when it comes to a deployment!). There are some common issues (how to ensure that data is "locked" so that only one update can be made at a time so as to not have transactions mysteriously disappear.

Reply
  • Appian Employee

    I believe there are 3 possible patterns here:

    1. Make Application D and A the same Application. Now you have no reason not be to able to access the same data
    2. Refactor Application A so that its Datastore and dependent datatypes sit outside in their own Application package, and (as Mike describes) make this new "Application" a child of Applications A and D. That is, the new (data only) Application functions like a shared "library" but instead of serving up functions/rules it provides data services
    3. Expose Application A's data via WebAPIs. So Application D has to call those WebAPIs to CRUD the data that is shared with Application A

    (there may be others that haven't occurred to me)

    There are all sorts of pros and cons for each of the above (a pro of keeping the Applications separate is different Development teams can develop concurrently and trip each other up less than if it was the same application. At the same time, encapsulating your data objects means both parties have to be aligned when it comes to a deployment!). There are some common issues (how to ensure that data is "locked" so that only one update can be made at a time so as to not have transactions mysteriously disappear.

Children
No Data
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.