These are chat archives for effektif/effektif

13th
May 2015
Tom Baeyens
@tombaeyens
May 13 2015 06:39

Now I understood the preferred way to deploy/execute flows was via the REST api

From the project perspective, Java API and REST API are equal. You might have your own preference, though. The REST API is not yet finished. So for now it’s better to start with Java API

Use JsonStreamMapper to convert workflow objects to json. Easiest way to get it is configuration.get(JsonStreamMapper.class)

Do you have a document describing the rest api? (and preferably an example)

We don’t have docs about this yet as it’s still under construction. But you can look at effektif-server/src/test/java/com/effektif/server/test/ServerTest.java

Tom Baeyens
@tombaeyens
May 13 2015 06:45

What is the /message api endpoint

It’s used when a workflow instance is in a wait state. The message request is for saying to the engine: 'This activity instance is now done and the engine should continue to execute the workflow from there' It s equivalent to java api WorkflowEngine.send(Message)

jblankendaal
@jblankendaal
May 13 2015 07:33
Thanks, got it working (using jersey, rest-easy is actually my preferred library, but I'll try that later) with the following code:
        final String url = "http://localhost:9990/deploy";

        ClientConfig clientConfig = new ClientConfig();
        JsonStreamMapper jsonStreamMapper = new JsonStreamMapper();
        clientConfig.register(new EffektifJsonProvider(jsonStreamMapper));
        Client client = ClientBuilder.newClient(clientConfig);

        WebTarget target = client.target(url);
        Deployment deployment =
                target.request()
                        .accept(MediaType.APPLICATION_JSON)
                        .post(Entity.entity(workflow, MediaType.APPLICATION_JSON))
                        .readEntity(Deployment.class);

        System.out.println("Deployed: " + deployment.getWorkflowId());

Maven dependencies:
>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.2.2</version>
</dependency>

    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.2.2</version>
    </dependency>

    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-annotations</artifactId>
        <version>2.2.2</version>
    </dependency>

    <dependency>
        <groupId>com.effektif</groupId>
        <artifactId>effektif-workflow-impl</artifactId>
        <version>3.0.0-alpha2-SNAPSHOT</version>
    </dependency>

    <dependency>
        <groupId>com.effektif</groupId>
        <artifactId>effektif-server</artifactId>
        <version>3.0.0-alpha2-SNAPSHOT</version>
    </dependency>

>

I think it might be useful to move JsonStreamMapper to the api module...
Tom Baeyens
@tombaeyens
May 13 2015 08:01
Could makes sense to expose json transformation as part of the API
i ll think about it to see if there are any hidden gotcha’s to that approach
It could be an idea to include support for multiple rest frameworks to the engine. Where the current server module maps the java api to rest with Jersey, another module could do the same mapping with Rest easy. Though I m not yet sure if this duplicate maintenance effort is worth
Question is : will developers see it as an advantage to have their framework of choice?
or are most just looking for a REST server that works
in the latter case, we just have to provide one
jblankendaal
@jblankendaal
May 13 2015 15:29

As we probably will mainly communicate with the Effektif server from C# / .Net, we will focus on the interface from C#. Please let me know if you would be interested to have this you repository.

Another question: if we pick up the deprecated UserTask / task classes, would you want to keep our modifications in your repository?

I will be on vacation the next 2 weeks. In the mean time my colleagues will work on the requirements.

Tom Baeyens
@tombaeyens
May 13 2015 15:31
Would be great to have an Effektif driver (orclient) for C# / .Net as part of the project somewhere.
for the task component, i think that’s better to have that in a separate, non-effektif repository for now. i ld see that as a labs thing for now. we might one day promote our task/cases component to the open source engine as well after we have the time to clean it up. but that is unsure for now how that’s going to go
Philipp Giese
@frontendphil
May 13 2015 15:38
I would suggest, that any drivers / adapters for other langauges should go into a separate repository. This does not mean, that it shouldn’t be under the effektif brand. I just think that we pollute the main repo for the engine, if we put everything in there.
Tom Baeyens
@tombaeyens
May 13 2015 15:39
makes sense