The following is the onboarding integration project that I developed during my first period at Thread Solutions.
When a new member joins the team, it is extremely important to have a solid onboarding plan. A structured learning strategy for newcomers helps them to become rapidly familiar with all technologies that we use in our business.
At Thread Solutions, our study path covers many technologies commonly used in modern IT, but the main focus of our onboarding plan is API development and MuleSoft’s API-led connectivity. The first, and probably most important, building block of the plan is the Mule Development Fundamentals Course which introduces beginners to API development using MuleSoft’s Anypoint Platform.
But, of course, attending a course is just the first step — after having learned the fundamentals, it’s time to address a real and challenging problem. Therefore, once the course concluded, I started to develop an internal project, under the supervision of a senior developer. Although it was approached as a “study project,” it was also a real project with outcomes that improve our business (i.e. it was intended to follow the full lifecycle, from development to production).
The following is the onboarding integration project that I developed during my first period at Thread Solutions.
The integration project
The problem: we use Avaza as a project management platform. All aspects of our business must be managed from Avaza. In particular, any paid-leave request must be submitted and approved through Avaza. At the time, the paid-leave scheduling for the team was a bit complicated because it was not possible for everyone to have a global view of requests. For the convenience of the whole team, we wanted to see all scheduled absences from work on a (Google) calendar. Thus, we had to build an integration system to connect Avaza and Google Calendar through their APIs.
After the initial analysis of the problem, which was useful to learn the API-led fundamentals, I decided to implement the following solution. First, we need two system APIs (s-APIs in the below diagram) to communicate with Avaza and Google Calendar. Building such system APIs is always a good practice because they provide an abstraction layer from the external world. After that, we needed a process API (p-API in the diagram), which implements all business logic. In this particular case, it was an “If This Then That,” IFTTT, application.
The development of the two system APIs is challenging on its own. Although these two API do not implement any logic, their development provides the opportunity to become familiar with technologies such as oAuth2, which is used to authenticate on Google and Avaza APIs. Fortunately, Mule has an extremely well-done structure that permits users to handle this (common) scenario easily.
On the other side, the process API implements all logic that we need for the project. It takes advantage of the two system APIs to retrieve data from Avaza and, after some validation logic, writes them on Google Calendar. Also, the development of this process API taught me some best practices of modern IT — when a paid-leave is requested, Avaza sends a webhook to our process API, so we had to implement a reliability pattern. For this reason, we used a database, hosted by Amazon Web Services (AWS), to store all data received from Avaza. Subsequently, the process API takes data from the database and processes them (or reprocesses, in case of errors). Finally, since all APIs are hosted on CloudHub, the process API takes advantage of CloudHub notification system to manage alerts and bad requests.
As part of the onboarding strategy, all presented structure was not planned in the beginning, but instead, an incremental approach was used: I started with some simple tasks, and then I added additional features step-by-step (additional logic, error handling, and, in the end, a full reliability pattern).
This project – which is, of course, simple when compared with projects that we handle with our customers – gave me a solid introduction to MuleSoft’s integration technologies and served as a good foundation for future customer-related projects.
Other MuleSoft capabilities
It is remarkable that this integration system is now deployed to production environment, and it is fully functional! It is worth noting that during the development of this internal project, which is of course developed as a learning path for newcomers, we were also able to test some of MuleSoft’s new, cutting-edge products. For example, this is how Anypoint Visualizer automatically shows the actual implementation of the project:
The duplication at the process layer is due to the fact that we used our service server to call APIs (i.e. there is actually only one process API).
Another example is Anypoint Monitoring, which shows all API metrics, which you can see in the figure below of our process API.
To learn more about Anypoint Platform and become a MuleSoft certified developer, visit the MuleSoft training page.
This article first appeared on Thread Solutions’ blog.
