Connettersi ad App per la logica di Azure da BizTalk Server
Per scambiare messaggi tra BizTalk Server e un flusso di lavoro dell'app per la logica in Azure, è possibile usare l'adapter in BizTalk Server per App per la logica di Azure. Questa guida illustra come ricevere un messaggio in BizTalk Server da un flusso di lavoro dell'app per la logica. Il flusso di lavoro può inviare messaggi a BizTalk Server. Il destinatario usa applicazioni Internet Information Services (IIS) per gestire la comunicazione con un servizio di Azure.
Se BizTalk Server è locale e aggiunto al dominio, è necessario installare il gateway dati locale in BizTalk Server e creare una risorsa gateway dati locale in Azure. Tuttavia, se BizTalk Server è installato in una macchina virtuale di Azure, è possibile scegliere se esporre o meno la macchina virtuale come endpoint HTTP, con un URL che è possibile chiamare.
Se si sceglie l'opzione endpoint HTTP, non è necessario usare il gateway. Si crea invece un flusso di lavoro dell'app per la logica, si aggiunge l'azione connettore BizTalkServer desiderata e si specifica l'URL dell'endpoint HTTP come richiesto dalle informazioni di connessione dell'azione. Tuttavia, se si sceglie l'opzione locale, è necessario configurare e usare il gateway dati, descritto più avanti in questa guida.
Questa guida illustra anche come inviare messaggi da BizTalk Server a un flusso di lavoro dell'app per la logica. In alternativa, il flusso di lavoro dell'app per la logica può ricevere messaggi da BizTalk Server.
Questa guida illustra come creare un percorso di ricezione e una porta di trasmissione usando l'adapter di App per la logica di Azure. È possibile usare questa scheda con un bizTalk Server locale o una macchina virtuale di Azure che esegue BizTalk Server.
Prerequisiti
Un account e una sottoscrizione di Azure in modo da poter accedere al portale di Azure e creare una risorsa e un flusso di lavoro dell'app per la logica. Se non si ha una sottoscrizione, iscriversi per ottenere un account Azure gratuito.
Requisiti di BizTalk Server in base al percorso in cui è installato il server:
Computer locale con BizTalk Server: installare e configurare il gateway dati locale per App per la logica di Azure. Nel portale di Azure creare quindi la risorsa gateway dati da usare con il connettore BizTalk Server nel flusso di lavoro dell'app per la logica.
Macchina virtuale di Azure con BizTalk Server:
Se la macchina virtuale non è esposta come endpoint HTTP, installare e configurare il gateway dati locale per App per la logica di Azure. Nel portale di Azure creare quindi la risorsa gateway dati da usare con il connettore BizTalk Server nel flusso di lavoro dell'app per la logica.
Se la macchina virtuale viene esposta come endpoint HTTP, non è necessario usare l'installazione del gateway dati né creare la risorsa gateway dati.
Familiarità con App per la logica di Azure. Se non si ha familiarità con le app per la logica, vedere Che cos'è App per la logica di Azure? e creare un flusso di lavoro di app per la logica a consumo di esempio in App per la logica di Azure multi-tenant.
Facoltativamente, supponendo che il flusso di lavoro inizi con un trigger in grado di ricevere richieste HTTP, ad esempio un trigger di richiesta, è possibile inviare un messaggio di test che attiva il flusso di lavoro dell'app per la logica. Per inviare questo messaggio, usare uno strumento che può inviare richieste HTTP all'URL dell'endpoint generato per il trigger nel flusso di lavoro. L'elenco seguente include alcuni strumenti di esempio:
- visual Studio Code con un'estensione da Visual Studio Marketplace
- powerShell Invoke-RestMethod
- Microsoft Edge - Strumento console di rete
- Bruno
- Curl
Cautela
Per gli scenari in cui sono presenti dati sensibili, ad esempio credenziali, segreti, token di accesso, chiavi API e altre informazioni simili, assicurarsi di usare uno strumento che protegge i dati con le funzionalità di sicurezza necessarie, funziona offline o in locale, non sincronizza i dati nel cloud e non richiede l'accesso a un account online. In questo modo, si riduce il rischio di esporre i dati sensibili al pubblico.
Installare l'adapter di App per la logica di Azure
BizTalk Server 2020 e versioni successive
A partire da BizTalk Server 2020, l'adapter app per la logica di Azure è incluso nell'installazione di BizTalk Server.
BizTalk Server 2016
In BizTalk Server scaricare e installare l'adapter app per la logica di Azure:
Passare a adapter Microsoft BizTalk Server per app per la logicae selezionare Scaricare.
Per installare, aprire il file
LogicAppAdapter.iso ed eseguire il file Adapter.msiLogicApp. Accettare il contratto di licenza e selezionare Installa.
Al termine dell'installazione, riavviare BizTalkServerApplication e istanze host bizTalkServerIsolatedHost.
Al termine dell'installazione, sono disponibili gli stati seguenti:
L'adapter app per la logica di Azure viene aggiunto ad Amministrazione BizTalk.
Il gestore di trasmissione viene creato e usa il BizTalkServerApplication'istanza host.
Il gestore di ricezione viene creato come servizio Windows Communication Foundation e usa l'istanza host BizTalkServerIsolatedHost.
La cartella dell'adapter LogicApp
viene creata all'interno della directory di installazione di BizTalk e include due servizi: Management eReceiveService .Management: usato dal connettore BizTalk in un flusso di lavoro dell'app per la logica per connettersi a BizTalk Server usando il gateway dati. Questo servizio di gestione consente a BizTalk Server di ricevere messaggi da un flusso di lavoro dell'app per la logica usando il gateway dati. Questo servizio viene usato solo sul lato di ricezione di BizTalk, non sul lato di invio.
ReceiveService: usato dal connettore BizTalk in un flusso di lavoro dell'app per la logica con il percorso di ricezione. Questo servizio è responsabile dell'invio di messaggi dal flusso di lavoro dell'app per la logica. Questo servizio viene usato solo sul lato di ricezione di BizTalk, non sul lato di invio.
Ricevere messaggi da un flusso di lavoro
Questa sezione elenca i passaggi aggiuntivi necessari per BizTalk Server per ricevere messaggi da un flusso di lavoro dell'app per la logica. Poiché il portale di Azure può cambiare, alcuni passaggi potrebbero non corrispondere esattamente a quelli elencati.
Solo BizTalk Server 2016: Adattatore NullAdapter e App per la logica di Azure
Se si installa l'adapter di App per la logica di Azure e NullAdapter, è possibile che venga visualizzato l'errore seguente:
Esiste già un'altra scheda con lo stesso valore OutboundEngineCLSID
Il GUID della classe Adapter è lo stesso per l'adapter app per la logica di Azure e NullAdapter. Se sono necessari entrambi gli adattatori, seguire questa procedura:
Scaricare il codice sorgente NullAdapter in GitHub.
Nella classe NullSendAdapter.cs aggiornare il GUID.
Nel file NullAdapter.reg aggiornare il valore OutboundEngineCLSID.
Compilare e distribuire NullAdapter.
Passaggio 1: Creare le applicazioni IIS
Le applicazioni IIS usano i di gestione
Mancia
Se si crea un nuovo pool di applicazioni, assicurarsi di mantenere la versione clr .NET predefinita e la pipeline gestita. Tenere presente che scegliere un'identità (Impostazioni avanzate) con appartenenza agli stessi gruppi BizTalk dell'account del servizio BizTalk.
Creare l'applicazione IIS di gestione
Il connettore BizTalkServer
BizTalk Server 2020 e versioni successive
Configurare le API REST usando la Configurazione guidata BizTalk.
Per altre informazioni, vedere la Guida alla configurazione di .
Per altre informazioni sulle API REST, vedere informazioni di riferimento sull'API REST bizTalk .
In un Web browser passare a
http://localhost/BizTalkManagementService/Schemas
.In base al Web browser, viene visualizzato l'elenco degli schemi oppure viene visualizzato un prompt per aprire e salvare un file schemas.json. In caso contrario, controllare la configurazione dell'API REST.
BizTalk Server 2016
Aprire Gestione Internet Information Services (IIS).
Dal menu di scelta rapida sito Web predefinito
selezionare Aggiungi applicazione .In questa nuova applicazione:
Immettere Alias (nome) per l'applicazione, ad esempio IISLogicApp.
Selezionare il pool di applicazioni.
Impostare il percorso fisico su
C:\Program Files (x86)\Microsoft BizTalk Server 2016\LogicApp Adapter\Management
.Testare le impostazioni per verificare che l'identità del pool di applicazioni superi i test di autenticazione
e autorizzazione.
Selezionare OK per salvare le modifiche.
In un Web browser passare a
http://localhost/YourApplicationAlias/schemas?api-version=2016-10-26
, ad esempio:http://localhost/IISLogicApp/Schemas?api-version=2016-10-26
.In base al Web browser, viene visualizzato l'elenco degli schemi oppure viene visualizzato un prompt per aprire e salvare un file schemas.json. Se non si verifica alcun problema, l'identità di AppPool potrebbe non appartenere ai gruppi BizTalk.
Creare l'applicazione IIS BizTalk ReceiveService
Il connettore BizTalkServer nel flusso di lavoro dell'app per la logica usa l'URL per questa applicazione IIS per il percorso di ricezione specificato.
Aprire Gestione Internet Information Services (IIS).
Aprire il menu di scelta rapida sito Web predefinito
e selezionare Aggiungi applicazione .In questa nuova applicazione seguire questa procedura:
Immettere Alias (nome) per l'applicazione, ad esempio ReceiveWCFService.
Selezionare lo stesso pool di applicazioni dell'applicazione IIS precedente.
Impostare il percorso fisico su quanto segue, in base alla versione:
- BizTalk Server 2020:
C:\Program Files (x86)\Microsoft BizTalk Server\LogicApp Adapter\ReceiveService
- BizTalk Server 2016:
C:\Program Files (x86)\Microsoft BizTalk Server 2016\LogicApp Adapter\ReceiveService
- BizTalk Server 2020:
Testare le impostazioni per verificare che l'identità del pool di applicazioni superi i test di autenticazione
e autorizzazione.
Selezionare OK per salvare le modifiche.
Passaggio 2: Creare un flusso di lavoro dell'app per la logica
Nel portale di Azure creare una nuova risorsa dell'app per la logica e un flusso di lavoro vuoto.
In base al flusso di lavoro creato,
seguire questi passaggi generici per aggiungere il trigger richiesta al flusso di lavoro.denominato Quando viene ricevuta una richiesta HTTP Seguire questi passaggi generici per aggiungere l'azione di bizTalkServer JSON al flusso di lavoro.denominata Preparare il messaggio da Nel riquadro di connessione dell'azione specificare le informazioni seguenti:
Proprietà Descrizione Connettersi tramite gateway dati locale Selezionare se si usa il gateway dati locale. Il gateway è necessario solo negli scenari seguenti:
- Si usa un'istanza locale di BizTalk Server.
- Si usa bizTalk Server in una macchina virtuale di Azure, ma la macchina virtuale non viene esposta come endpoint HTTP.nome connessione Immettere un nome descrittivo per la connessione. url di BizTalk Server Immettere il nome di dominio completo (FQDN) di Gestione BizTalk nell'URL dell'applicazione IIS. Ad esempio, immettere http://BizTalkServerName.corp.contoso.com/IISLogicApp/
.tipo di autenticazione Selezionare Windows. nome utente Immettere l'identità del pool di applicazioni IIS. password Immettere la password del pool di applicazioni IIS. gateway - sottoscrizione: selezionare la sottoscrizione di Azure associata alla risorsa gateway creata nel portale di Azure.
- Gateway: selezionare la risorsa gateway creata nel portale di Azure.Selezionare Crea nuovo.
Dopo aver visualizzato il riquadro informazioni sull'azione, specificare i dettagli necessari, ad esempio:
Proprietà Descrizione corpo Selezionare l'output del corpo HTTP. schema Selezionare lo schema da usare. Nota
Questo passaggio presuppone che si abbia familiarità con gli schemi in BizTalk e che si conosca lo schema desiderato. Se non si è certi, distribuire l'esempio HelloWorld SDK, aggiornarne gli artefatti per usare l'adapter di App per la logica di Azure e usarne lo schema e il messaggio di esempio.
Seguire questi passaggi generici per aggiungere l'azione BizTalkServer denominata Invia messaggio al flusso di lavoro.
Proprietà Descrizione di ricezione Nell'elenco selezionare l'URL oppure immettere il nome di dominio completo (FQDN) per l'URL dell'applicazione IIS ReceiveService. Ad esempio, immettere http://BizTalkServerName.corp.contoso.com/ReceiveWCFService/Service1.svc
.
Quando si crea il percorso di ricezione, immettere anche questo URL esatto nella scheda generalecome indirizzo pubbliconelle proprietà di trasporto della posizione di ricezione. corpo Selezionare l'output del corpo dall'azione di BizTalk Server precedente. Salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione selezionare Salva.
Questo passaggio crea automaticamente un URL dell'endpoint visualizzato nel trigger richiesta
. È possibile inviare richieste HTTP a questo URL, che trigger o causare l'avvio dell'esecuzione del flusso di lavoro. Copiare e salvare l'URL dell'endpoint. Queste informazioni sono necessarie per Passaggio 4: Inviare un messaggio.
Passaggio 3: Creare una porta di ricezione e un percorso di ricezione
Questa sezione descrive come creare elementi personalizzati.
Mancia
Anziché creare porte di ricezione personalizzate e località di ricezione, è possibile distribuire l'esempio HelloWorld SDK e quindi aggiornare gli artefatti per usare l'adapter di App per la logica di Azure.
In Amministrazione bizTalk Server espandere quanto segue:
applicazioni bizTalk Group Espandere l'applicazione da usare per l'esecuzione del percorso di ricezione. Ad esempio, espandere 'applicazione BizTalk - Ricevere.
Dal menu di scelta rapida porte di ricezione
selezionare Nuovo e selezionarePorta di ricezione unidirezionale .Nelle proprietà
porta di ricezione immettere le informazioni seguenti: Proprietà Descrizione Nome Immettere un nome per la porta di ricezione. Ad esempio, immettere LAReceivePort. di autenticazione di
- nessuna di autenticazione (impostazione predefinita): disabilitare l'autenticazione.
- Eliminare messaggi se l'autenticazione non riesce: abilitare l'autenticazione ma elimina i messaggi non autenticati.
- Mantenere i messaggi se l'autenticazione non riesce: abilitare l'autenticazione e mantenere i messaggi non autenticati.Abilitare il routing per i messaggi non riusciti Instradare qualsiasi messaggio che non riesce a elaborare un'applicazione di sottoscrizione, ad esempio un'altra porta di ricezione o una pianificazione dell'orchestrazione. Deselezionare questa opzione per sospendere i messaggi non riusciti e generare un riconoscimento negativo (NACK). Per impostazione predefinita, l'opzione è deselezionata.
Per altre informazioni, vedere How to Enable Routing for Failed Messages for a Receive Port.Selezionare Località di ricezionee selezionare Nuovo.
Immettere un Nome per il percorso di ricezione. Ad esempio, immettere LAReceiveLoc.
Per Tipo, selezionare LogicAppe quindi selezionare Configura.
Nella scheda Generale configurare l'indirizzo dell'endpoint per il flusso di lavoro dell'app per la logica:
Proprietà Descrizione indirizzo (URI) Obbligatorio. Immettere l'URL dell'applicazione IIS BizTalk ReceiveService come indicato di seguito:
Formato:/{your-IIS-app2-name}/Service1.svc
Esempio:/ReceiveWCFService/Service1.svc
.indirizzo pubblico Obbligatorio. Immettere l'URL seguente come indicato di seguito:
Formato:http://{fully-qualified-machine-name}/{your-IIS-App2-name}/Service1.svc
.
Esempio:http://btsProd.northamerica.corp.contoso.com/ReceiveWCFService/Service1.svc
Questo URL esatto è elencato anche nell'app per la logica nel percorso di ricezione.facoltativo . Nella scheda binding
configurare qualsiasi timeout e proprietà correlate alla codifica dell'associazione WCF-WebHttp sottostante. Quando si gestiscono messaggi di grandi dimensioni, sono utili le proprietà seguenti: Proprietà Descrizione di timeout di apertura Immettere l'intervallo di tempo previsto per il completamento dell'operazione di apertura del canale. Questo valore è maggiore o uguale a System.TimeSpan.Zero.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59di timeout di invio Immettere l'intervallo di tempo previsto per il completamento dell'operazione di invio. Questo valore è maggiore o uguale a System.TimeSpan.Zero. Se si usa una porta di ricezione request-response, questo valore specifica un intervallo di tempo per il completamento dell'intera interazione, anche se il client restituisce un messaggio di grandi dimensioni.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59timeout di chiusura Immettere l'intervallo di tempo previsto per il completamento dell'operazione di chiusura del canale. Questo valore è maggiore o uguale a System.TimeSpan.Zero.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59Dimensione massima messaggio ricevuta (byte) Immettere le dimensioni massime in byte per un messaggio, incluse le intestazioni, da ricevere in transito. La dimensione del messaggio è associata alla quantità di memoria allocata per ogni messaggio. È possibile usare questa proprietà per limitare l'esposizione agli attacchi Denial of Service (DoS).
- Valore predefinito: 65536
- Valore massimo: 2147483647Numero massimo di chiamate simultanee Immettere il numero di chiamate simultanee a una singola istanza del servizio. Le chiamate che superano il limite vengono accodate. L'impostazione di questo valore su 0 equivale a impostare il valore su Int32.MaxValue.
Valore predefinito: 200facoltativo . Nella scheda sicurezza
configurare le proprietà di sicurezza. A scopo di sviluppo, è possibile selezionare Nessuno: Proprietà Descrizione modalità di sicurezza - Nessuna: i messaggi non sono protetti durante il trasferimento.
- Transport: la sicurezza viene fornita tramite il trasporto HTTPS. I messaggi SOAP vengono protetti tramite HTTPS. Per usare questa modalità, è necessario configurare Secure Sockets Layer (SSL) in IIS.
- TransportCredentialOnly: impostazione predefinita.tipi di credenziali client trasporto Selezionare il tipo di credenziale quando si usa l'autenticazione client.
- Nessuna: nessuna autenticazione viene eseguita a livello di trasporto.
- basic: usare l'autenticazione di base per inviare nomi utente e password in testo normale in rete. È necessario creare gli account utente locali o di dominio corrispondenti alle credenziali.
- Digest: usare l'autenticazione digest per inviare password come valore hash in rete. Disponibile solo nei domini con controller di dominio che eseguono l'autenticazione dei sistemi operativi Windows Server. È necessario creare gli account utente locali o di dominio corrispondenti alle credenziali client.
- ntlm (impostazione predefinita): i client inviano le credenziali senza inviare una password a questo percorso di ricezione. È necessario creare gli account utente locali o di dominio corrispondenti alle credenziali client.
- Windows: l'autenticazione integrata di Windows negozia Kerberos o NTLM, preferendo Kerberos se è presente un dominio. Per usare Kerberos, è importante che il client identifichi il servizio con un nome dell'entità servizio (SPN). È necessario creare gli account utente locali o di dominio corrispondenti alle credenziali client.
- Certificato: usare un certificato client. È necessario installare la catena di certificati CA per i certificati X.509 client nell'archivio certificati Autorità di certificazione radice attendibili di questo computer in modo che i client possano eseguire l'autenticazione in questo percorso di ricezione.
- InheritedFromHostusare l'accesso Single Sign-On facoltativo . Nella scheda Messaggi di
utilizzare la proprietà Intestazioni HTTP in uscita per aggiungere intestazioni personalizzate e utilizzare le proprietà aggiuntive per risolvere gli errori:Proprietà Descrizione intestazioni HTTP in uscita Immettere le intestazioni HTTP desiderate nel messaggio di risposta. Disabilitare il percorso in caso di errore Disabilitare il percorso di ricezione se l'elaborazione in ingresso non riesce a causa di un errore della pipeline di ricezione o di un errore di routing. Per impostazione predefinita, l'opzione è deselezionata. Sospendere il messaggio di richiesta in caso di errore Sospendere il messaggio di richiesta se l'elaborazione in ingresso non riesce a causa di un errore della pipeline di ricezione o di un errore di routing. Per impostazione predefinita, l'opzione è deselezionata. Includere i dettagli dell'eccezione nelle degli errori Quando si verifica un errore, restituire eventuali errori SOAP per facilitare il debug. Per impostazione predefinita, l'opzione è deselezionata.
Per altre proprietà della porta di ricezione e della posizione, vedere Gestione dei percorsi di ricezione.
Passaggio 4: Inviare un messaggio
Aprire lo strumento per l'invio di messaggi o richieste HTTP.
Incollare l'URL dell'endpoint salvato dal trigger richiesta
nel flusso di lavoro dell'app per la logica. Questo URL è stato copiato in un passaggio precedente. Selezionare post come metodo HTTP da usare. Impostare l'intestazione tipo di contenuto
su . Nel corpo della richiesta incollare il codice JSON seguente e seguire le istruzioni dello strumento per inviare il messaggio HTTP. {"hello":"world"}
Poiché la richiesta è una chiamata unidirezionale a BizTalk, si dovrebbe prevedere un HTTP 202 come risultato.
Se si usa l'esempio HelloWorld SDK, passare al server BizTalk. È possibile che nella cartella di invio esista un file.
Inviare messaggi al flusso di lavoro dell'app per la logica
Passaggio 1: Creare un flusso di lavoro dell'app per la logica
Nel portale di Azure creare una nuova risorsa dell'app per la logica e un flusso di lavoro vuoto.
Seguire questi passaggi generici per aggiungere il trigger di richiesta al flusso di lavoro.denominato Quando viene ricevuta una richiesta HTTP Supponendo di disporre di un account microsoft aziendale o dell'istituto di istruzione, seguire questi passaggi generici per aggiungere l'azione office 365 di Office 365 denominata Inviare un di posta elettronica al flusso di lavoro.
Se richiesto, accedere a Office 365 Outlook.
Nel riquadro di connessione dell'azione specificare le informazioni seguenti:
Proprietà Descrizione a Immettere l'indirizzo di posta elettronica di Office 365. oggetto Immettere Invio da BizTalk. corpo Selezionare all'interno della casella di modifica. Quando vengono visualizzate le icone di fulmine e funzione, selezionare l'icona a forma di fulmine per aprire l'elenco di contenuto dinamico. Nell'elenco, in Quando viene ricevuta una richiesta HTTP, selezionare l'output del trigger da includere nel messaggio di posta elettronica. Il flusso di lavoro è simile all'esempio seguente:
Salvare il flusso di lavoro. Nella finestra di progettazione selezionare Salva.
Nel trigger richiesta informazioni copiare l'URL HTTP , che viene creato automaticamente quando si salva il flusso di lavoro. Questo URL è necessario per il passaggio successivo. Se l'URL non viene visualizzato, potrebbe essere necessario chiudere e riaprire l'app per la logica.
Passaggio 2: Creare una porta di trasmissione
Affinché BizTalk Server invii messaggi a un flusso di lavoro dell'app per la logica, il flusso di lavoro deve iniziare con un trigger manual
, ad esempio Quando viene ricevuta una richiesta HTTP.
In Amministrazione bizTalk Server espandere quanto segue:
applicazioni bizTalk Group Espandere l'applicazione da usare per l'esecuzione della porta di trasmissione. Ad esempio, espandere 'applicazione BizTalk - Invia.
Dal menu di scelta rapida porte di trasmissione
selezionare Nuovo e selezionareporta di trasmissione statica unidirezionale .Immettere un Nome per la porta di trasmissione. Ad esempio, immettere LASendPort.
Nell'elenco Tipo di selezionare LogicAppe selezionare Configura.
Nella scheda Generale
specificare il URI di callback per il trigger del flusso di lavoro dell'app per la logica scegliendo un'opzione: opzione 1
Nella proprietà trigger (URI di callback)
incollare l'URL HTTP copiato in precedenza . Mancia
È anche possibile usare le API di Azure Resource Manager per ottenere questo URI.
opzione 2
Se non si conosce l'URI di callback , selezionare Configurae accedere ad Azure. Selezionare i valori per Sottoscrizione, gruppo di risorse, app per la logicae Trigger.
facoltativo . Nella scheda binding
configurare qualsiasi timeout e proprietà correlate alla codifica dell'associazione WCF-WebHttp sottostante. Queste proprietà sono utili quando si gestiscono messaggi di grandi dimensioni: Proprietà Descrizione di timeout di apertura Immettere l'intervallo di tempo previsto per il completamento dell'operazione di apertura del canale. Questo valore è maggiore o uguale a System.TimeSpan.Zero.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59di timeout di invio Immettere l'intervallo di tempo previsto per il completamento dell'operazione di invio. Questo valore è maggiore o uguale a System.TimeSpan.Zero. Se si usa una porta di ricezione request-response, questo valore specifica un intervallo di tempo per il completamento dell'intera interazione, anche se il client restituisce un messaggio di grandi dimensioni.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59timeout di chiusura Immettere l'intervallo di tempo previsto per il completamento dell'operazione di chiusura del canale. Questo valore è maggiore o uguale a System.TimeSpan.Zero.
- Valore predefinito: 00:01:00
- Valore massimo: 23:59:59Dimensione massima messaggio ricevuta (byte) Immettere le dimensioni massime in byte per un messaggio, incluse le intestazioni, da ricevere in transito. La dimensione del messaggio è associata alla quantità di memoria allocata per ogni messaggio. È possibile usare questa proprietà per limitare l'esposizione agli attacchi Denial of Service (DoS).
L'adattatore App per la logica di Azure usa la classe WebHttpBinding nella modalità di trasferimento memorizzato nel buffer per comunicare con un endpoint. Per la modalità di trasporto memorizzato nel buffer, la proprietà WebHttpBinding.MaxBufferSize è sempre uguale al valore di questa proprietà.
- Valore predefinito: 65536
- Valore massimo: 2147483647facoltativo . Nella scheda messaggi di
utilizzare la proprietà intestazioni HTTP in uscita per aggiungere eventuali intestazioni personalizzate nel messaggio in uscita. Selezionare OK per salvare la configurazione.
Per altre proprietà della porta di trasmissione, vedere Gestione delle porte di trasmissione e dei gruppi di porte di trasmissione.
Passaggio 3: Inviare alcuni messaggi
È possibile creare una porta di ricezione e un percorso di ricezione usando l'adattatore file
Creare una porta di ricezione, ad esempio *FileSendPort.
Creare un percorso di ricezione e impostare le proprietà simili ai valori di esempio seguenti:
Proprietà Input di esempio di ricezione cartella C:\temp\In\
maschera file *.txt
pipeline PassThruReceive
Nella porta di trasmissione creata in precedenza impostare il Filtro
sui valori di esempio seguenti: Proprietà Operatore Valore BTS. ReceivePortName == FileSendPort
Creare un file di testo denominato {file-name}.txt con il testo seguente e quindi questo file di testo come messaggio di esempio:
<Data> <DataID>DataID_0</DataID> <DataDetails>DataDetails_0</DataDetails> </Data>
Copiare {file-name}.txt nella cartella di ricezione.
La porta di trasmissione invia il file .txt al flusso di lavoro dell'app per la logica usando l'URI fornito. Dopo che il flusso di lavoro riceve i file, il flusso di lavoro invia un messaggio di posta elettronica con il messaggio di esempio all'indirizzo di a specificato.