CMDBuild Forum

Workflow Automation with IAC tools

Programming and Web Services
#1

Hello Everyone,

I ask for your helps because I am quite stuck since days :’(.

I am working on a proof of concept, linking a cmdb (like cmdbuild) to IAC tools (like ansible tower).

I saw that cmdbuild come with one orchestrator, River or Shark workflow engine.
So i would like to use them to do so.

To write a new process with have to use xpdl format.
I just discover that format so I am not an expert on it, but from what I understood/read, it is possible to add external process’ call inside workflow.
To do so, an application need to be add inside package passing by extended attributes and ToolAgentClass.

Have someone done something similar or am i following a false lead ?
Am I trying to hack workflow engine purpose ?
If not, do you have some basic examples ?

I can not find any documentation related to that with River workflow engine.
So I am stuck with Shark workflow engine which seem to be an old version 4.4-1 (release in 2012).

Is Shark engine still a good choice or is it encouraged to use River engine ?

Kind regards,

#2

Please, read about Rundeck for automation IT tasks. You can run it, from widget or workflow.

#3

Thanks for your answer,
Have you got any documentations/example describing Rundeck integration ?
I can not find anything on cmdbuild website.

#4

@tecnoteca: Have you got any documentation related to Rundeck integration ? What is your recommendation ?

#5

No I’m sorry, we have no documentation on this.
However, both CMDBuild and Rundeck have a REST webservice, and it is therefore possible to create an external client that implements the communication between the two systems.

#6

Thanks a lot for your answer but I am quite confused.

From what said @pavel.kuznetsov, i’m throught we do not need any external client, as it seem we could trigger it directly from widget or workflow.

From my point of view, It seem to be quite overkill to create an external client to work as webhook’s boilerplate.
Am I missing something ?

I wanted to use ansible-tower to run some automated tasks, do you think i can call it directly from cmdbuild or should i keep rundeck as an abstraction layer ?

How can I secure rundeck trigge with cmdbuild user ?
Is it possible to share authentication with a sso or openIDConnect/IdP mecanism ?

Thanks a lot for your helps,

Kind regards,

#7

Thanks a lot, @pavel.kuznetsov

I finally had success to use form trigger to post request.

If someone else is looking for something similar, here is an exemple.
It is still a draft but I hope that could help.

Code for “Create new form trigger” from class object :

Ext.Ajax.request({
    url: '< URL >',
    method: 'POST',
    timeout: 60000,
    headers:
    {
        'Authorization' : auth
    },
        success: function (response) {
            
        Ext.Msg.alert('Status', 'Request Success ');
    },
        failure: function (response) {
        Ext.Msg.alert('Status', 'Request Failed ' + response.responseText);
    }
});

for (const element of arguments) {
  console.log("Code: ", element.record.data.Code);
  console.log("Description: ", element.record.data.Description);
}
1 Like
#8

Hi Alfred,
First, congrats for discover how to set this code, but I have a doubt, where I can insert this type of code?

In fact I’m searching for a way to dispach a request (webhook) from CMDUILD (in fact I using Openmaint) to my server every time an event is fired (like sent of an email), do u know how I can do something like this?

#9

You’re not completely on a false path, but I think you’re mixing two different goals that usually get separated in production setups.

What you’re trying to achieve (CMDB → orchestration tool like Ansible Tower/AWX) is very common, but most implementations don’t rely on XPDL workflow engines as the integration layer anymore. Those engines (Shark/River) were designed more for structured business processes, not for acting as an automation bus between infrastructure systems.

A few key points from experience with similar setups:

Yes, XPDL can technically call external services via extensions / ToolAgents, but that quickly becomes “framework hacking” rather than clean integration.
Documentation around River is indeed quite sparse because most of the ecosystem moved away from that workflow model years ago.
Shark being older doesn’t necessarily make it unusable, but it’s effectively legacy in terms of community support and real-world adoption.

In practice, most modern CMDB + IaC integrations look more like this:
CMDB (source of truth) → event/API layer → automation engine (Ansible/AWX) → feedback loop into CMDB.

Instead of embedding orchestration inside the workflow engine, the workflow engine is usually replaced by something lighter (event-driven logic, API triggers, or message queues). That avoids the need to “force” XPDL into a role it wasn’t really designed for.