Instantiation d'un processus via API BPM avec en entrée un contenu Json pour un champs du contrat

Q&A
1

Bonjour ,

J'utilise la version 2022.1.

J'aimerais pouvoir lancer mon processus via l'API BPM

Voici le contrat de mon pool via l'API

{
    "inputs": [
        {
            "inputs": [],
            "type": "TEXT",
            "description": null,

            "name": "clients",
            "multiple": false
        }
    ],
    "constraints": []
}

Le contenu the clients étant le json suivant pour mon test

{"clients" : [
    {
        "id": "0010001",
        "firstname" : "Boris",
        "lastname" : "Johnson",
        "comment" : "UK ex  Prime Minister"
    },
    {
        "id": "0010002",
        "firstname" : "Emmanuel",
        "lastname" : "Macron",
        "comment" : "France Prime Minister"
    },
        {
        "id": "0010003",
        "firstname" : "Joe",
        "lastname" : "Biden",
        "comment" : "USA president"
    },
    {
        "id": "0010004",
        "firstname" : "Yoshihide",
        "lastname" : "Suga",
        "comment" : "apan  Prime Minister (predecessor DEAD)"
    },
    {
        "id": "0010005",
        "firstname" : "Mario",
        "lastname" : "Dragh",
        "comment" : "Italy ex Prime Minister"
    }]}

 J'essaie donc d'instancier le processus  via API/bpm/process/:processid/instantiation avec un POST , mais malheuresment j'obtiens un code hhtp 400  et le message d'erreur suivant dans le log BONITA, malgres que la syntaxe Json semble correct:

2022-09-05T12:28:23,419+0200 | ZRH30479n | INFO  | [http-nio-8080-exec-2|91] o.r.C.BonitaRestletApplication - Error while validating expected inputs
Explanations:
[{id=0010001, firstname=Boris, lastname=Johnson, comment=UK ex  Prime Minister}, {id=0010002, firstname=Emmanuel, lastname=Macron, comment=France Prime Minister}, {id=0010003, firstname=Joe, lastname=Biden, comment=USA president}, {id=0010004, firstname=Yoshihide, lastname=Suga, comment=apan  Prime Minister (predecessor DEAD)}, {id=0010005, firstname=Mario, lastname=Dragh, comment=Italy ex Prime Minister}] cannot be assigned to TEXT

Merci de votre aide.

 

david

2

Bonjour David,

La payload du POST devrait avoir le format suivant:

{ "clients" : "Du texte" }

Si vous souhaitez envoyer la payload de votre test, votre contrat devrait plutot ressembler a ca:

{
“inputs”: [
{
“inputs”: [
{
“inputs”: ,
“type”: “TEXT”,
“description”: null,
“name”: “id”,
“multiple”: false
},
{
“inputs”: ,
“type”: “TEXT”,
“description”: null,
“name”: “firstname”,
“multiple”: false
},
{
“inputs”: ,
“type”: “TEXT”,
“description”: null,
“name”: “lastname”,
“multiple”: false
},
{
“inputs”: ,
“type”: “TEXT”,
“description”: null,
“name”: “comment”,
“multiple”: false
}
],
“type”: “COMPLEX”,
“description”: null,

        "name": "clients",
        "multiple": true
    }
],
"constraints": []

}

You can use the Studio to designed th contract where clients is a multiple COMPLEX input. Or even, initialize the contract from a Business Object if it make sense in your case.

HTH
Romain

3

4

Merci Romain pour votre réponse rapide.

L'idée que j'essaie de designer et d’implémenter dans un POF serait d’avoir un process générique qui accepte en entrée virtuellement tout type de format JSON, qui seront exploité par des connecteurs qui accepteront en entrée aussi ces formats.

Pour cette raison, je n’aimerais idéalement pas lier la structure de données du processus (Business object) au format JSON puisque qu’il est libre.

Idéalement, j’aimerais avoir un processus générique ouvert, dont les instances peuvent être paramétriser pour accepter des formats JSON différents en entrée et dont le traitement par les connecteurs adéquat serait défini par paramétrisation du processus générique. On aurait dont un processus générique que l’on pourrait décliner en des processus spécifiques traitant adéquatement l’entrée JSON.

Qu’en pensez-vous ?

La notion de contrat n’étant pas conditionnel m’indique qu’il est obligé de redéfinir le processus pour chaque type the JSON en entrée, est ce correct ?

Cordialement.

david

5

C’est en effet possible, mais j’attire votre attention sur:

  • Les problématique de validation de la donnée en entrée (et des risques associes)
  • La maintenance et la documentation d’une telle solution (il faudra d’une maniéré ou d’une formalise les formats accepte en entrée et bien mettre a jour le tout a chaque évolution)

et du coup, pour réparer le souci dans votre question initiale, il faut bien penser a mettre la valeur de clients entre " puisqu’il s’agit d’une String.

Cordialement

6

Merci beaucoup pour vos réponses et conseils.

 J’avais réussi entre temps en prenant soin de formatter ma requête avec le " préfixé de \ comme ceci :

{"input" : "{\"clients\" :[{\"id\": \"0010001\",\"firstname\" : \"Boris\",\"lastname\" : \"Johnson\",\"comment\" : \"UK ex  Prime Minister\"},{\"id\": \"0010002\",\"firstname\" : \"Emmanuel\",\"lastname\" : \"Macron\",\"comment\" : \"France Prime Minister\"},{\"id\": \"0010003\",\"firstname\" : \"Joe\",\"lastname\" : \"Biden\",\"comment\" : \"USA president\"},{\"id\": \"0010004\",\"firstname\" : \"Yoshihide\",\"lastname\" : \"Suga\",\"comment\" : \"Japan  Prime Minister (predecessor DEAD)\"},{\"id\": \"0010005\",\"firstname\" : \"Mario\",\"lastname\" : \"Dragh\",\"comment\" : \"Italy ex Prime Minister\"}]}"

Pour le coup, n'est il pas possible d'envisager, dans le type de données des contrats, des type ouvert comme du XML ou JSON voir même pour les "business variables". 

Bien entendue la validation devra être faite par les connecteurs traitant ces inputs.

Il va de soi que chaque déclinaison de ce processus générique devra être documenter, le but ici étant de fournir un(des) processus générique(s) standards et paramétrable(s) mais aussi extensible(s).

Plus concrètement dans mon POC on fait du reporting dont le processus et identique pour chaque rapport mais, chaque rapport peut avoir des données d’entrées différentes et une logique de génération des données et de document différent. De nouveaux rapports peuvent être rajouté après même la définition du processus.  Voyez vous une autre approche a ce genre de problématique ? 

 

 

7

Peut etre utiliser un Business Object qui represente un ReportTemplate avec toutes ces infos ? Vous auriez la flexibilite de creer des templates a posteriori tout en gardant un modele structurer. Reste a savoir si vous avez la possibilite d’avoir un template de rapport suffisament stable pour ne pas avoir a mettre a jour vos process a chaque nouveau template.

Bon courage