Panoramica delle politiche

Le policy possono controllare particolari proprietà del nodo, come le credenziali di connessione e alcuni aspetti del comportamento del flusso di messaggi, inclusa la portata. Le policy forniscono una definizione condivisa e gestita che è possibile riutilizzare.

Le policy contengono proprietà operative definite e consentono le seguenti funzionalità dell'utente:
  • Gli sviluppatori possono utilizzare le policy per controllare il funzionamento di runtime e riutilizzare le informazioni di configurazione in più luoghi, eliminando quindi la duplicazione degli sforzi. Laddove le policy siano utilizzate per sovrascrivere le proprietà del flusso di messaggi in fase di esecuzione, le informazioni come i dettagli di connessione possono essere aggiornate senza dover aggiornare i flussi di messaggi.
  • Gli amministratori possono utilizzare le policy per definire i dati di configurazione chiave per ogni ambiente e per sovrascrivere le proprietà specificate dagli sviluppatori del flusso di messaggi. Questa capacità è utile se i dettagli di connessione sono diversi per ambienti diversi (come lo sviluppo, il test e i sistemi di produzione.) Gli amministratori possono anche aggiornare le policy con dati sensibili che potrebbero non essere disponibili agli sviluppatori.
  • Gli operatori possono utilizzare le policy per monitorare e modificare dinamicamente i dati di configurazione.
È possibile allegare una politica a una o più entità che si desidera controllare, come i flussi di messaggi, i nodi del flusso di messaggi o server di integrazione. Ad esempio, se si aggiunge un nodo AggregateControl al flusso, è possibile utilizzare la proprietà Nome aggregazione sul nodo del flusso di messaggi per associare i flussi fan - in e fan - out. In alternativa, può specificare il nome di una politica di aggregazione. Se si specifica solo il nome della normativa nella proprietà Nome aggregato , la politica viene richiamata dal progetto policy predefinito. In alternativa, specificare una politica in un diverso progetto di policy utilizzando il seguente formato nella proprietà del nodo del flusso di messaggi:
{PolicyProjectName}:PolicyName
Se la politica denominata non può essere trovata, il flusso di messaggi non può essere avviato.
È anche possibile fare riferimento a una politica da un nodo JavaCompute utilizzando il nome della politica nel codice Java; ad esempio,
MbPolicy myUserPolicy = getPolicy("UserDefined", "{MyPolicyProject}:MyUserPolicy");

Le politiche sono documenti XML, definiti da unaPolicy.xsd(XML Schema Definition) che si trova nella directory di installazione predefinita. Ad esempio, in Windows, è possibile trovare il file di definizione della politica in C:\Program Files\IBM\ACE\version\common\schemas\Policy.

Servizi configurabili

Le policy sostituiscono i servizi configurabili in App Connect Enterprise. È possibile migrare i servizi configurabili esistenti alle politiche utilizzando il comando mqsiextractcomponents (consultare Comando mqsiextractcomponents).

Il comando mqsicreateconfigurableservice è obsoleto in App Connect Enterprisee non crea più servizi configurabili. Tuttavia, se si utilizza il comando mqsicreateconfigurableservice nei propri script IBM Integration Bus , questo comando crea politiche equivalenti (laddove supportate) in App Connect Enterprise (consultare Comando mqsicreateconfigurableservice (obsoleto)).

Le politiche create dal comando mqsicreateconfigurableservice vengono create nel progetto di politica predefinito (DefaultPolicies) e sono associate a un nodo di integrazione . Queste politiche vengono ereditate da tutti i server di integrazione su tale nodo di integrazione . È possibile sovrascrivere una politica ereditata da un server di integrazione dal nodo di integrazione distribuendo una versione aggiornata della politica a quel server di integrazione . In alternativa, è possibile inserire una politica aggiornata nella directory secondaria overrides della directory di lavoro del server di integrazione (vedere Ordine di precedenza per le sovrascritture).

Progetti di politica

Quando si esegue un comando mqsicreateworkdir , viene creato un file di configurazione denominato server.conf.yaml , che contiene impostazioni predefinite per il server di integrazione. Questo file di configurazione definisce un progetto policy predefinito, utilizzato per memorizzare politiche non qualificate. Quando crei una politica in IBM App Connect Enterprise Toolkit, devi crearla in un progetto di politiche. Quando si fa riferimento ad una politica da un nodo del flusso di messaggi o del flusso di messaggi, utilizzare il nome della politica se la politica è nel progetto di policy predefinito. Se la politica si trova in un progetto di politica differente, anteporre al nome della politica il nome del progetto di politica, con il formato {policyProject}:PolicyName. Puoi utilizzare i progetti di politica per organizzare le tue risorse e puoi aggiungere altrettante politiche a un progetto di politica come vuoi. Ad esempio, il tuo progetto di politica potrebbe organizzare delle politiche nei seguenti modi:
  • Il tuo progetto policy potrebbe contenere tutte le policy per un particolare server di integrazione.
  • Il progetto potrebbe contenere tutte le policy di un tipo particolare (ad esempio tutte le policy JDBC Provider) per un server di integrazione.
  • Potrebbe contenere tutte le policy per un'applicazione specifica.
Per ulteriori informazioni sulla creazione di politiche, vedi Creazione di politiche con il toolkit IBM App Connect Enterprise.

Progetto e politiche di default policy

Un progetto di politica predefinito denominato DefaultPolicies è definito nel file server.conf.yaml per il server di integrazione. Le politiche che vengono create dal comando mqsicreateconfigurableservice vengono create in questo progetto di politica predefinito. È anche possibile specificare determinate politiche predefinite per controllare le risorse su un server di integrazione impostandole nel file server.conf.yaml per quel server di integrazione (consultare Configurazione di un server di integrazione modificando il file server.conf.yaml). Il seguente estratto dal file server.conf.yaml indica che è possibile fornire criteri predefiniti che controllano le seguenti impostazioni:
  • Specificare una policy di monitoraggio predefinita di monitoraggio per configurare il monitoraggio per i flussi di messaggi. Per ulteriori informazioni, consultare Profili di monitoraggio.
Defaults:
 defaultApplication: ''       # Name a default application under which independent resources will be placed
 policyProject: 'DefaultPolicies'   # Name of the Policy project that will be used for unqualified Policy references
 Policies:
   # Set default policy names, optionally qualified with a policy project as {policy project}:name
      monitoringProfile: ''       # Default Monitoring profile
Dopo aver creato la politica, impostare il nome della politica nel file server.conf.yaml . Se la politica predefinita si trova nel progetto di politica, non è necessario specificare il nome del progetto di politica. Se la politica predefinita si trova in un progetto di politica non predefinito, qualificare il nome della politica con il nome del progetto di politica ({policyProject}:PolicyName).

Distribuzione della politica

Si distribuiscono le policy in progetti di policy in un file BAR indipendente o in un file BAR con il flusso di messaggi associato. Come amministratore, è anche possibile sovrascrivere le politiche distribuite utilizzando la sottodirectory overrides del server di integrazione . Per ulteriori informazioni, vedi Sostituzione delle politiche distribuite in fase di runtime con la directory di sovrascrittura. Se un nome policy è impostato specificamente su un nodo del flusso di messaggi o del flusso di messaggi, è necessario distribuire la politica prima che il flusso di messaggi possa essere avviato. Se una politica non viene specificata esplicitamente su un flusso di messaggi o di flusso di messaggi, è necessario distribuire la politica prima o con il flusso di messaggi.

È possibile modificare e ridistribuire alcuni tipi di politica dopo che sono schierati, ridistribuendo il progetto di policy. Quando si ridistribuisce il progetto della politica, tutti i flussi di messaggi che stanno utilizzando la politica vengono fermati e riavviati. Per ulteriori informazioni sui tipi di politica che è possibile ridistribuire, consultare Proprietà della politica.

Per altri tipi di politica, che non può essere ridistribuita, è necessario eliminare tutte le risorse distribuite dal server di integrazione utilizzando il parametro IBM App Connect Enterprise Toolkit o il parametro -m sul comando mqsideploy . Poi, è necessario distribuire una nuova versione del progetto policy e dei flussi di messaggi. In alternativa, è possibile inserire una copia aggiornata della politica nella sottodirectory overrides della directory di lavoro server di integrazione , quindi riavviare il server di integrazione per selezionare i nuovi valori.

Le politiche distribuite vengono visualizzate nella sottodirectory run della directory di lavoro del server di integrazione , all'interno di una sottodirectory che ha il nome del progetto di politica. È possibile visualizzare le proprietà delle politiche distribuite in Integration Explorer di IBM App Connect Enterprise Toolkit o nella scheda Politiche dell'interfaccia utente Web (consultare Accesso all'interfaccia utente Web). È inoltre possibile vedere quali proprietà vengono utilizzate dal flusso distribuito in fase di esecuzione utilizzando l'interfaccia REST API o web user.

Per ulteriori informazioni sulla distribuzione della politica, vedi "Cosa fare dopo" in Creazione di politiche con IBM App Connect Enterprise Toolkit.

Ordine di precedenza per le sovrascritture

È possibile sovrascrivere una politica distribuita inserendo un progetto di politica aggiornato nella sottodirectory overrides della directory di lavoro del server di integrazione e riavviando il server di integrazione (consultare Sostituzione delle politiche distribuite al runtime con la directory di sovrascrittura).

Le seguenti regole di precedenza si applicano ai valori di proprietà operativa:
  • Le proprietà nelle politiche HTTP o HTTPS Connector sovrascrivono completamente le proprietà impostate dal connettore HTTP o HTTPS nella sezione ResourceManagers del file server.conf.yaml .
  • Un valore in una politica nella sottodirectory overrides della directory di lavoro sovrascrive un valore in una politica schierata.
  • Un valore in una politica distribuita sovrascrive un valore in una politica a livello di nodo di integrazione creata dal comando mqsicreateconfigurableservice .
  • Un valore in una policy di livello nodo di integrazione ha la precedenza su un valore sovrascritto in un file BAR o impostato sul nodo.
  • Quando nessuna politica esiste per un valore di proprietà operativa, il valore sovrascritto in un file BAR ha la precedenza sul valore impostato sul nodo.
  • Quando non esiste alcuna sostituzione di file policy o BAR per un valore di proprietà operativa, il valore impostato sul nodo ha la precedenza.
Suggerimento: Se hai progettato il tuo flusso di messaggi per includere una sovrascrittura di ambiente locale, qualsiasi valore di proprietà impostato dall'ambiente locale sovrascriva sovrascrivi un valore impostato da una policy, una sovrascrittura di file BAR o sul nodo.

Le politiche sostituiscono servizi configurabili in IBM App Connect Enterprise Versione 11.0. Nelle versioni precedenti, se si utilizzava un servizio configurabile per sovrascrivere le proprietà del nodo in fase di esecuzione, una proprietà vuota in un servizio configurabile sovrasta una proprietà del nodo con un valore vuoto. Tuttavia, quando si utilizza una politica, una proprietà vuota in una politica non sovrasta la proprietà del nodo con un valore vuoto. In questo caso, viene utilizzato il valore impostato dalla proprietà del nodo.

Tipi di politica

Oltre ai tipi di politica elencati in Proprietà della politica, i profili di monitoraggio e le serie di politiche e i collegamenti sono forme di politica che possono essere utilizzate per sovrascrivere proprietà in fase di runtime. Per ulteriori informazioni su questi tipi di politica, consultare Monitoraggio dei profili e Serie di politiche.