# IntegrationM Scripts Structure
The integrationm folder holds scripts and code for the IntegrationM system. This allows for developers to easily customize behaviour of the CoB ecosystem by adding code to this folder.
Most files that are added here are Groovy scripts. The subfolder where a script is added determines its purpose and how it runs. The internal structure of this folder is:
# Actions and Concurrents
The folders actions and concurrent hold Groovy scripts. A script inside the actions folder is an action, while scripts in councurrent are concurrents.
Both of these kinds of scripts need to be invoked via POST calls to their endpoint. An action called calculateExpenses.groovy will be available on the endpoint:
/integrationm/actions/calculateExpenses
Similar endpoints are available for each action.
These two kinds of scripts differ in whether they are blocking or not. Actions are blocking, which means IntegrationM does nothing else. Requests received during this execution (be it HTTP requests or system messages) are placed on hold and execute once the action finishes. On the contrary, Concurrents execute in parallel and allow IntegrationM to continue working.
# Scripts
The scripts folder holds Groovy scripts that are called when a new message from the system is received. These scripts are always executed regardless of the message and as such, they should start by determining whether to run or not.
The convention for these scripts is that there is one script (when necessary) for each definition, so that all code regarding that definition can easily be found. For example, the definition "Department Purchases" would have a script called department_purchases.groovy. A script handles all the different logics that run when a message regarding that definition is received.
Scripts that start with a _ are associated to specific customizations, por example _calc.groovy. These scripts are automatically added to this folder when the cob-cli customize command executes.
# Common
The common folder holds code that is used in different places of the system. This allows us to refactor code and avoid repetition. Since we are working in the context of Groovy, the code in these needs to be inserted into a class, and its methods accessed as usual.