Creare e pubblicare modelli di flusso di lavoro per App per la logica di Azure

Articolo
11/09/2024

Si applica: App per la logica di Azure (Standard)

App per la logica di Azure fornisce modelli di flusso di lavoro di integrazione predefiniti che è possibile usare per accelerare il processo di creazione di applicazioni di integrazione. Questi modelli seguono modelli di uso comune e consentono di semplificare lo sviluppo fornendo un punto di partenza o una linea di base con la logica di business e le configurazioni predefinite.

Non solo è possibile avviare lo sviluppo con i modelli di flusso di lavoro, è possibile creare modelli di flusso di lavoro personalizzati o condividerli con altri utenti. Il modello può includere elementi come schemi, mappe e assembly personalizzati. Per aggiungere il modello alla raccolta modelli nella portale di Azure, creare un pacchetto modello usando questa guida pratica. Al termine, visitare il repository dei modelli di flusso di lavoro in GitHub per App per la logica di Azure in cui è possibile creare una richiesta pull per il pacchetto modello e chiedere al team di App per la logica di Azure di esaminare il modello.

Limiti

I modelli di flusso di lavoro attualmente supportano solo app per la logica Standard e singoli flussi di lavoro.

Che cosa include un pacchetto modello?

La tabella seguente descrive i file obbligatori e facoltativi in un pacchetto modello:

File name	Richiesto	Descrizione
workflow.json	Sì	Un file JSON con la definizione del flusso di lavoro.
manifest.json	Sì	Un file JSON con informazioni sul flusso di lavoro e sui componenti correlati.
*<image-name>-dark.png*	Sì	Un file di immagine con il flusso di lavoro come screenshot di sola lettura in formato .png e funziona con il tema scuro di un browser.
*<image-name>-light.png*	Sì	Un file di immagine con il flusso di lavoro come screenshot di sola lettura in formato .png e funziona con il tema chiaro di un browser.
*<map-name>.json, .xml* o xslt	No	Tutti gli artefatti, ad esempio mappe e schemi che supportano il modello del flusso di lavoro.
*<assembly> personalizzato.dll*	No	Tutti gli assembly personalizzati che supportano il modello di flusso di lavoro.
readme.md	No	Un file Markdown con istruzioni, procedure o altre informazioni per il modello di flusso di lavoro.

È anche possibile includere qualsiasi altro file per gestire e supportare il modello, ad esempio file con dati di test o di esempio.

Creare una cartella del pacchetto modello

Prima di creare la cartella del pacchetto modello, acquisire familiarità con nomi e convenzioni di stile.
Per semplificare l'esplorazione, l'organizzazione e la manutenzione del repository dei modelli, usare la sintassi seguente per il nome della cartella e il minor numero di parole per evitare di superare il limite di caratteri per i percorsi di file:

<workflow-task-product-pattern-or-protocol><><, se disponibile>

Per esempi, vedere il repository dei modelli di flusso di lavoro per App per la logica di Azure in GitHub.
Per registrare correttamente la cartella del pacchetto modello, è necessario aggiungere il nome della cartella al file di manifest.json a livello radice del repository.

Creare un file workflow.json

Il file workflow.json contiene la definizione sottostante per un flusso di lavoro in formato JSON. Per creare il file workflow.json , è necessario copiare e salvare la definizione del flusso di lavoro come file denominato workflow.json.

Per ottenere la definizione del flusso di lavoro più semplice e migliore, creare il flusso di lavoro usando la finestra di progettazione. Assicurarsi di esaminare le procedure consigliate per il flusso di lavoro insieme ai nomi e alle convenzioni di stile. In alternativa, come punto di partenza, è possibile usare i modelli di flusso di lavoro predefiniti della raccolta modelli nella portale di Azure.

Durante la compilazione del flusso di lavoro, la finestra di progettazione include automaticamente riferimenti a eventuali connessioni predefinite, provider di servizi, connessioni API gestite o librerie nella definizione del flusso di lavoro sottostante.

Al termine, copiare la definizione del flusso di lavoro sottostante in un file di workflow.json vuoto.

Procedure consigliate per il flusso di lavoro

Usare le operazioni predefinite il più possibile. Ad esempio, il connettore Archiviazione BLOB di Azure include le versioni seguenti disponibili per i flussi di lavoro Standard:
- Versione predefinita del provider di servizi visualizzata nella raccolta connettori con l'etichetta In App . Questa versione è ospitata ed eseguita con il runtime di App per la logica di Azure a tenant singolo, offrendo prestazioni, velocità effettiva e altri vantaggi migliori.
- Una versione dell'API gestita da Microsoft, visualizzata nella raccolta connettori con l'etichetta Condivisa . Questa versione è ospitata ed eseguita in Azure multi-tenant usando risorse globali condivise.
Non usare proprietà hardcoded e i relativi valori nelle definizioni di trigger e azione.
Fornire più contesto sulle definizioni di trigger e azione aggiungendo commenti descrittivi e utili.

Copiare la definizione del flusso di lavoro sottostante

Nel portale di Azure, nel menu del flusso di lavoro, in Sviluppatore selezionare Codice.
Dalla finestra di visualizzazione codice copiare l'intera definizione del flusso di lavoro, ad esempio:
In un file vuoto denominato workflow.json salvare la definizione del flusso di lavoro.

Riferimenti ai parametri in workflow.json

Quando si fa riferimento ai parametri nel file workflow.json , è necessario riflettere i nomi dei parametri che usano il suffisso _#workflowname# nel modo seguente:

"name": "@parameters('<parameter-name>_#workflowname#')"

Ad esempio:

"name": "@parameters('sharepoint-folder-path_#workflowname#')"

Riferimenti alla connessione in workflow.json

Quando si fa riferimento alle connessioni nel file workflow.json , è necessario riflettere i nomi di connessione che usano il suffisso _#workflowname# nel modo seguente:

"referenceName": "<connector-ID>_#workflowname#",
"connectionName": "<connector-ID>_#workflowname#"

Ad esempio:

"referenceName": "azureaisearch_#workflowname#",
"connectionName": "azureaisearch_#workflowname#"

Per altre informazioni sull'ID connettore, vedere Trovare l'ID connettore.

Creare un'immagine del modello di flusso di lavoro

Nella portale di Azure ogni modello di flusso di lavoro include un riquadro di panoramica nella raccolta dei modelli di flusso di lavoro. Questo riquadro include un'immagine di anteprima di sola lettura per il flusso di lavoro creato dal modello e altre informazioni sul modello.

Per creare questa immagine di anteprima, seguire questa procedura:

Nella finestra di progettazione configurare il flusso di lavoro per la creazione di due screenshot.

È necessario creare una versione per il tema chiaro del browser e il tema scuro.
Creare gli screenshot del flusso di lavoro usando lo strumento di acquisizione dello schermo preferito. Non includere troppi spazi vuoti intorno al flusso di lavoro.
Salvare ogni immagine usando l'estensione .png nome file e qualsiasi nome desiderato, seguendo le convenzioni di stile e nomi.
Nel file manifest.json per il pacchetto modello di flusso di lavoro aggiungere gli stessi nomi di immagine alla images sezione senza l'estensione del nome file .png, ad esempio:
```
"images": {
    "dark": "workflow-dark",
    "light": "workflow-light"
}
```

Creare un file manifest.json

Il file manifest.json descrive la relazione tra un flusso di lavoro e i componenti correlati. Attualmente, è necessario creare manualmente questo file oppure riutilizzare il file manifest.json da un modello esistente esistente nel repository dei modelli di flusso di lavoro App per la logica di Azure in GitHub. Quando si crea il file di manifest.json , assicurarsi di esaminare i nomi e le convenzioni di stile.

Nella tabella seguente vengono descritti gli attributi nel file manifest.json :

Attribute name	Obbligatorio	Valore	Descrizione
`title`	Sì	<template-title>	Titolo visualizzato nella raccolta modelli, che viene aperto quando si aggiunge un flusso di lavoro da un modello nel portale di Azure.
`description`	Sì	<template-description>	Descrizione del modello, visualizzata nel riquadro di panoramica del modello nella raccolta modelli.
`prerequisites`	No	<prerequisiti di modello>	Eventuali prerequisiti da soddisfare per l'uso del modello. Viene visualizzato nel riquadro di panoramica del modello. È possibile collegarsi ad altri documenti di questa sezione.
`tags`	No	<template-tags-array>	Tag del modello da usare per la ricerca o il filtro dei modelli.
`skus`	Sì	`standard`, `consumption`	Tipo di flusso di lavoro dell'app per la logica supportato dal modello. Se non si è certi, usare `standard`.
`kinds`	No	`stateful`, `stateless`	Modalità flusso di lavoro, che determina se gli stati della cronologia di esecuzione e dell'operazione vengono archiviati. Per impostazione predefinita, tutti i flussi di lavoro sono disponibili sia in modalità con stato che senza stato. Se il flusso di lavoro viene eseguito solo in modalità con stato, usare questo attributo per rendere esplicito questo requisito.
`detailsDescription`	No	Vedi la descrizione.	Qualsiasi altra descrizione dettagliata per il modello.
`details`	No	Vedi la descrizione.	Informazioni sul modello da usare per filtrare la raccolta di modelli. - `By`: autore del modello, `Microsoft`ad esempio . - `Type`: `Workflow` - `Trigger`: tipo di trigger, ad esempio , `Recurrence``Event`o `Request`.
`artifacts`	Sì	<artifacts-array>	Tutti i file pertinenti nel pacchetto modello e includono gli attributi seguenti: - `type`: tipo di file, che determina il percorso appropriato per dove copiare il file, `workflow`ad esempio . - `file`: il nome e l'estensione del file, ad esempio, workflow.json.
`images`	Sì	Vedi la descrizione.	Nomi di file di immagine del flusso di lavoro per temi chiari e scuri del browser: - `light`: nome dell'immagine per il tema chiaro, ad esempio luce del flusso di lavoro - `dark`: nome dell'immagine per il tema scuro, ad esempio, scuro del flusso di lavoro.
`parameters`	Sì, ma può essere vuoto se non esiste	<workflow-parameters-array>	Parametri per le azioni nel modello del flusso di lavoro. Per ogni parametro, è necessario specificare le proprietà seguenti: - `name`: il nome del parametro deve avere il suffisso , `_#workflowname#`. Usare solo caratteri alfanumerici, trattini o caratteri di sottolineatura e seguire questo formato: `<parameter-name>_#workflowname#` - `displayName`: nome visualizzato descrittivo del parametro. Vedere Nomi e convenzioni di stile. - `type`: tipo di dati del parametro, ad esempio `String` o `Int`. - `default`: valore predefinito del parametro, se presente. In caso contrario, lasciare questo valore come stringa vuota. - `description` Dettagli del parametro e altre informazioni importanti o utili. - `required`: `true` o `false`
`connections`	Sì, ma può essere vuoto se non esiste alcuno.	<connections-array>	Connessioni da creare usando il modello di flusso di lavoro. Ogni connessione ha le proprietà seguenti: -`connectorId`: l'ID connettore deve avere il suffisso , `_#workflowname#`. Usare solo caratteri alfanumerici, trattini o caratteri di sottolineatura e seguire questo formato: `<connector-ID>_#workflowname#` Per trovare l'ID connettore, vedere Trovare l'ID connettore. - `kind`: il tipo di host di runtime del connettore, che è `inapp` per le operazioni predefinite e i connettori del provider di servizi o `shared` per i connettori gestiti ospitati in Azure. Nella raccolta connettori, le operazioni predefinite e i connettori del provider di servizi vengono etichettati come In App, mentre i connettori gestiti vengono etichettati come Condivisi.
`featuredConnections`	No	<featured-connections-array>	Per impostazione predefinita, la raccolta modelli mostra le icone per le operazioni predefinite e i connettori in App per la logica di Azure usati da ogni modello. Per includere icone per qualsiasi altra operazione, è possibile usare l'attributo `featuredConnections` . Ogni operazione deve avere gli attributi seguenti: - `kind`: tipo di operazione - `type`: tipo di operazione Per trovare questi valori, vedere la sezione Trovare il tipo di operazione e il tipo per la sezione in primo pianoConnections.

Trovare l'ID connettore

Per trovare l'ID connettore da usare per una connessione nel file manifest.json o un riferimento alla connessione nel file workflow.json , seguire questa procedura:

Nel portale di Azure aprire la risorsa app per la logica.
Nel menu dell'app per la logica, in Flussi di lavoro selezionare Connessioni.
Selezionare la scheda Visualizzazione JSON.
In base al tipo di connessione, seguire questa procedura:
- Per una connessione API gestita "condivisa" ospitata ed eseguita in Azure:
  1. Trovare la sezione managedApiConnections.
  2. Nell'attributo connection copiare e salvare il id valore, ma sostituire tutti i dati personali o sensibili, ad esempio l'ID sottoscrizione, il nome del gruppo di risorse e così via, con #<item>#:
    
    /subscriptions/#subscription#/providers/Microsoft.Web/locations/#location#/managedApis/<connection-name>
    
    Ad esempio, il testo seguente mostra l'ID connettore per il connettore SharePoint:
    
    /subscriptions/#subscription#/providers/Microsoft.Web/locations/#location#/managedApis/sharepointonline
- Per una connessione del provider di servizi ospitata nel runtime di App per la logica di Azure a tenant singolo:
  1. Trovare la sezione serviceProviderConnections.
  2. Per ogni connessione, trovare l'attributo id nell'attributo serviceProvider .
  3. Copiare e salvare il valore seguente:
    
    /serviceProviders/<connection-name>
    
    Ad esempio, il testo seguente mostra l'ID connettore per il connettore Ricerca intelligenza artificiale di Azure:
    
    /serviceProviders/azureaisearch.

Trovare le proprietà 'kind' e 'type' dell'operazione per le connessioni in primo piano

Nel file manifest.json la featuredConnections sezione può includere icone per qualsiasi altra operazione da includere nella raccolta di modelli nella portale di Azure. Per questa sezione, ovvero una matrice, è necessario specificare gli kind attributi e type per ogni operazione.

Per ottenere questi valori di attributo, seguire questa procedura nel portale di Azure con il flusso di lavoro aperto:

Nel menu del flusso di lavoro, in Sviluppatore, selezionare Codice.
Nella sezione della actions finestra della visualizzazione codice individuare l'operazione desiderata e quindi trovare i kind valori e type .

Aggiungere un pacchetto modello al repository GitHub

Per pubblicare il modello nella raccolta di modelli nella portale di Azure, configurare GitHub e creare una richiesta pull con il pacchetto modello per la convalida e la revisione:

Creare un account GitHub, se non ne è disponibile uno.

Per altre informazioni, vedere Introduzione all'account GitHub.
Passare al repository dei modelli di flusso di lavoro denominato LogicAppsTemplates per App per la logica di Azure in GitHub.
Creare un fork personalizzato, ovvero una copia remota del repository LogicAppsTemplates in GitHub.

Per altre informazioni, vedere Creazione di fork di un repository.
Per lavorare in locale, clonare il fork nel computer.
1. Seguire questa procedura per scaricare, installare e configurare Git.
2. Passare al fork, con l'URL seguente:
  
  https://github.com/<your-username>/LogicAppsTemplates
3. Nel computer locale creare una cartella denominata GitHub, se non è già disponibile. Non clonare in una cartella sincronizzazione OneDrive ed.
4. Seguire questa procedura per clonare il fork, non il repository di produzione.
5. Nel repository locale seguire questa procedura per creare un ramo di lavoro.
6. Dopo aver estratto il ramo di lavoro, passare al livello radice nel repository locale e creare la cartella del pacchetto modello.
7. Aggiungere i file modello alla cartella del pacchetto modello e aggiornare il file di manifest.json a livello radice con il nome della cartella.
8. Quando si è pronti per eseguire il commit delle modifiche nel repository locale, ad esempio il salvataggio di uno snapshot, eseguire i comandi seguenti usando lo strumento da riga di comando Git o altri strumenti:
  
  git add .
  
  git commit -m "<commit-short-description>"
9. Per caricare lo snapshot nel fork remoto, eseguire il comando seguente:
  
  git push origin <your-working-branch>
In GitHub creare una richiesta pull per confrontare <your-working-branch> con il ramo main nel repository LogicAppsTemplates.
1. Passare alla pagina Richieste pull del repository e selezionare Nuova richiesta pull.
2. In Confronta modifiche selezionare Confronta tra fork.
3. Assicurarsi che la richiesta pull abbia le impostazioni seguenti e quindi selezionare Crea richiesta pull.
  
  Repository di base Base Repository head Confronta
  
  Azure/LogicAppsTemplates main <user-name>/LogicAppsTemplates <your-working-branch>
4. Immettere un titolo e una descrizione per la richiesta pull. Per completare, selezionare Crea richiesta pull.
5. Attendere che il team App per la logica di Azure riveda la richiesta pull.
Per altre informazioni, vedere Creazione di una richiesta pull da un fork.

Repository di base	Base	Repository head	Confronta
Azure/LogicAppsTemplates	main	*<user-name>/LogicAppsTemplates*	*<your-working-branch>*

Nomi e convenzioni di stile

Area	Convenzione
Dati sensibili	Non includere o caricare dati personali e sensibili nei file modello, screenshot, descrizioni o dati di test. Ad esempio, questi dati includono ID sottoscrizione, nomi utente, password e così via.
Nomi delle cartelle	Per semplificare la leggibilità, usare caratteri minuscoli e trattini quando possibile. Vedere La guida per le maiuscole e minuscole - Guida di stile Microsoft.
Nomi dei file di immagine	Usare il .png come estensione del nome file, caratteri minuscoli e trattini, ad esempio workflow-light.png.
Nomi di prodotto, servizio, tecnologia e marchio	Seguire l'ortografia ufficiale e la maiuscola. Ad esempio: - Quando si fa riferimento al nome o alla piattaforma del servizio, usare "App per la logica di Azure", non "App per la logica". - Quando si fa riferimento alla risorsa o all'istanza, usare "app per la logica" o "app per la logica", non "App per la logica" o "App per la logica". - Quando si fa riferimento alla sequenza di trigger e azioni, usare "flusso di lavoro dell'app per la logica" o "flusso di lavoro".
Abbreviazioni e acronimi	Usare il nome espanso per prodotto, servizio, tecnologia, nomi di marchi e termini tecnici non comuni, non abbreviazioni o acronimi. Gli acronimi comuni, ad esempio "HTTP" e "URL", sono accettabili. Ad esempio, usare "Visual Studio Code", non "VS Code". Vedere Acronimi - Guida di stile Microsoft.
Altro testo	- Usare la distinzione tra maiuscole e minuscole per titoli, intestazioni e contenuto del corpo, ovvero si maiuscola solo la prima lettera, a meno che non si disponga di prodotto, servizio, tecnologia o nome del marchio. - Non maiuscolare nomi e articoli ordinari, ad esempio "a", "an", "and", "or", "the" e così via.
Voce	- Usare la voce di seconda persona (l'utente e il proprio) anziché la terza persona (utenti, sviluppatori, clienti) a meno che non sia necessario fare riferimento a ruoli specifici. Vedere Person – Microsoft Style Guide (Persona - Guida di stile Microsoft). - Usa un tono attivo, diretto, ma amichevole quando possibile. La voce attiva è incentrata sull'oggetto e sul verbo nel testo, mentre la voce passiva è incentrata sull'oggetto nel testo.
Vocabolario	- Usare parole semplici, comuni, quotidiane, ad esempio "usare", anziché "utilizzare" o "sfruttare". - Non usare parole, frasi, gergo, colloquialismi, idiomi o gergo che non traducono bene tra le lingue. - Usare "please" solo per scenari specifici. Vedere : Guida di stile Microsoft. - Usare "ad esempio" o "ad esempio", non "ad esempio" o "ad esempio". - Non usare termini direzionali come "here", "above", "below", "right" e "left", che non sono accessibili.
Punteggiatura	- Per una serie di elementi, includere l'ultima virgola prima della congiunzione, ad esempio "e". Ad esempio, "mele, arance e banane". Vedere Virgola - Guida di stile Microsoft. - Terminare le frasi complete con punteggiatura appropriata. Non usare punti esclamativi. Vedere Punctuation – Microsoft Style Guide (Guida di stile Microsoft).
Formattazione in corso	- Per il codice, seguire la convenzione di stile per il linguaggio del codice. - Non usare collegamenti hardcoded, che interrompono se gli URL cambiano. Nella richiesta pull chiedere invece un collegamento di reindirizzamento da usare. - Per i collegamenti, usare il formato seguente: "`For more information, see [descriptive-link-text](URL)]`.". - Usare testo descrittivo del collegamento, non testo generico o vago, ad esempio "`See [here](URL)`". - Usare i numeri solo per i passaggi di una procedura, non per gli elenchi che non dispongono di un ordine specifico. Vedere Elenchi - Guida di stile Microsoft. - Usare solo uno spazio dopo la punteggiatura, a meno che non venga applicato un rientro al codice.

Per altre indicazioni, vedere la Guida di stile Microsoft e i suggerimenti per la scrittura globale.

Creare un flusso di lavoro dell'app per la logica Standard da un modello predefinito

Condividi tramite

Creare e pubblicare modelli di flusso di lavoro per App per la logica di Azure

Limiti

Che cosa include un pacchetto modello?

Creare una cartella del pacchetto modello

Creare un file workflow.json

Procedure consigliate per il flusso di lavoro

Copiare la definizione del flusso di lavoro sottostante

Riferimenti ai parametri in workflow.json

Riferimenti alla connessione in workflow.json

Creare un'immagine del modello di flusso di lavoro

Creare un file manifest.json

Trovare l'ID connettore

Trovare le proprietà 'kind' e 'type' dell'operazione per le connessioni in primo piano

Aggiungere un pacchetto modello al repository GitHub

Nomi e convenzioni di stile

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Creare e pubblicare modelli di flusso di lavoro per App per la logica di Azure

Limiti

Che cosa include un pacchetto modello?

Creare una cartella del pacchetto modello

Creare un file workflow.json

Procedure consigliate per il flusso di lavoro

Copiare la definizione del flusso di lavoro sottostante

Riferimenti ai parametri in workflow.json

Riferimenti alla connessione in workflow.json

Creare un'immagine del modello di flusso di lavoro

Creare un file manifest.json

Trovare l'ID connettore

Trovare le proprietà 'kind' e 'type' dell'operazione per le connessioni in primo piano

Aggiungere un pacchetto modello al repository GitHub

Nomi e convenzioni di stile

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive