interface development: integrating m&ms designer and azteca cityworks at the city of concord,...

Interface Development:

Integrating M&M’s Designer and Azteca Cityworks at the City of Concord, North

Carolina

June 2005

Copyright © 2005 OneGIS, Inc.

OneGIS, Inc.One Platform, One Solution, One Company…



Let’s start with a few simple questions… What is an Interface and Why do we develop them?

• Interfaces usually consist of custom components or middleware which aid in the transfer of data to and from one application to another

• Some interfaces are one-way and others are bi-directional

• All interfaces should be developed with a purpose to provide TRUE BUSINESS BENEFIT to the organization by reducing data entry and producing a more efficient work flow.

InterfaceCityworksDatabase

M&MDesignerDatabase



The Concord Case StudyThe participants: The City of Concord, Electric Department OneGIS

The environment:• Miner and Miner’s Designer• Azteca Cityworks

General Interface functions:• Send the Cityworks Work Order to Designer• Send Designer Estimates to Cityworks• Send Designer As-Built Facilities to Cityworks

How was this accomplished?• Through the development of a scheduled MS Windows

Service



Phase 1: Send the Cityworks Work Order to Designer

• When a qualifying Cityworks Work Order is created, a Designer Work Request is auto-created by the Interface and linked back to the original Work Order. A design engineer can then perform design functions within M&M’s Designer.

This function/phase has three main purposes:• First, it improves communication within the organization by auto-preparing

the Designer-side environment, such that a design engineer does not have to be otherwise informed that a design effort is required for a particular job.

• Second, the Designer Work Request that it creates ‘borrows’ many of its header fields from the originating Work Order – e.g., site address, customer name/address, etc. This information is used on the cost-estimate report and inventory report, so the Interface makes it unnecessary for the design engineer to fill these in by hand.

• Finally, the Interface links the Cityworks Work Order and the Designer Work Request, on behalf of Phases 2 and 3.



Phase 2: Send Designer Estimates to Cityworks

• When the Design has been approved for construction, the Interface sends the Design’s Construction Units (CUs, also called Compatible Units) to Cityworks and breaks them out as appropriate into materials, equipment, and labor.

This function/phase has two main purposes:• First, it makes it unnecessary for someone to manually re-key all the

CUs into Cityworks. On large jobs there can be hundreds of CUs.

• Second, and in conjunction with the first, the Interface automatically categorizes the CUs by materials, equipment, or labor, simply by making the match within the Cityworks database. Thus, Concord’s administrators do not have to ensure that the Designer-side CU categorizations match up exactly with those on the Cityworks side; rather, the Interface makes the match based on the CU code, and will place them in the bucket as dictated by the Cityworks configuration, which is considered to be the more ‘enterprise-level’ system, as compared to Designer, whose scope covers only the construction design effort.



Phase 3: Send Designer As-Built Facilities to Cityworks

• When the Design has been as-built-updated within Designer and posted, the Interface sends a list of the GIS facilities (pole features, transformer features, etc) and ‘attaches’ them to the Cityworks Work Order. Thereafter, any Cityworks user can select a pole on the map and pull up the Work Order that installed the pole, or perhaps that last updated the pole’s assemblies. In addition, a user can open the Cityworks Work Order and highlight/select the assets that were associated with the Work Order. Optionally, users can allocate actual Work Order material, equipment, and labor costs across the attached entities.

This function/phase has one main purpose:• The great effort of manually identifying, finding, selecting, and attaching

Work Order-associated assets is such that it will typically not be undertaken by an electric utility. The jobs come too frequently and have too many assets associated with them. So this Interface function really enables a data management capability that (arguably) otherwise would not exist.

The Work Flow





A Cityworks user creates a Service Request for a possible design/build project, then submits the Request to a Concord official. The act of submitting the Request means completing the Request’s Submit-To field. The person referenced in the Submit-To field will receive an automated email, or will see the new Request the next time he logs into Cityworks.



The official meets with the customer to explore design and budget requirements.



If a preliminary agreement is reached, the Concord official opens the original Service Request and then creates an associated Cityworks Work Order (based on an applicable Work Order template). By creating the Work Order in this fashion, the Work Order and Service Request are now linked, allowing a person (or a software application, such as our Interface) to see the customer-specific information for the Work Order whenever this is needed. (In Cityworks, customer-related information is stored on a Service Request, not a Work Order.)



Work Orders that require a design effort will be based on a Work Order template that automatically creates a Work Order Task titled “Send Work Order to Design” (or similar – this is configurable). If, for whatever reason, a Work Order does not have this Task auto-created, a user can manually select it from a list and add it to the Work Order.



The Interface, which runs as a Windows Service, polls the Cityworks database, looking for new Work Orders that include the “Send Work Order to Design” Task – this is Phase 1 of the Interface. When this Task is found, the interface automatically creates a Designer Work Request. After creating the Designer Work Request, the Interface links the new Work Request to its parent Work Order, sets the Work Order’s Status to In Design, and sets the Interface-inserted Task’s status to Complete. Thus the Work Order and Work Request are tied to one another, which is a prerequisite for all other Interface functions.



When creating the Designer Work Request, the Interface queries the Work Order’s Submit-To field and attempts to auto-assign ownership of the Work Request to a named design technician. If the Submit-To field is null, or if the specified person is not yet set up within Designer, the interface will assign the new Work Request to a generic user named “CWDSGN”. In addition to setting the Work Request owner, the interface fills in most of the Work Request’s header fields, such as customer information, description, and site address.



On a regular basis, design technicians will open Designer (and the companion Workflow Manager application) to look for new Work Requests. They will also look for Work Requests owned by the catch-all CWDSGN user; if any are found the design technician converts ownership of the Work Request to himself. (Alternatively, a coordinator, such as the System Engineer, could routinely look for these ‘orphaned’ Work Requests and decide which design technicians should receive them.)



When the design technician is ready to process a Work Request, he will find the Work Request and create one or more Designs for it. In the large majority of cases, only one Design is created for a given Work Request. But Designer and the Interface allow for the possibility that a Work Request has multiple Designs – e.g., one for overhead and one for underground. (Only one of these Designs can eventually be promoted to an Approved status.)



Once the Design exists, the design technician will open the Design into Designer and proceed to lay out the construction sketch, all the while associating Construction Units (CUs, also called Compatible Units) to the job. At any point in the process, a technician can request a cost estimate against the custom cost-estimation engine built by Miner & Miner for Concord.



Every time the design technician saves or closes the Design, an Interface component wakes up to perform a function not immediately used by the Interface, but required later when the Interface performs Phase 3 (when the assets are ‘attached’ to the Cityworks Work Order). This function reads the contents of the Design, builds an XML document describing the features/objects associated with the Design, and loads this XML into a custom Interface table, and identifies this XML as belonging to the currently active Design.



When the design technician has finished his work on the Design, he can submit it for approval, using off-the-shelf Designer tools for this purpose. Designer also allows the design technician to submit-to-self; this does not avoid the approval step, mechanically speaking, but it prevents an authorized design technician from artificially having to submit the Design to another person, when the design technician himself is authorized to approve his own work.



When an Engineer or the design technician deems the Design to be approved, the user promotes the Design to the Approved for Construction state. Once this transition is made for the Design, no other possible Designs for the Work Request can be promoted – i.e., the approved Design is considered the official to-be-constructed Design.



The Interface (Phase 2) will detect this new status and will send all estimated materials, equipment, and labor to Cityworks, attached to the Work Order associated with the Design’s parent Work Request. The interface does this by matching the CU code in Designer with the codes used within Cityworks for materials, equipment, and labor. The interface does not know, ahead of time, what category a given CU will fall in. When, for a particular CU, no match is found in any category, the interface will insert a record within the list of estimated materials, with a message that unequivocally explains that this CU did not find a match and that someone should put some attention on this issue. To indicate that Interface Phase 2 has completed, the Interface creates a Task on the Work Order, named “Get Estimates from Designer” (or similar – this is configurable) and automatically sets the Task’s status to Complete.



At this point, any authorized Cityworks user can open the Work Order and see the estimated items. If, for whatever reason, the Design is later ‘unapproved’, meaning that its status within Designer is moved back to a state prior to ‘Approved for Construction’, the interface will clean up the Cityworks Work Order by removing all the estimates, and it will remove the Task that it originally inserted. Later, when the Design is re-approved (or perhaps a different Design under the same Work Request gets approved instead), the interface will proceed as it did the first time around, by sending the Designs CUs to the Cityworks Work Order as estimates.



At this stage the Work Order is no longer in the design process and construction can begin. With respect to this particular Work Order, the Cityworks-Designer interface is dormant and may remain so for weeks or months.



Eventually the construction is complete and the construction crew has updated the paper construction sketch to reflect any modifications that differ from the original design sketch. This modified sketch is sent back to the design technician who created the original design, so that the design technician can apply the as-built updates.



When the design technician has updated the Design with the as-built updates, he posts the Design, which effectively deletes the Design and its parent Work Request from Designer. In reality, the Design and Work Request are not deleted but rather flagged as hidden, such that they are no longer visible within Designer.



At this point the Interface intercedes and gathers a list of the assets (poles, transformers, etc.) that were involved in the design and/or as-built construction sketch. The Interface then ‘attaches’ these assets to the Cityworks Work Order. This is Phase 3, the final phase of the Interface. To indicate that Interface Phase 3 has completed, the Interface creates a Task on the Work Order, named “Get As-Built Assets from Designer” (or similar – this is configurable) and automatically sets the Task’s status to Complete.



At this point, for this particular Cityworks Work Order, the Interface has completed its functions.

Where will Concord Go Next?





Developing Interfaces and taking it to the WEB…

• Implement and Interface between M&M’s Session Manager and Cityworks

• OneGIS plans to work with business partner Orion to develop a Web Interface that will allow end users to :

– view a map showing all work orders and service requests in an ArcIMS/OnPoint environment

– query the database for all active work orders for a particular employee or crew.

– open and view work order and service request details– Allow for citizen entry of a service request via the Internet

In Summary



1. The Cityworks-Designer Interface provides a solution for data maintenance, editing, and reporting that fits into the daily business routine that occurs when a customer makes a request that requires a new work order and electrical design.

Work Flow based interfaceReduces data entry and ensures data integrity

2. The Cityworks-Designer Interface was designed to be a framework for integration that is flexible and adaptable to the City as the implementation of Cityworks and Designer evolve over time.

Built as a Microsoft ServiceConfigurable XMLConfigurable Cityworks Tasks

3. The Cityworks-Designer Interface provides a means for distributing data across the enterprise to:

Improve the quality of asset data by allowing the people who use the data to maintain the data in an application they are already familiar with (Cityworks or Designer),Provide a faster turnaround for service requests and work order generation,Eliminate redundancy; and Support better decision making.



The Solution

Questions?



interface development: integrating m&ms designer and azteca cityworks at the city of concord,...

Documents

o ne gis

designer work request

interface cityworks

cityworks user

cityworks configuration

originating work order

original work order

designer estimates