Third-party Integration Basics

Owned by Asiya Wadud (Deactivated)
Nov 21, 2014

 

The basic PublicStuff integration package automates the process of transmitting service requests and citizen comments from the PublicStuff servers to a single 3rd party system using a set of standardized web services. Any number of PublicStuff request types can be configured to route to this 3rd party system.


PublicStuff integrates with a number of third-party systems, including Lucity, Active Directory, CityWorks, Tyler, Cartegraph, Maximo, and Hansen. If your city is interested in an integration, please ensure the third-party system has public-facing web services to allow the systems to update each other.


Requirements:

  • The third party system must have documented web services that can support the functionality being requested. Generally this includes an endpoint to accept service requests, a method to accept comments, but the exact methods required can vary based on the city’s integration requirements.

  • The city must be able to provide PublicStuff with access to the endpoints associated with the desired functionality. This includes access through firewalls, internal networks, system specific security mechanisms, etc.

  • The city must provide a point of contact in the company that built the 3rd party system. This can be an account manager, a technical support contact, or an Administrator. This contact is not required to write any code, but should be able to direct our team to the appropriate documentation for the system, as well as connect us with qualified technical support if needed.

  • The city must provide a set of field mappings for each object involved in the integration (generally this is limited to service requests, but comments, users, and locations should also be considered). These mappings must indicate field names, optional/required fields, data types, etc.


Additional Functionality:

  • PublicStuff can set up a mechanism to periodically poll a 3rd party system for changes to a service request or new comments from city staff, and update local data accordingly. This polling mechanism is considered a separate integration, as it requires the same amount of coding, support, and maintenance as our standard integration.

  • 3rd party user authentication can be implemented if it is thoroughly specced out and the appropriate mechanisms are all available. PublicStuff offers endpoints to support user authentication free of charge, so it is recommended that cities use those, but if needed PublicStuff can implement a mechanism to authenticate users against other systems.

  • Address validation is not considered part of the standard integration package, though it is a common request. If the city has an automated method of authenticating location data (either string based or location based), this can be incorporated into the integration as well at an additional cost.

  • Any objects aside from service requests and comments are not considered part of the standard integration package (though requests can contain additional information, as described above). They can be incorporated into an integration, though it may incur additional development time depending on the complexity of the object in question.

  • By default, all integrations will route requests to 3rd party systems based exclusively on the request type. If additional logic is required to determine where a request should be routed (things like time of day, request location, custom field values, etc), that can introduce additional development time and cost.

  • If the city or 3rd party system requires that attachments be stored locally on a remote server (one not managed by PublicStuff), PublicStuff can arrange to transfer the binary file, if the system has the appropriate tools and mechanisms in place to support the file transfer.