...
Accela APO records must be kept synchronized with EAS addresses in near real time. Regardless of how we build this it is convenient to think of this as a sort of custom replication service. We've already done this successfully with DBIs AVS as described here and here. That implementation has been used in production since February 15, 2012.
Implementation
As of November 4, we have a working Accela implementation - we are "replicating" to . Addresses that are created or changed on our EAS DEV should replicate in near real time to a table named easEAS_flat_addresses. We ADDRESSES_FLAT on Accela GIS DEV. To accomplish this we use the ArcGIS rest API; inserts maps to addFeatures; updates maps to query and updateFeatures. Note that we do not delete address records. You can see the code here and it should be running now on our DEV instance. When an address is created we call addFeatures. When an address is updated we use query to get the primary key from Accela (OBJECTID) and then use updateFeatures to update the other fields. The code is here. You can also get some sense of how this works by examining the insert and update log file output.
Learning Curve
After some discussion, Mike and Paul have decided to try the simplest thing that could possibly work. In this case, this means using a flattened representation of EAS addresses. This should allow us to better understand Accela and how addresses work in Accela. We expect that we'll make some changes as we learn.
Next Steps
The issue list for this feature is here.
I'd also like to do the following before we get to Here are the remaining issues that will go into subsquent Accela related releases.
Before we get too much further down the road.
- design review
- code review
- discuss strategy for production cut-over from AVS to Accela (see this line) (currently hard coding timestamp)
...
, I'd like to have a code review.
| Anchor | ||||
|---|---|---|---|---|
|
...