What were the underlying reasons or business implications for the need of application integrations?
The Courts and Justice division of Tyler Technologies primarily focuses on our Enterprise Justice platform and our connected products to provide first class business functionality to State and Local government court systems. When new clients purchase our software, they often have existing applications that require integration with our platform.
To account for these integration requirements, we have built an Integration Toolkit that provides inbound API and outbound configurable publishing support to our clients. Additionally, we provide custom development for integrations that a client may be unable to build through our toolkit because of functionality gaps, knowledge gaps, or lack of development resources. Using this development model, we have compiled over 200 XML/SOAP APIs the past 15 years and several customizable interfaces through our publisher.
As we modernize our platform and develop new connected applications, we must maintain functionality and interfaces for our existing clients while providing new feature sets for modern applications. Recently, we developed a new application using server-less AWS technologies and restful APIs to provide browser-based warrant entry functionality for court officials and officers. Delivery timelines and limited customization options in a new product provided a unique opportunity to modernize our integration strategies while maintaining functionality for our existing clients.
Describe your application innovation strategy and how you executed the strategy.
Our long-term modernization strategy involves moving towards cloud native solutions. We would also like to expand the functionality of our toolkit to allow our clients to be more self-sufficient at building and owning their application integrations.
Given our monolithic application, we need mechanisms to provide iterative improvements while maintaining our existing functionality and our expected level of service. The new warrants application is my division’s first foray into a server-less application. While many aspects of server-less environments are compelling, we needed a mechanism to communicate with our existing server-based platform.
Traditionally, we would develop a custom .net solution to merge the two systems built on our integration framework. While this solution has served us well in the past, development effort is required to modify or enhance these solutions, which can distract from modernization efforts. Rather than building the required middleware on our platform, we decided this would be a great opportunity to leverage an out-of-the box integration platform with the hopes that SnapLogic could provide a mechanism to build client specific integrations through configuration and allow development teams to remain focused on modernization efforts.
The first step was to build out a custom Snap that would allow us to interface with our existing XML/SOAP API services in a model that would fit well within the SnapLogic application. We translated our API schemas into JSON schemas so that we could build custom endpoints that more accurately modeled the business requirements of the new server-less application, while abstracting out the underlying XML structures.
Next, we leveraged this custom Snap to build out new application specific ultra-tasks that provided the specific functionality required without updating our underlying APIs. This allowed for the flexibility required for greenfield development.
With Enterprise Justice platform integration abstracted, we branched out to other areas of the SnapLogic platform. We implemented interfaces that would handle SNS subscriptions, interact with a Legacy IBM MQ solution, and various SFTP sites. Additionally, the REST Snaps allowed interaction with the REST/JSON services provided by the new server-less application.
With the integration up and running, we were able to leverage our local Snaplex environment to provide logging solutions through S3 to DataDog, enabling dashboard and monitoring support to an application that has lacked a unified logging strategy.
Leveraged SnapLogic functionality: Ultra tasks, Custom Snaps and Accounts, REST Snaps, File Access Snaps, Script Snaps (with side loaded Apache libraries), and JMS Snaps
Attached Documents
- Network Architecture.png: Displays our Snaplex environment and connected systems
- Buffer Queue Interaction.png: Displays one example of our SnapLogic integration patterns
- Project Config.expr: Expression library to configure log settings
- Log Message Handler.slp: Logging pipeline that writes to local disk (mounted file gateway) for the DataDog Agent to consume
- Error Message Handler.slp: Error handling that remaps system and business errors as necessary and logs business errors to the Enterprise Justice Application for user resolution. Also writes to local disk (mounted file gateway) for the DataDog Agent to consume. The “log message” Snap is our proprietary custom Snap.
Who was and how were they involved in building out the solution? (Please include the # of FTEs, any partners or SnapLogic professional services who were involved on the implementation)
The core development team consisted of 3 FTEs with another 10 developers rotating in as necessary to build specific functionality pertaining to additional integrations, and logging and monitoring solutions. We were able to attend Snap development training, SnapLogic training, and worked with our account manager and SnapLogic technical support as we encountered challenges.
What were the business results after implementing these application integrations?
By abstracting our SOAP/XML API messages, we were able to focus on the requirements of integrating new and existing applications through configuration and not custom development. This allowed for rapid development and flexibility to deliver interfaces through conversion activities, changing requirements, and newly developed functionality and applications.
Using existing SnapLogic logs and our custom logging solution, we were able to provide integration Dashboards and monitors to allow our stakeholders a real-time view of integration health and alerts when issues arise.
On an average day we handle 20k SNS webhook messages through our ultra-tasks. Additionally, we process thousands of triggered synchronous API requests, tens of thousands of JMS messages, and 100k+ log writes. From performance testing we know our environment can handle 3-5 times an average days volume without issue, which gives confidence to our customers that we can handle their operations during peak volumes.
Anything else you would like to add?
SnapLogic provides an effective abstraction of our existing Integration Toolkit to allow flexibility in developing new integration solutions though configuration. This allows customizable API endpoints that are application specific while allowing development to modernize our existing platform.
Error Message Handler.slp (73.6 KB)
Log Message Handler.slp (13.5 KB)
ProjectConfig.expr (725 Bytes)
