Problème de perte de données lors s'appel API

Bonjour,
On utilise les API (com.simplicite.webapp.services.RESTMappedObjectsExternalObject) pour exposer nos données à l’un de connexe.
Il a un job qui tourne chaque jour pour récupérer toutes nos données modifiées à partir d’une certaine date, lors de la récupération de données il parcourt page par page (on a mis en place une pagination)
Le problème qu’on a : c’est que lors de l’appel on a des traitement qui tournent au même temps et qui augmente le count et on a remarqué qu’on procédant de cette manière notre connexe perd de la donnée.
On aimerait savoir s’il y a une manière pour garder le même count récupéré au premier appel ( une sorte de cache) .

Je vous remercie d’avance.

Cdt,
Laila

[Platform]
Status=OK
Version=5.1.44
BuiltOn=2022-05-10 18:36
Git=5.1/a51516647c95b8cab51e136ca72a2a5e5c30e27c
Encoding=UTF-8
EndpointIP=172.20.179.40
EndpointURL=http://mla-api-57bcd487f-lf27l:8080
TimeZone=Europe/Paris
SystemDate=2022-08-26 06:28:59

Il n’existe pas nativement de mécanisme qui pemet d’itérer sur une liste paginée “figée” alors que des choses sont en train d’être modifiées.

En effet le principe de la pagination c’est justement de ne pas monter en mémoire l’intégralité des données, donc forcément la lecture se fait à la demande.

Votre pb est à aborder d’une autre manière = ex: effectuer vos traitement sur une instance A et vos lectures sur une instnace B et basculer de A vers B un fois les traitements terminés ou dans le genre

Il faut à mon avis revoir la façon de paginer sans faire de “count”.
Ou alors rendre tout votre process atomique = poser un verrou car vous êtes en concurrence d’accès.

Une idée qui n’a pas besoin de verrou : boucler sur la page 0 tant qu’elle n’est pas vide, en supposant que le select filtre bien les enregistrements non encore synchronisés.

Faire...
- page 0 = select des objets non synchronisés limités à 100 (ex: antérieur à un timestamp)
- pour chacun / boucle pour faire les mises à jour 
   - faire des trucs métier
   - et le marquer comme synchronisé (ex: changer un timestamp sur le record, pour pas le retraiter, un programme tiers ira aussi changer le timestamp donc il sera bien repris au prochain passage)
Tant que page non vide

Bonjour,
Merci pour vos réponses François et David. On a envisagé de faire l’appel sur un intervalle, autrement dit positionner un filtre de type “range de date” sur le call API cela peut permettre à notre connexe d’avoir un count stable et par la suite il aura pas de perte d’informations ( par exemple : items/v1/aftersales-items?referentialLastUpdate>=‘2022-08-01’&referentialLastUpdate<=‘2022-08-25’)
Malheureusement, cela ne fonctionne pas.
A-t-on un moyen de faire un appel sur un intervalle de date?

Topic ré-ouvert suite à relance utilisateur

La syntaxe pour un filtre de type intervalle sur les API REST est soit <date min>;<date max>, ex:

curl -H "Authorization: Bearer $TOKEN" "https://dev5.dev.simplicite.io/api/rest/DemoOrder?demoOrdDate=2022-01-01;2022-06-01"

Soit en utilisant les préfixes dmin__ et/ou dmax__ (attention il y a bien un double underscore dans ces préfixes) , ex:

curl -H "Authorization: Bearer $TOKEN" "https://dev5.dev.simplicite.io/api/rest/DemoOrder?dmin__demoOrdDate=2022-01-01&dmax__demoOrdDate=2022-06-01"

Bonjour David,
On a fait un test sur nos instances (aussi en curl), les filtres ne fonctionnent pas en utilisant les deux syntaxes proposés.
L’API nous remontes toutes les références en bases.
On voudrait savoir si on a besoin d’une surcouche dans le code pour faire fonctionner les filtres ou c’est native simplicité?

Cordialement,
Laila Bouzidi

On parle de quelles APIs ?

Des API standards REST (c’est de celles là dont je parle dans ma réponse) ou d’API mappées à la mode Renault ?

Hello David,
On parle d’API mappées à la mode Renault (en utilisant RESTMappedObjectsExternalObject)

Cordialement,
Laila Bouzidi

Effectivement, de ce que je vois ces APIs mappées ne gèrent pas encore les filtres de type “intervalle de date/datetime” car c’est traité dans le cas des APIs standard à un niveau par lequel les APIs mappées ne passent pas. On va revoir ça pour gérer la syntaxe <date min>;<date max>

PS: par contre êtes vous toujours en 5.1 ? Je pose la question car cette version mineure n’est plus en phase de maintenance

L’évolution est faite en 5.2+ et sera livrée avec la révision 5.2.19 prévue dans la semaine.

J’attend votre réponse sur la version que vous utilisez pour voir s’il est envisageable de backporter sur cette branche qui n’est plus maintenue. En tout état de cause je vous suggère de consulter la release note 5.1 pour voir ce qui a été corrigé depuis la révision 5.1.44 (qui date de début mai): Simplicité® 5/releasenote/releasenote-5.1, quelle que soit la version mineure que vous utilisez il est impératif de vous maintenir à jour régulièrement pour bénéficier de ces corrections.

1 Like

Hello David,
La version qu’on utilise est :
[Platform]
Status=OK
Version=5.1.44
BuiltOn=2022-05-10 18:36
Git=5.1/a51516647c95b8cab51e136ca72a2a5e5c30e27c
Encoding=UTF-8
EndpointIP=172.20.179.4
EndpointURL=http://mla-api-57bcd487f-qbvdf:8080
TimeZone=Europe/Paris
SystemDate=2022-10-11 14:14:59

Cordialement,
Laila Bouzidi

OK on verra pour backporter cette évolution en 5.1 mais on a pas prévu de nouvelle révision à court terme sur cette version mineure plus maintenue.

De manière plus générale vous devriez envisager une migration en 5.2. A minima, il faut vous maintenir à jour sur votre version mineure 5.1 plus régulièrement (la révision actuelle est la 5.1.51, cf. la release note indiquée dans mon message précédent)

1 Like

Pour information une révision 5.1.52 est poussée ce soir, elle embarque l’évolution ci-dessus cf. Simplicité® 5/releasenote/releasenote-5.1

PS: Coté 5.2 une 5.2.19 sera poussée demain, elle aussi embarquera cette évolution.

1 Like

Bonjour David,
On a fait un test sur nos instances (aussi en curl), les filtres ne fonctionnent pas en utilisant les deux syntaxes proposés.
L’API nous remontes toutes les références en bases.
[Platform]
Status=OK
Version=5.1.52
BuiltOn=2022-10-14 15:38
Git=5.1/c6fb125e7bd075a3ba4950ff2d54caff53d171ca
Encoding=UTF-8
EndpointIP=172.20.179.142
EndpointURL=http://mla-api-59dbb96bf-smvtc:8080
TimeZone=Europe/Paris
SystemDate=2022-10-20 08:23:31

Cordialement,
LBouzidi

Je ne reproduis pas ce que vous indiquez => en 5.1.52 les API mapped supportent bien la syntaxe <min date>;<max date> conformément à ce qui est dit dans la release note (elles ne supportent pas les syntaxes avec prefix dmin__ et dmax__)

Vous devez faire une erreur dans votre syntaxe d’appel ou vous êtes dans un cas particulier qu’il va falloir nous détailler.

Exemple:

Obtention du token:

export TOKEN=`curl -s -u designer:Passw0rd "https://testdaz51.dev.simplicite.io/api/login"`

Appel API standard avec filtre de période:

curl -s -H "Authorization: Bearer $TOKEN" "https://testdaz51.dev.simplicite.io/api/rest/Responsability?rsp_start_dt=2020-01-01;2023-01-01" | jq '.'
[
  {
    "row_id": "76",
    "rsp_login_id": "1",
    "rsp_login_id__usr_login": "designer",
    "rsp_group_id": "10",
    "rsp_group_id__grp_name": "APP_ADMIN",
    "rsp_start_dt": "2022-10-20",
    "rsp_end_dt": null,
    "rsp_activ": true,
    "row_module_id": "31",
    "row_module_id__mdl_name": "ApplicationUsers"
  }
]

Appel API mappée avec le même filtre:

curl -s -H "Authorization: Bearer $TOKEN" "https://testdaz51.dev.simplicite.io/api/ext/TestAPI/resp?date=2020-01-01;2023-01-01" | jq '.'
{
  "resp": [
    {
      "date": "2022-10-20",
      "row_id": "76",
      "login": "designer",
      "group": "APP_ADMIN"
    }
  ]
}

Appel API mappée avec filtre plus large:

curl -s -H "Authorization: Bearer $TOKEN" "https://testdaz51.dev.simplicite.io/api/ext/TestAPI/resp?date=2000-01-01;2023-01-01" | jq '.'
{
  "resp": [
    {
      "date": "2000-01-01",
      "row_id": "42",
      "login": "designer",
      "group": "ADMIN"
    },
    {
      "date": "2022-10-20",
      "row_id": "76",
      "login": "designer",
      "group": "APP_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "56",
      "login": "designer",
      "group": "DESIGNER"
    },
    {
      "date": "2000-01-01",
      "row_id": "61",
      "login": "designer",
      "group": "GRANT_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "73",
      "login": "designer",
      "group": "MD_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "68",
      "login": "designer",
      "group": "MODELER"
    },
    {
      "date": "2000-01-01",
      "row_id": "57",
      "login": "designer",
      "group": "OPERATOR"
    },
    {
      "date": "2000-01-01",
      "row_id": "71",
      "login": "designer",
      "group": "SOCIAL_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "64",
      "login": "designer",
      "group": "USER_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "66",
      "login": "designer",
      "group": "WEB_ADMIN"
    },
    {
      "date": "2000-01-01",
      "row_id": "75",
      "login": "public",
      "group": "MD_READER"
    },
    {
      "date": "2006-10-01",
      "row_id": "52",
      "login": "public",
      "group": "PUBLIC"
    }
  ]
}

Voici l’API mappée utilisée:

package com.simplicite.extobjects.Application;

import com.simplicite.util.tools.Parameters;

public class TestAPI extends com.simplicite.webapp.services.RESTMappedObjectsExternalObject {
	private static final long serialVersionUID = 1L;

	@Override
	public void init(Parameters params) {
		addObject("resp", "Responsability");
		addField("resp", "login", "rsp_login_id.usr_login");
		addField("resp", "group", "rsp_group_id.grp_name");
		addField("resp", "date", "rsp_start_dt");
	}
}

Vous pouvez tester sur cette instance https://testdaz51.dev.simplicite.io qui est toujours active (designer/Passw0rd)

Hello David,
On a refait les tests sur notre environnement, cela n’a pas l’ai de marcher


On n’a pas d’erreur dans les logs, mais le filtre ne marche absolument pas

On a fait le mapping de la façon suivante :

 	addObject("aftersales-item", "MlaAftersaleItem");
	addField("aftersales-item", "rowId", "row_id");
	addField("aftersales-item", "createdDt", "created_dt");
	addField("aftersales-item", "updatedDt", "updated_dt");
	addField("aftersales-item", "MLA_REFERENCE_NUMBER", "MLA_REFERENCE_NUMBER");
	addField("aftersales-item", "MLA_ENGINEERING_CATEGORY", "MLA_ENGINEERING_CATEGORY");

Bonjour @lbouzidi Laila, as-tu testé avec la syntaxe indiquée par David ? (i.e. updatedDt=2022-10-01;2022-10-10)

Hello Bruno,
Oui j’ai testé avec les deux syntaxes.