Limites connues - Automate_Evolve - Automate_Studio_Manager - 20.3

Seuls ISO et Ticks (cycles) (fomat de date JSON Microsoft) son pris en charge. Exemple : Ticks : / Date(1492041600000)/, ISO: “2021-04-13T14:48:00.000Z”. De plus, seules les valeurs de date UTC sont lues et définies dans les champs du formulaire. Si la valeur de la date a un décalage défini, celui-ci sera ajusté pour obtenir la valeur de la date UTC. Pour les nombres simples, format en sans séparateur de milliers, et point comme séparateur décimal, par exemple 1345612.45

Prise en charge de l'API REST pour la Liste déroulante, contrôle Query, contrôle Lookup, la requête de participant, les règles pour interroger la connexion des données :

• Étant donné que les contrôles, Liste déroulante, contrôle Query, contrôle Lookup, requête de participant et les règles pour interroger la connexion des données ne prennent en charge que les données tabulaires, l'utilisation de ces fonctionnalités avec l'API REST ne sera prise en charge que si les données peuvent être transformées au format tableau. Cela s'applique également aux données provenant d'une structure imbriquée (par exemple, une table dans une autre table ou une bibliothèque dans une autre bibliothèque, etc. Exemple :

  [{  "id": "int", "name": "string", "productType": "string", "sizes": ["string"] "otherDetails": {   "colors": ["string"],   "versions": ["int"] }, "Plant":[{   "PlantNo":"string",   "PlantName":"string" }]}]

  Dans cette charge utile, seules les propriétés "id", "name" et "productType" peuvent être transformées en structure tabulaire et peuvent également être utilisées avec les contrôles mentionnés ci-dessus.

  Les tableaux imbriqués (tableau de type champ unique ou "champs multiples" / type complexe) ne sont pas pris en charge par les contrôles ci-dessus.

• Comportement des filtres du contrôle Lookup

  1. Contrôle de recherche : les propriétés Filtre de recherche (Rechercher dans une colonne, Opération de recherche une opération, champ de clé de recherche, par exemple) ne sont pas prises en charge.

  2. Contrôle Lookup : Clause Where : les champs de la table répétitive seront remplacés par des valeurs séparées par des virgules et le filtre sera exécuté pour cette exécution de l'API. Ainsi la requête ou l'url aura toutes les valeurs dans la colonne avec des virgules séparées. L'exécution de la commande de consultation pour les seules données de la ligne en cours n'est pas prise en charge. Par conséquent, le contrôle de recherche ne sera pas en mesure d'obtenir des données pour la ligne actuelle (c'est-à-dire si l'URL a un champ de la table de la ligne actuelle).

• Seule la connexion de l'API REST avec une opération Get est prise en charge par ces contrôles.

Les champs suivants du contrôle de recherche ne sont pas pertinents pour la connexion de données de l'API Rest :

• Table

• Colonne de recherche

• Opération de recherche

• Champ clé de recherche

• Taille minimale de clé de recherche

• Fin générique auto

• Début générique auto

• Clause Where --> champ de formulaire/champ de solution dans le générateur d'URL (non pris en charge), comme pour les autres connexions de données.

• Requête brute (Non pertinente en cas de contrôle Query)

Prise en charge de la modification d'URL avec une liste déroulante

• La connexion asynchrone aux données de l'API REST (c'est-à-dire que la case « Récupérer automatiquement les données à l'ouverture du formulaire » n'est pas cochée) définie avec le champ de formulaire dans l'URL de l'API ne fonctionne pas lorsqu'elle est utilisée dans la liste déroulante. Sinon, la partie url devrait être définie dans le filtre de la liste déroulante. Cette limitation n'existe que lorsque l'URL de la connexion de données comporte des champs de formulaire. Tous les champs non répétitifs sont pris en charge pour être définis dans l'URL de l'API. De même, lorsque la liste déroulante est ajoutée au tableau répétitif, tous les champs de formulaire non répétitifs ainsi que les champs de la ligne actuelle sont pris en charge.

• Synchronisation de la connexion de données REST API (c'est-à-dire que la case « Récupérer automatiquement les données à l'ouverture du formulaire » est cochée) : connexion de données API REST définie avec des champs de formulaire dans l'URL de l'API et délimitée par une liste déroulante. Seuls les champs de formulaire non répétitifs sont pris en charge (c'est-à-dire les champs ne figurant pas dans une table extensible ou une section répétitive). De même, le comportement de synchronisation de la connexion de données sera exécuté au chargement du formulaire, de sorte que la "valeur du formulaire enregistrée sur le serveur" ou la "valeur par défaut du nouveau formulaire" sera utilisée pour remplacer l'URL de l'API.

• L'application prend en compte l'URL complète de l'API REST qui est enregistrée dans la connexion de données de l'API REST de la solution si aucune donnée n'est fournie dans le filtre de contrôle.

API Payload (Entrée/Sortie/Erreur) : tous les éléments répétitifs

Le contenu de l'API qui contiennent toutes les propriétés de type répétitif /tableau dans un tableau / répétitif (par exemple, un tableau répétitif ne contient que des tables extensibles, sans propriété simple) n'est pas pris en charge. Vous trouverez un exemple ci-dessous :

[{   "sizes": ["string"],   "codes": ["int"],   "listedDates": ["date"],   "results": [{     "countryCode": "string",     "city": "string",     "address": "string"   }]}]

Contenu d'entrée/ « Envoyer les données » au serveur d'API (par exemple, post, put, patch etc.)

Les API qui acceptent un tableau en entrée plusieurs enregistrements (c'est-à-dire le contenu d'entrée qui peut accepter un tableau ou plusieurs données) sont également prises en charge. Par exemple :

[{   "id": "int",   "name": "string",   "productType":    "string","price": "decimal" }]

{ "products":[{ "id": "int", "name": "string", "productType": "string", "price": "decimal" }]}

[{   "id": "int",   "name": "string",   "productType":    "string","price": "decimal",   "to_Description": {     "results": [{        "language": "string",       "description": "string"   }]}}]

L'exemple ci-dessous d'un seul enregistrement mais avec des données répétitives ou de type tableau plus tard dans le schéma est également pris en charge.

{ "id": "int",   "name": "string",   "to_Description": {  "results": [{     "language": "string",     "description": "string"   }]},   "to_Plant":{ "results": [{       "PlantName":"string",       "to_location":{ "results":[{           "locationName":"string",           "field2":"string" }]}}]}}

Les noms de champs contenant les caractères suivants ne sont pas pris en charge

• caractère point (« . ») Les noms de champ contenant un point, tels que « field3.test », ne sont pas pris en charge.

• Les parenthèses ( ou ), comme dans « Produit(description) » ou « Produit(description) », ne sont pas prises en charge.

Plugin Service Web ou Adaptateur de connexion de données : exécution

• Créer les champs de formulaire : Génération d'une section répétée n'est pas cochée : la connexion de données de l'API REST lorsque l'URL de l'API inclut des champs de formulaire d'un Schéma répétitif (champs de formulaire d'un tableau), cela ne fonctionnera pas ou n'est pas pris en charge lors de son exécution avec un plugin Contrôle de service Web ou Adaptateur de connexion de données.

• Créer les champs de formulaire : Génération d'une section répétée n'est pas cochée :

  1. Seuls les champs de ligne en cours (c'est-à-dire la table extensible mappée à cette connexion de données, qui a le champ allow_run) sont pris en charge dans l'URL de l'API. Toute autre valeur n'est pas remplacée.

  2. L'en-tête de requête/réponse de la connexion de données de l'API REST doit être mappé avec le champ de formulaire du tableau répétitif de la ligne actuelle. Pour tout autre champ de formulaire (non répétitif) ou pour les champs qui ne font pas partie de la ligne actuelle dans le tableau répétitif, cela ne fonctionnera pas.

API Payload et mappage des champs (génération de champs de formulaire)

• Il n'est pas recommandé de mapper le même nom de groupe pour différentes connexions de données API. L'utilisateur peut choisir de mapper les champs de formulaire existants à différentes connexions d'API REST. Par exemple, le cas d'utilisation ci-dessous, qui consiste à ajouter deux API REST et à créer des champs de formulaire dans le même groupe de champs de formulaire, ne fonctionnera pas :

  Créer la première connexion d'API Rest (GET) ayant le schéma suivant (c'est-à-dire un enregistrement de données unique)

  {     "f1": "string",      "grp1": {       "grp2": [         {"f2": "int"}]} }

  Créer la deuxième connexion d'API Rest (GET) ayant un schéma similaire (c'est-à-dire plusieurs enregistrements du 1er schéma d'API Rest ci-dessus)

  [{     "f1": "string",      "grp1": {       "grp2": [         {"f2": "int"}]} }]

API Payload et mappage des champs (génération de champs de formulaire)

Composer- La connexion des données API Rest n'est pas prise en charge dans Plugin → Fonction → Connexion des données

Seule l'imbrication à deux niveaux est prise en charge dans les API REST, comme dans les tables extensives.

Seuls les en-têtes de réponse sont pris en charge dans les API REST. L'en-tête Content-Type n'est pas pris en charge, car il s'agit d'un en-tête de contenu de réponse.