Our onboarding strategy: a first integration project for beginners

Alberto Melati talks about his onboarding experience in Thread Solutions

When a new member becomes part of the team it is extremely important to have a great and solid onboarding plan. A structured learning strategy for newcomers helps them to become rapidly familiar with all technologies that we use in our business.

Our study-path covers a lot of technologies commonly used in modern IT, but the main focus of our onboarding plan is on APIs development and MuleSoft API-led connectivity. The first, and probably most important, building block of the plan is the “Mule Development Fundamentals Course” which serves to introduce a beginner to APIs development using MuleSoft’s Anypoint Platform. But, of course, attending a course is not enough: after having learned the fundamentals it’s time to address a real and challenging problem. Therefore, once the course was 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 whose outcomes now helps us to improve our business (i.e. it was intended to follow all the lifecycle from development to production). The following is the onboarding integration project that I developed during my first period at Thread Solutions.
 

The challenge

We use avaza.com as management platform. Everything regarding any aspect of our business must be managed from Avaza. In particular any paid-leave request must be submitted and approved through Avaza. Currently the paid-leave scheduling for the team is a bit complicated because it is not possible for everyone to have a global vision of requests. Thus, for the convenience of the whole team, we want to see all scheduled absences from work on a (Google) calendar. Thus, we have to build an integration system which connects Avaza and Google Calendar through their APIs.

The solution

After the initial analysis of the problem, which was useful to learn the API-led fundamentals, I decided to implement the following solution. First of all we need two system-APIs (sAPI) to communicate with Avaza and Google Calendar. To build such sAPI is always a good practice because they provide an abstraction layer from external world. After that, we need a process-API (pAPI) which implements all business logic (in this particular case it will be an If This Then That, IFTTT, application).

The development of the two system-APIs is challenging on its own. Although this two APIs does not implement any logic, their development gives the possibility to become familiar with some modern technologies such as oAuth2 (which is used to authenticate on Google and Avaza APIs). Fortunately Mule has an extremely well-done structure that permit to handle this (common) scenario easily. 
On the other side the process-API implements all logics that we need in the project. It takes advantage of the two sAPI to retrieve data from Avaza and, after some validation logics, write them on Google Calendar. Also the development of this pAPI gives the possibility to learn some best practices of modern IT: when a paid-leave is requested, Avaza sends a webhook to our pAPI and thus we have 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 pAPI takes data from the DB and process them (or reprocess, in case of errors). Finally, since all APIs are hosted on CloudHub, the pAPI takes advantage of CloudHub notification system to manage alerts and bad request.
As part of the onboarding strategy, all presented structure was not planned at the beginning, but instead an incremental approach was used: I started with some simple task and then I added additional features step by step (additional logic, error handling and, at the end, a full reliability pattern).

This project, which is of course simple if compared with projects that we handle with our customers, gave me a nice and solid introduction to MuleSoft integration technologies and thus it serves as a good foundation for future, customer-related, projects.
It is remarkable that this integration system is now deployed to production environment and it is fully functional!
 

In conclusion

It is noteworthy that during development of this internal project, which is of course developed as a learning path for newcomers, we were also able to test some new MuleSoft’s cutting-edge products (such as Anypoint Visualizer and Monitoring) with benefits for the whole team. For example this is how Anypoint Visualizer automatically shows the actual implementation of the project:

The duplication at process layer is due to the fact that we used our service server to call APIs (i.e. actually there is only one pAPI).

Another example is Anypoint Monitoring which shows all metrics of APIs (in the figure below of our process-API):