At my latest work place, which is a Learning Content Provider, I got the opportunity to do integration work for the content we store in our database to two external learning platforms called EdCast and Cornerstone Ondemand.
In this article I’m writing the things I learned when I was doing the integration work.
The integration with EdCast was based on REST API where our platform would periodically push the content to EdCast through their APIs. One of the problems I had when integrating with EdCast was that I didn’t have an environment to test the changes. So during development it was uncertain that my code would work once deployed.
The option I took in this case was to create a mock server to simulate the EdCast API interfaces. By referring to their API docs, I created the mock server endpoints. At least this way I could verify that our system calls the endpoints correctly with the correct payloads during a sync.
However this is far from perfect. If I had miss some point their API docs or if the API docs are not up to date, the way I created the mock server would be inconsistent from the actual behavior.
When I did the deployment and performed the sync with their environment, I’ve noted few incidents that didn’t work as expected. If I had the staging environment earlier I’d have found them before.
When I worked on Cornerstone integration. I had a Cornerstone staging environment during development. This was immensely useful as the integration was tested with different configuration to decide what works for our company. Since Cornerstone is heavily customization compared to other learning platforms, it was essential that I could try out the platform.
Have a contact from the Learning Platform
During the work you might encounter issues questions or approaches you want to check with from someone on the learning platform team.
When I was working in EdCast integration at the beginning I didn’t have a contact from their company to communicate with and I only got the opportunity almost 75% of the work is completed.
I had raised this concern with my manager so for the next integration, we were prepared upfront. We had contact points from Cornerstone and after the initial investigation, we arranged a call with their consultants to discuss the approach I proposed.
Communicate any assumptions made
It might be the case that you sometimes encounter situations where you might have an approach that you might consider to suppose to work but not certain. They should be communicated with the consultants.
This is to ensure they are aware of you the approach and that they can raise any concerns. Also if there are some unforeseen issue arise due the approach, you can depend on the consultants for their response.
Ensure adequate logging in place
In production when integration code runs the platform sync, there are many things that can go wrong. For EdCast the integration was based on REST API while for Cornerstone, it was CSV files placed on an FTP server.
So to debug issues effectively when things go wrong, ensure proper logging is done. AS this will be hte way to figure out what went wrong.
When dealing with network requests there are different ways that the request can be interpreted. This could be to hardware or service limitations such as rate limiting. You would want to refer the learning platform documentation to find out that the limitation and possible errors that can happen and handle them in your integration code.