How to add custom Rest Endpoints to Shared Engine?

Hey guys,
I have a situation where a potential client wants to extend the standard REST API for Camunda.
Generally in an embedded model this isn’t an issue as we just register new controller services.

However, they want to use the shared engine and I am struggling to see how to do it in a supported/sensible way.
Certainly I can rebuild the entire Camunda Engine with the new controllers and this is probably my fallback position, but I imagine when we get the client purchases Enterprise Edition this would put them in an unsupported environment.

Any thoughts or suggestions?
Oh, we are running shared engine over tomcat.

Thanks,
Greg

What is the endpoint you want to add?

Hi,
If you are running on say Tomcat, could you create a small Spring app which encapsulate the REST API you want? In this case the context path may be different to the engine, but it would be the same host etc…

Ive done this style when I have a business object (eg Order). Hence I can use the database and a table to store my business object and I expose a REST API for my process to use. This approach keeps the engine clean, however I can colocate the deployment etc…

regards

Rob

1 Like

It will be a custom endpoint to retrieve specific process variables of type file (i.e. file uploads).

Thanks,
Greg

okay so its really using existing endpoints but to provide a very tailored response?

If yes, I would suggest you create a small nodeJS app that acts as middleware, (or just deploy a new tomcat app to do the same as @Webcyberrob suggests ).
I only suggest the node app as you mentioned shared engine, and depending on your scenario your shared engine/camunda server could be very “hands off”.

Thanks Webcyberrob, this sounds like a viable option.
I guess CORS will be an issue since the contexts are different, but that is a manageable complication.
I like the idea of keeping the main app clean.

I will need to access process engine services, but I should be able to do that using the Bpm Platform services.

Thanks,
Greg

Hi @gdharley
besides the nodeJS app, you could also have a look here:

If you use this then you could remove engine-rest.war from the server and instead use the cutom-rest-api endpoints.

Hope this gives you an idea how it could work.

Best
Felix

2 Likes

Thanks Felix. I will give this a try.
Greg

From an architectural point of view and as a proposal for a long term solution:
Camunda could implement GraphQL into the core engine. GraphQL would be a very good alternative to REST.

That’s funny Hal, I was considering GraphQL as the basis for the extensions I needed to make. :slight_smile:
Certainly if the technology matures it would be a great alternative to RestEasy.
Greg

I would say GraphQL seems to be mature. The status changed from something like “technical preview” to “production ready” by the end of 2016. We are using GraphQL in our Apps as much as possible and it really gives us huge advantages over REST. I would not implement REST anymore.
We are using Apollo (http://www.apollodata.com).

To demo how GraphQL would feel on top of Camunda BPM one could do something like this:


I did the exercise of implementing the (green) GraphQL-Server based on an existing REST-API of another BPMN/CMMN-platform (called Edorasware). I will put the whole project for public access on github soon.

Somewhat independent of the GraphQL integration:
The interesting part is the GraphQL Type System, i.e. the schema that reflects the “Camunda data universe” (plus your custom extensions).
I would love to extend the Camunda BPM core engine with GraphQL.
Anybody wants to join this project?
I know the GraphQL part quite good.

1 Like

Hi Greg,
are you really considering a GraphQL extension? Are you planning to do this in open source? I thought about the same… :slight_smile: Maybe we should share our ideas in more depth?
Harald
greetings from Switzerland

If you’re using the CDI capable app-server and maven archetype, your camunda app (using the shared engine) should be able to provide additional ReST services/endpoints with direct access, via CDI/annotations, into the Camunda engine itself.

Though the endpoint will have a slightly different signature…

/**
 * Access to the Camunda Process API
 */
@Inject
private RuntimeService runtimeService;

then, for example:

@GET
@Path("echoBpm/{processID}/{hello}")
@Produces(MediaType.APPLICATION_JSON)
public String echoBpm(@PathParam("processID") String processID, 
				    @PathParam("hello") String hello ){
	
	LOGGER.info("*** echoBpm - processID: " + processID);
	LOGGER.info("*** echoBpm - hello: " + hello);
	
	ProcessInstanceWithVariables pVariablesInReturn = runtimeService.createProcessInstanceByKey(processID)
											.setVariable("hello", hello)
											.executeWithVariablesInReturn();

‘’’

And, this rest service is defined in the Camunda shared-engine project. So, it’s all in the same deployment.

Not using CDI.
Thanks Gary.

Hal,
Greetings for Austin Tx.
Yes, I am really considering GraphQL.
One of my team ran a recent “labs and larger” (Friday tech presentation with beer) on GraphQL and it looks very promising for the sort of things we do.
Would love to join your open source project to add GraphQL to Camunda as a alternative to the engine-rest module.
Cheers,
Greg

started a new thread here…: Developing the Camunda GraphQL extension

For anyone following along at home, I have ended up creating a bare bones Spring Boot app using spring-boot-starter-web.
For now, I have added a RestController but will likely move to using he spring-boot-starter-graphql project once the kinks are sorted out.

In order to access the shared engine I added the following bean definitions into my spring boot application definition class:

@Bean
public ProcessEngineService getProcessEngineService() {
    return BpmPlatform.getProcessEngineService();
}

@Bean
public ProcessEngine getProcessEngine() {
	return this.getProcessEngineService().getDefaultProcessEngine();
}

Packaging for Tomcat deployment simply means to tag the spring-boot-starter-tomcat dependency as provided, changing the packaging type in maven and adding a servlet entry point:

	@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
    return application.sources(Application.class);
}

All seems to be working pretty well.
The only issue I have right now is hot deployment seems to blow away the shared process engine, still trying to work out why, but a full restart of tomcat brings everything up correctly.

Thanks for all the suggestions and if anyone has any comments on the approach I’ve taken, I’d love to hear.
Greg

Hi @gdharley
I started the open source GraphQL for Camunda BPM project here: https://github.com/Loydl/camunda-graphql
It uses the new graphql-java-tools which lets you write the GraphQL schema language in plain text (same as the JavaScript graphql-tools do).
I started to write some resolvers for tasks, processes and two mutation are included.
Its planned to have this as a Camunda BPM Community Extension.
Got excellent support from Camunda - see initial thread and some tweets from Camunda.
Also added a related blog post: Camunda GraphQL
Check it out and let me know what do you think.

Hi hal,

Sorry I have been radio silent.
Am working on a project with a different technology right now and haven’t had a chance to get back to this.
But, I will definitely check out the project.
Greg