Utilizzo di modelli con connettori LoopBack

Interazioni tra i LoopBackRequest nodo e alcuni tipi di origini dati backend richiedono LoopBack® modelli da definire.

Alcuni connettori LoopBack richiedono che il modello dati con cui interagire sia definito tramite un modello JSON LoopBack . Quando il LoopBackRequest il nodo interagisce per la prima volta con un nodo denominato LoopBack object (che è specificato come proprietà del nodo o sovrascritto dinamicamente nell'ambiente locale), cerca a LoopBack File del modello JSON in una sottodirectory della directory che contiene il filedatasources.json file. Per informazioni sulla configurazione del modello, vedi Configurazione dell'origine dati e dei modelli per il tuo connettore LoopBack.

Un modello LoopBack è generalmente richiesto per le origini dati supportate da database relazionali, in cui vengono utilizzati gli oggetti tabella con una struttura dati rigida. Con questi tipi di origini dati, il modello può essere utilizzato per definire mappature delle proprietà tra le colonne del database e il file LoopBack proprietà utilizzate da LoopBackRequest nodo.

Nel seguente esempio, il nodo di integrazione denominato IIB10 utilizza un file datasources.json ubicato nella directory MQSI_WORKPATH\IIB10\connectors\loopback , dove MQSI_WORKPATH è definito dalla variabile di ambiente MQSI_WORKPATH. Il file datasources.json include la seguente sezione, denominata POSTGRESQL, per connettersi al database PostgreSQL :
"POSTGRESQL": {
    "host": "localhost",
    "port": 5432,
    "database": "loopback",
    "name": "postgreSQL",
    "connector": "postgresql"
  }

Il file product.json viene copiato nella directory MQSI_WORKPATH\IIB10\connectors\loopback\POSTGRESQL . Per il LoopBackRequest nodo per utilizzare il modello, theLoopBack object proprietà sul nodo (o il LocalEnvironment. Destination.Loopback.Request.object variabile, se utilizzata) deve corrispondere esattamente al nome del modello, escluso il file.json estensione del file. In genere, questi nomi sono gli stessi, ma possono essere diversi; ad esempio, se il nome dell'oggetto nel sistema connesso LoopBack contiene un carattere che non sarebbe valido in un nome file. Se i nomi sono diversi, viene emesso un messaggio BIP3880 .

In questo caso, la propriet ... LoopBack object viene configurata come mostrato nel seguente diagramma:
Questo diagramma mostra il LoopBack proprietà dell'oggetto nella scheda Base del LoopBackRequest nodo.
Il seguente esempio mostra come utilizzare un modello LoopBack per interagire con una tabella product definita in un database PostgreSQL :
CREATE TABLE public.product
(
  product_id serial NOT NULL,
  product_name character varying(20),
  sell_by date,
  number_in_stock integer,
  obsolete boolean,
  CONSTRAINT product_pk PRIMARY KEY (product_id)
)
Il connettore LoopBack PostgreSQL supporta il rilevamento, quindi gli strumenti di generazione del modello StrongLoop® e API Connect sono stati utilizzati per generare il seguente modello LoopBack per la tabella product . Questo modello è stato emesso nel file product.json :
{
  "name": "Product",
  "base": "PersistedModel",
  "idInjection": false,
  "options": {
    "validateUpsert": true
  },
  "postgresql": {
    "schema": "public",
    "table": "product"
  },
  "properties": {
    "numberInStock": {
      "type": "number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "number_in_stock",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      },
      "_selectable": true,
      "comments": "Items in stock"
    },
    "obsolete": {
      "type": "boolean",
      "required": false,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "obsolete",
        "dataType": "boolean",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "YES"
      },
      "_selectable": true,
      "comments": "Flag if stock is obsolete"
    },
    "productId": {
      "type": "number",
      "id": true,
      "required": true,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "product_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "NO"
      },
      "_selectable": false,
      "comments": "Unique product number"
    },
    "productName": {
      "type": "string",
      "required": true,
      "length": 20,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "product_name",
        "dataType": "character varying",
        "dataLength": 20,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "YES"
      },
      "_selectable": true,
      "comments": "Description of product"
    },
    "sellBy": {
      "type": "date",
      "required": false,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "sell_by",
        "dataType": "date",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "YES"
      },
      "_selectable": true,
      "comments": "Expiry date"
    }
  },
  "validations": [],
  "relations": {},
  "acls": [],
  "methods": {}
}

Per ulteriori informazioni sugli strumenti di creazione del modello StrongLoop e API Connect , vedi la documentazione sul sito WebStrongLoop.

Nella tabella PostgreSQL product , la colonna product_id è definita con un tipo di dati di serial, che risulta in valori per la colonna generati automaticamente quando una riga viene inserita nella tabella. Per riflettere questo, il modello LoopBack product.json è stato aggiornato per includere una proprietà generated per productId. ILrequired anche l'attributo è stato modificato infalse , che impedisce al modello di verificare che i dati nelle richieste inviate dal LoopBackRequest il nodo include aproductId quando viene creata una riga, perché questo valore verrà generato automaticamente. Il modello aggiornato è mostrato nel seguente esempio:
"productId": {
      "type": "number",
      "id": true,
      "required": false,
      "generated": true,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "product_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "NO"
      },
      "_selectable": false,
      "comments": "Unique product number"
    }
Il modello può essere utilizzato anche per impostare valori predefiniti per i valori dei dati; nel seguente esempio, il valore obsolete assume il valore predefinito false:
"obsolete": {
      "type": "boolean",
      "required": false,
      "default": false,
      "length": null,
      "precision": null,