Automated Reconcile and Posting Solutions

Document Sample
Automated Reconcile and Posting Solutions Powered By Docstoc
					Automated Reconcile and Posting
          Solutions


Scott Higgins – Senior Project Manager - Athens
           Automated Reconcile/Post Concept


                          Posting Queue Table
                          Session   Version   Date   Priority    Edits
        Default
        Default
                          906       ES006 10/1 Norma               27
ES006    ES007    ES008   907                  l
                                    ES007 10/1 Norma               39
ES006    ES007    ES008
                          908                  l
                                    ES008 10/1 High                20

   Posting Service
   Posting Service        Progress
       Process
        Process           Get to Session…
                          PostNextHistory…
                          Move tonext session…
                          Reconcile Version…
                          Get thethe with Default…
                          Delete Default…

                          Posting History Table
                          Session   Version   Date   Priority   Edits

                          908       ES008 10/1 High                20
    What is the Reconcile Process?
       The ESRI Definition…..

From the Glossary in the ArcGIS Help……


“In version management, reconciling is the process of merging
all modified datasets, feature classes, and tables in the current
edit session and a second target version. All features and rows
that do not conflict are merged into the edit session, replacing
the current features or rows. Features that are modified in more
than one version are conflicts and require further resolution via
the Conflict Resolution dialog box.”
     What is the Reconcile Process?
        The ESRI Definition…..

More important Concepts……

• The Reconcile button in Arcmap merges all modifications between
the current edit session and a target version you select.
• A target version is any version in the direct ancestry of the version
such as the parent version or the DEFAULT version.
• Any differences between the features in the target version and the
features in the edit session are applied to the edit session. Differences
can consist of newly inserted, deleted, or updated features.
• The reconcile process detects these differences and discovers any
conflicts. If conflicts exist, a message is displayed, followed by the
conflict resolution dialog box.
• Reconciling happens before posting a version to a target version.
                    What is Posting?
                  The ESRI Definition…..
    From the Glossary in the ArcGIS Help……

    “During versioned geodatabase editing, posting is the process of
    applying the current edit session to the reconciled target version.”

    More important concepts…….

  You can post a version after you have first performed a reconcile.
  Once the edit session has reconciled with a target version, clicking the
Post button synchronizes the edit session with the reconciled version and
performs a save.
  Posting can't be undone because you are applying changes to a version
that you are not currently editing.
  If the reconciled version is modified between reconciling and posting,
you will be notified to reconcile again before posting.
    Requirements for batch reconcile and
            post applications .

  ArcSDE versioning, by design, supports one post to a parent at a time. In
an enterprise implementation, user productivity could be impacted if many
users post to the same parent version at the same time, or in rapid
succession.
  Conflicts may be detected reconciling a version. Resolution of conflicts
can be a complex task. Versions with conflicts need to be queued up for
GIS Administrators, Business Analysts or “Power Users” to resolve.
  All versions in the geodatabase should be periodically reconciled with
SDE.Default (or other parent) in order to maximize the benefits (state
reduction) of geodatabase compression.
  Logging of which versions are reconciled, posted, or found to have
conflicts is important for validation, reporting, measuring user progress,
and looking for trends in the ‘nature’ of edits being made by the user
population.
    Requirements for batch reconcile and
            post applications ..

  May need to support multiple versioning schemes. For example, the
version hierarchical scheme for ArcFM Edit Sessions may differ from
Designer Sessions. The schemes for either may differ from one utility to
another.
  It makes sense for Rec/Post to be integrated with the ArcFM Session
and/or Designer Session Management tools. Users sending sessions to a
“posting queue” need to see that their edits were posted.
  Multiple Contexts:
      Batch Reconcile Only – To support just the reconciliation of all
     versions that exist in the database in order to maximize benefits of
     periodic compression.
      Batch Rec/Post – To support Posting completed sessions.
    Requirements for batch reconcile and
            post applications …

  After Posting is complete, the application must remove the version along
with associated stored displays and whatever other related data that may
exist in the database.
  There may be interface points to other Systems (Customer, Billing,
Inventory, Outage, Work Management or others) that need to be invoked
upon posting a session. This may require detailed analysis of what has
been edited in the session.
  Posting Service may need to securely store/persist database connection
information, user names, passwords and other required parameters.
  System Administrators need convenient ways to configure, start, stop
and interrupt reconciling and posting applications.
  For Designer, feature and object classes that are configured to be “non-
postable” need to be removed from the version prior to posting.
  Etc….There may be other requirements in your organization.
   “One Off Default” or “Flat” Versioning
                 Scheme
                           Default
                           Default

                  ES006
                  ES006      ES007
                             ES007      ES008
                                        ES008



  Typically utilized for ArcFM Edit Sessions.
  These sessions are normally created, worked, and posted within the
same business day and can contain an arbitrary number of edits.
  Depending on the nature of the editing being performed by your GIS
maintenance group, users may work several of these sessions each
day…or more.
  Backlog/Asbuilt updates of design/construction jobs, updates to
landbase, QA/QC and correction of existing data.
     “District – User” Versioning Scheme
   Typically utilized for ArcFM Edit Sessions.
   District Level Versions are created each
day from SDE.Default.
   User Versions are created within each
district.
   Each day, users post their own versions
up to the District Level.
   District Versions are posted up to
SDE.Default.
   This approach can help to minimize
conflicts as smaller numbers of users edit in
fixed geographic areas.
   All versions are posted up each day.
          WR/Revision “Re-assignment”
              Versioning Scheme
  Typically utilized for Designer Sessions.
  This Scenario can bring CUs and Features from an
original WR Revision that can no longer be              S D E .D E FAU LT
                                                        (B ulletin B oard)
edited…This might be a WMS driven requirement.
  This might occur because WMIS will not allow an
existing revision to be developed upon after reaching
a certain state, or ‘Lockdown’.
                                                              DN 1
  If the need arises to continue making changes to       (N on-Postable)

that design it will be copied and placed under a new
                                                                       B ring C U s
work request to save time.                                                  and
                                                                        Features

  The original DN1 version will become non-postable.                       from
                                                                         original


   Reconcile and Posting Applications need to be             D N 1.1
smart enough to recognize Non-Postable versions,
reconcile versions in a particular order, and Delete
versions appropriately.
                WR/Revision “Alternative”
                  Versioning Scheme
   Typically utilized for Designer Sessions.
   This Scenario can bring CUs and Features from
                                                                         SDE.DEFAULT
an original WR Revision that can no longer be                            (Bulletin Board)
edited.
   A typical case would be an overhead versus an
underground design, where the two alternatives
would originate from the same tap point.                                      DN 1
                                                                         (Non - Postable)
   The CUs from the original design (the common
tap point) are carried over to the alternatives Design Option
                                          Post Single


because the chosen alternative will ultimately be                            Bring CUs
                                                                                 and

posted instead of the original from which the                                Features
                                                                                from

alternatives were copied.                                                     original


                                                                DN 1.1                      DN 1.2
   Reconcile and Posting Applications need to be
smart enough to recognize Non-Postable
versions, reconcile versions in a particular order,
and Delete versions appropriately.
                 WR/Revision “Tap Off”
                  Versioning Scheme
  Typically utilized for Designer Sessions.
  The copied design (DN2) continues from a point
in the original.                                     SDE.DEFAULT
                                                     (Bulletin Board)
  The difference is that the CUs from the original
will not be transferred to the copy, but the                            Pos t
                                                                                Pos t

features placed by those CUs will appear in the
new version.
  Both Versions can be posted, but it may be              DN 1
optimal to ensure that DN1 is posted before DN2.
This may be the responsibility of the posting
service or the Tool used to submit the session to
the posting service.
  Reconciliation of the designs must be done in           DN 2

the correct parent/child order – in the above
diagram, DN1 must be reconciled with its parent
(SDE.DEFAULT) before DN2 is reconciled its
parent version (DN1).
            Who needs Batch Rec/Post?
  Small Utility (1-5 ArcFM/Designer Users)– May not require reconcile and
posting services if only a small number of users edit SDE.Default directly.
  Medium Utility (5-15+ ArcFM/Designer Users) – May need to batch
reconcile/compress once every few weeks or so, and may not need a
posting service at all (users post from Arcmap application) in a simple
versioning scheme.
  Large Utility (15-30+ ArcFM Users) – May have a “Posting Officer” that
uses a batch rec/post tool once each day to post edit sessions. Depending
on the nature of the editing being performed, there may be few conflicts.
Users may post from Arcmap to intermediate “district” or “office” versions
in what is a fixed and consistent versioning scheme.
  Large Utility (15-30+ ArcFM Users and 30-100+ Designer Users) Many
users performing a wide variety of edits each day, along with Designers
completing Design-Asbuilt work requests. Need a more automated
posting application that is sensitive to different versioning schemes.
Batch Reconcile/Compress is important for geodatabase maintenance.
Original Stand Alone Batch Reconcile Executable
               ESRI Developer Sample
Command Line Batch Reconcile Executable
User Initiated Batch Reconcile/Post
  Integrated with ArcFM Session Manager
User Initiated Batch Reconcile/Post
  Integrated with ArcFM Session Manager
User Initiated Batch Reconcile/Post
  Integrated with ArcFM Session Manager
  Automated Reconcile/Post Executable
Posting Queue and Posted Sessions Filters
            Automated Reconcile/Post Executable
     Integrated with Session and Workflow Management
                           Tools
• The GIS Administrator or SA Starts
PostingService.exe and the service is exposed in
the system tray.
• Upon opening the properties, the SA sets
database connections to the geodatabase and the
Process database (SDE user and Process user).
• After establishing the connections the service
can be started and the property dialog closed.
The form can be left open and status messages are
presented at the bottom.
• The Options button exposes configuration
options.
            Automated Reconcile/Post Executable
     Integrated with Session and Workflow Management
                           Tools
•Posting Service configuration parameters stored
in the registry on the computer that is running the
service.
•Passwords are encrypted.
         Automated Reconcile/Post Executable
  Integrated with Session and Workflow Management
                        Tools




••Session is opened
   Session is opened
••Transitioned to ‘In Progress’ state
   Transitioned to ‘In Progress’ state
••Feeder Management is initialized
   Feeder Management is initialized
••Attribute Editor is displayed
   Attribute Editor is displayed

The user is ready to start editing
The user is ready to start editing
         Automated Reconcile/Post Executable
  Integrated with Session and Workflow Management
                        Tools




••Identifies edited features
   Identifies edited features
••QA’s edited features
   QA’s edited features
••If no validation errors then Session:
   If no validation errors then Session:
     ••Is submitted to Posting Queue
        Is submitted to Posting Queue
     ••State transitioned to PostingQueue.
        State transitioned to PostingQueue.

User can open another session without
User can open another session without
waiting for the session to reconcile/post
waiting for the session to reconcile/post
          Automated Reconcile/Post Executable
   Integrated with Session and Workflow Management
                         Tools

                              Posting Queue Table
                              Session   Version   Date   Priority   Edits
          Default
          Default
                           906          ES006 10/1 Norma              27
 ES006     ES007     ES008 907                     l
                                        ES007 10/1 Norma              39
 ES006     ES007     ES008
                           908                     l
                                        ES008 10/1 High               20

Posting Service
 Posting Service
••Runs on dedicated computer
  Runs on dedicated computer
••Polls Posting Queue Table
  Polls Posting Queue Table
••Reconciles next priority session
  Reconciles next priority session History Table
                            Posting
••Runs continuously while
  Runs continuously while
scheduled
 scheduled
         Automated Reconcile/Post Executable
  Integrated with Session and Workflow Management
                        Tools

                          Posting Queue Table
                          Session   Version   Date   Priority    Edits
        Default
        Default
                          906       ES006 10/1 Norma               27
ES006    ES007    ES008   907                  l
                                    ES007 10/1 Norma               39
ES006    ES007    ES008
                          908                  l
                                    ES008 10/1 High                20

   Posting Service
   Posting Service        Progress
       Process
        Process           Get to Session…
                          PostNextHistory…
                          Move tonext session…
                          Reconcile Version…
                          Get thethe with Default…
                          Delete Default…

                          Posting History Table
                          Session   Version   Date   Priority   Edits

                          908       ES008 10/1 High                20
Automated Reconcile/Post Executable
  Posted Sessions Filter for Users
Automated Reconcile/Post Executable Reporting
Automated Reconcile/Post Executable
             Logging
    Batch Reconcile/Post Windows Service
• The AutoReconcilePost service accesses the Session Manager tables
through database Views and the SQL package SessionUtils.




 • When the AutoReconcile service is running it queries the Posting Queue
 table for any sessions that can be posted. Each session in the post queue is
 then validated for posting.
 • If the Session has conflicts it is removed from the post queue and reverted
 back to the pre-post status.
 • If the Session has no conflicts it is posted and routines are called to
 cleanup the session tables and remove the related stored display.
   Batch Reconcile/Post Windows Service




• After the SESSION_POST_QUEUE table is processed, the
SESSION_RECONCILE_QUEUE is queried for a list of sessions that can be
reconciled.
• Continually reconciles versions that are 1) Not Locked by another user and
2) of a certain age.
• In this pre-ArcFM 8.3 version of the tool, the MMProcess Framework is not
being used because it did not yet support a .NET implementation….Now with
ArcFM 8.3 this can be re-implemented.
   Batch Reconcile/Post Windows Service


•The AutoReconcile service is controlled by the
AutoReconcileController.exe which is accessed via the
System Tray.
•Set up the connection properties to a SDE database.
•Set up the run-time for the reconcile-post service.
•The Enabled and Disabled Times specify the
window when reconciles and are executed.
• Age to Reconcile specifies how old a version has to
be (based on the last modified date) before it can be
reconciled.
•The Reconcile Interval allows a user to specify how
often reconciles are performed.
•The Post Reconciled Versions checkbox indicates to
the service that any version that was flagged for
posting in Session Manager should be posted.
   Batch Reconcile/Post Windows Service
• Properties are persisted in XML.

• Whenever the Auto-Reconcile Manager is updated,
the related AutoReconcileProperties.xml file is
updated as well.
   In Summary, Batch Rec. and Post
         Applications can…..
• Help to position your geodatabase for the best possible results of
gdb compression, even if you have long transaction versions in the
system.
• Free users from potential posting delays and let them get on with the
next ArcFM or Designer session.
• Keep up with the demands of posting large numbers of versions each
day or night, helping to keep SDE.Default current so it can drive other
important applications, viewers, and interfaces to external systems.
• Help manage conflicts by queuing conflicting sessions for review by
administrators and more experienced business systems analysts.
• Improve data integrity by enforcing QA and other business rules, as
well as providing an interface point to other critical business systems.
• Give users and managers confidence that the geodatabase is being
updated in a timely manner by producing logs that form the input data
for a variety of useful reports.
• As more Designer implementations mature, additional requirements
for these services will become evident.
 Questions?……..Comments?


Scott Higgins – scott.higgins@miner.com
Thank You!

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:14
posted:12/18/2011
language:English
pages:36