SymXchange API
I created a fast, efficient REST service that connects to a Symitar core system to retrieve and update account and transaction information in real time.
Overview
Symitar is a core transaction processing system used by the majority of credit unions in the nation. The system manages all of the financial aspects of a credit union including member accounts, transfers, credit card transactions, back-office operations, and much more.
The Symitar core has a SOAP-based API that allows third-party applications to retrieve information and perform operations on the core processing system. The API is very robust and can perform most operations that can be done directly on the core system itself.
Because there is so much data available, the SOAP API’s WSDL generates some very large C# objects when implementing the API. These large objects make startup times and calls to the SOAP service unacceptably slow.
After researching what could be done about this issue, I decided to create my own solution that doesn’t rely on the generated code and would allow consuming services to use JSON instead of XML.
Features
WebAPI / Swagger / OpenAPI
The REST web service is WebAPI / OpenAPI. This means that any client can use JSON and an HTTP client to make calls to the service to use the service. The service is not accessible to any front-end client – meaning it is not meant to be called directly by any public-facing application. The amount of control and information available to this API requires strict security measures. Only a select few devices are allowed to use the API.
Access Control
The system uses IP address restrictions and token-based authentication to keep access to the data secure. The system is hosted on premises so access from any outside network is not allowed.
Data Availability
The SymXchange API limits the queries to certain modules in the system. Currently I have created services for the account, card, loan, loan transaction, name, Repgen, share, share transaction, and tracking modules. It would be easy to create additional services for other modules in the system but I have not needed them.
My Involvement
I worked with a Symitar programmer to gain access to the API. He set up the parameters in the Symitar core host on the test and production environments. I did everything else myself.
Process
After verifying I had access to a test SymXchange environment, I created a new console application in Visual Studio and generated a connection to the service. This generated hundreds of C# objects that I could use in the real projects I would create next.
While testing this service, I noticed that the SymXchange server was sending some non-XML-compliant text at the beginning and end of the response. This text caused the generated services to throw an exception. This was another reason not to use the generated services.
The generated objects had a lot of extra code in them that I didn’t need. Most of that data was extra attributes related to reading the XML from the SOAP web service. I didn’t need all of those as I would be reading the XML responses myself and converting them to JSON objects. So I created another program to strip out all of that extra code to generate simple code.
After that was done, I created a new Visual Studio solution and started creating C# library projects for the models, service definitions, service implementations, tests, http client, and the WebAPI project itself.
To make a call to the SymXchange web service, I generated my own XML envelope in a method and included the required information to send to the service. Then I posted the XML data to the server using an async HttpClient call.
After checking to make sure the response was a successful response, I retrieved the XML from the response and stripped out the envelope data and the extra text coming from the core. This gave me only the raw XML response. Then I used the Newtonsoft JsonConvert.SerializeXmlNode method to convert the response XML to JSON.
Finally, I parsed the JSON using the JsonConvert.DeserializeObject method to convert the JSON to one of the objects I generated from the web service. This made the sure the response could be serialized back to JSON in a format that a consuming client would be sure to be able to read.
Results
The results were eye opening. The method call response times from the Visual Studio generated code were 800+ms and startup times were nearly 10 seconds. With my code, application startup times were below 1 second and each method call was typically in the 50ms range. Much better.
I have several projects that utilize this service including credit card personalization, board elections, and online account activation.