Integrations and automations are at the heart of digital efficiency. But what makes an integration successful, secure, and scalable? We sat down with one of Bosbec’s experienced support technicians, Johan Levin, to hear his best advice for building smart, future-proof workflows in the Bosbec platform.
When someone wants to build an integration in Bosbec – where do you recommend they start?
Consider what you are trying to achieve with the integration. What problem are you trying to solve? Sometimes, the integration can be much simpler and lightweight than you may initially think.
Identify what data you need to move and where to find it. When you have the data, does it perhaps need to be transformed to a different format or changed in other ways to suit the target system?
When you’ve answered these questions, start thinking about the integration’s building blocks (import, export, transform, calculations, etc.) and the jobs, triggers, and resources necessary to build them.
What are common mistakes people make when building integrations?
As I hinted at in the previous questions, workflows are usually made up of smaller blocks of tasks that together become a more complex system. I often see that users may try to build the whole solution at once instead of breaking it down into smaller tasks that are easier to tackle one by one.
It’s also common to assume that because the workflow is not working, there must be something entirely wrong with the workflow or the chosen jobs. But often times it’s just a simple spelling error or a date saved in the wrong format. Relax, read through the job stories and logs, and try to locate the source of the issue and work from there.
What about security — what should users think about?
I suggest that you make sure that some form of authentication process is active.
For example, the HTTP channels look at the header “Authorization” in the incoming requests to find a valid API token (created in the admin platform).
But sometimes this header cannot be added due to limitations of the system you are trying to integrate with. In these cases, I’d recommend looking into what alternatives they do support. Oftentimes, you can leave the trigger public and build an authorization process in the actual workflow instead. For example, add a route from metadata-job and check for a specific key in the request query, or a username/password in the request body.
Another thing to consider is GDPR and how you store your data. You should only save the data you actually need, even if the incoming request sends more than that, and build a cleaning workflow that removes data once it is no longer needed.
How do you recommend testing before going live?
I usually test each part of the workflow as I go along.
Supposing that I am building a workflow where I will receive a request, parse the data, transform it, and send it to a different system. I would first set up a trigger and channel and make a request from the original system to the workflow. I now know that the endpoint and trigger work and what data I can expect from the original system.
After that, I might build a dummy request using the target system’s documentation and make a request using that. Is there anything I need to change, or does the format work?
Once I’ve done these two tests, I proceed to parse and transform the data, testing these processes, and so on.
It can also be beneficial to force some errors to occur so that you can account for this before going live. For example, what happens if the incoming request is missing an ID? Or what do I do if the target system is not responding? Sending a request to an incorrect URL or providing incorrect authorization details can help guide you in this.
When I have done enough tests to feel confident it works as intended, I activate whatever I need to in the original system and let the workflow run.
In short, I am performing different tests throughout the building process.
Do you have any tips for making integrations more maintainable in the long run?
Ask yourself, “How can I troubleshoot this in six months when it’s no longer fresh in my mind?” What seemed logical while building can be difficult to understand later despite you having built the solution.
Name your jobs and resources, and document why you made the choices you did so that you can look back at it when asking yourself, “Why am I creating a unit here?”
Structure the workflow in a way that makes it easier for you to navigate, troubleshoot issues, fix problems, and expand upon it.
What’s your favorite “hidden” feature in Bosbec that people should use more?
We have a feature called the “Workflow Library,” where you can access simple snippets and templates that can serve as inspiration for your own solutions. It’s a great place to look when trying to learn new ways to build.
In the admin platform, we also have Account Settings, where you can add metadata key-value pairs that can be accessed during workflow executions. These act as global variables that you can reference in any workflow instead of hardcoding values directly into jobs. This allows you, for example, to update a supplier’s API key in one place instead of searching through all the locations where it might have been written.
