Request: More docs about what can and cannot be deployed through Rest API

Been going through the docs and seeing lots of questions on Forum, and gaps in docs about deployment specifics…
The API docs for Post deployment indicates your can technically deploy “any file”, but not all files can be used from the deployment.

Example: You can deploy a Java Delegate, but you would not be able to call the delegate from the process. If there further docs you can share about what can and cannot be deployed (and actually used)?

Some specifics of interest:

  1. Various Types of Forms (especially external user task forms)
  2. “External Resrouce” Scripts
  3. Java Classes and Delegates
  4. connectors


Ref to other topics:

  1. Form uploaded via REST api is not getting loaded in tasklist
  2. Deploying Process Application through REST API
  3. Rest deployment
  5. When Forms need external libs: and

Further Refs:

Anyone from Camunda able to provide some additional details? or point to a doc that outlines this?

Thanks! :slight_smile:

Looking at deploying different .js scripts and was looking at some examples.

When deploying through REST, can the various files you are deploying be grouped into different paths?

something like:

In this example, the Script.js in folder 1 is different than Script.js in folder 2.

I ran a quick test with a deployment such as: the js file being deployed to folder1/Script.js but kept the bpmn ref to the file as deployment://Script.js, and the script was still accessible.

Is there a extra config required to make this work?

Anyone have any notes or interesting un-documented features on this?


I know more documentation is available when you opt for Enterprise support. Perhaps this is one of those topics that is available only on the enterprise website.

Hi guys,

In general, any type of resource can be deployed. However, some of those are meaningful to the process engine (e.g. are parsed in to process definitions; can be used as scripts) and some are not (i.e. the process engine will put it into the database but that’s it). This topic is not documented in a central place but the other way round: If for a specific topic deployment resources can be useful, then the respective documentation mentions this. For example, the documentation on scripting describes how scripts can be loaded from a deployment.

Sure, we could additionally document all of those things in one place. I personally am not very fond of documenting one thing in two different places, though, since that enables inconsistencies.

@StephenOTT: Regarding your second last post, where you were asking a question regarding loading of scripts sources: I have trouble understanding the problem description, especially when you write about folders and their relation to the deployment. Could you please provide a test case that shows the behavior that seems odd to you (=> unit testing template) or at least specific steps how to reproduce that (e.g. the exact REST requests you make)?

@nvanbelle: There is currently no Camunda BPM user documentation that is not publicly available.

Have a nice weekend,

@thorben, sorry about that. That is me using the wrong words to explain :slight_smile:
The question was more about being able to group files in a deployment. Currently all files go into the DB in a deployment, and each file gets a ID and the Name attribute. It would be great if there was a way to add dot notion or some sort of Tag/group attribute to each file as part of the deployment, so we could sort through the deployment files more easily. Example use case could be if you have many embedded forms as part of many processes in a single deployment. You may want to “group” the forms by process. basically the equivalent to “folders”.

Hi @StephenOTT,

Thanks for the clarification.

When deploying via Java API (ManagementService#createDeployment), the resource names can be freely chosen. See the DeploymentBuilder#add* methods.

When deploying resources as part of a process application where the resources are added automatically by the process engine (e.g. by declaring them in processes.xml), then the path to the file on the classpath becomes the resource’s name. Note that you can customize deployment by overriding the method #createDeployment in a ProcessApplicationInterface class.

When deploying via REST API, the resource’s name is chosen as the filename that is passed with the form part that contains the data. I guess that this does not include the path on the machine you upload the resources from, so separation could be done here by using dot notation in the file names, e.g. process.order-processing.script.1.js.