Estensione delle capacità di un nodo di input in C

Prima di iniziare

Assicurarsi di aver letto e appreso il seguente argomento:
Una volta creato un nodo definito dall'utente, sono disponibili le seguenti opzioni:
  1. Ricezione di dati esterni in un buffer
  2. Gestione del thread e delle transazioni
  3. Distribuzione del messaggio

Ricezione di dati esterni in un buffer

Un nodo di input può ricevere dati da qualsiasi tipo di origine esterna, come un file system o connessioni FTP, purché l'output proveniente dal nodo sia nel formato corretto. Relativamente alle connessioni alle code o a database, è necessario utilizzare i nodi primitivi IBM e le chiamate API fornite, principalmente perché tali nodi sono già impostati per la gestione degli errori. Non utilizzare i comandi mqget o mqput per accedere direttamente alle code WebSphere MQ.

È necessario fornire un buffer di input (o flusso di bit) per contenere dati di input e associarlo ad un oggetto messaggio. Nell'API in C, il buffer viene collegato all'oggetto CciMessage che rappresenta il messaggio di input utilizzando la funzione di utilità cniSetInputBuffer. Ad esempio:
{
  	static char* functionName = (char *)"_Input_run()";
  	void* buffer;
  CciTerminal*         terminalObject;
  	int buflen = 4096;
  	int rc = CCI_SUCCESS;
  	int rcDispatch = CCI_SUCCESS;
  
  buffer = readFromDevice(&buflen);
  cniSetInputBuffer(&rc, message, buffer, buflen);
}
/*esecuzione distribuzione, ecc.*/

Gestione del thread e delle transazioni

Un nodo di input ha la responsabilità di concludere in modo appropriato l'elaborazione dei messaggi quando un messaggio viene distribuito in un flusso di messaggi. In particolare, il nodo di input deve fare in modo che venga eseguito il commit o il rollback di ogni transazione e che i thread vengano restituiti al relativo pool.

Ogni thread del flusso di messaggi è assegnato da un pool di thread mantenuto per ciascun flusso di messaggi e la cui esecuzione viene avviata nella funzione cniRun. Il funzionamento di un thread viene determinando utilizzando la funzione di utilità cniDispatchThread insieme al valore di restituzione appropriato.

Dalla funzione cniRun, è possibile chiamare la funzione di utilità cniDispatchThread per consentire a un altro thread l'avvio dell'esecuzione della funzione cniRun. Il momento più adeguato per eseguire un altro thread è direttamente dopo avere stabilito che potrebbero essere presenti dei dati disponibili per la funzione da elaborare sul nuovo thread.

Il termine transazione viene qui utilizzato in modo generico per descrivere una transazione coordinata in modo globale o una transazione gestita dal broker. Le transazioni coordinate in modo globale sono coordinate da WebSphere MQ come una gestione transazione compatibile con XA o da RRS (Resource Recovery Service) su z/OS. WebSphere Message Broker gestisce le transazioni eseguendo il commit (o il rollback) delle risorse di database e quindi eseguendo il commit di eventuali unità di lavoro WebSphere MQ; tuttavia, se viene utilizzato un nodo definito dall'utente, il broker non può eseguire automaticamente il commit di eventuali aggiornamenti di risorsa. Il nodo definito dall'utente utilizza valori di restituzione per indicare se una transazione ha avuto esito positivo e per controllare se è stato eseguito il commit o il rollback delle transazioni. Eventuali eccezioni non gestite sono rilevate dall'infrastruttura del broker e viene eseguito il rollback della transazione.

Nella tabella riportata di seguito è riportata la descrizione dei valori di restituzione supportati, l'influenza di ognuno di questi sulle transazioni e l'azione intrapresa dal broker nei confronti del thread attuale.

Valore di restituzione Influenza sulla transazione Azione del broker sul thread
CCI_SUCCESS_CONTINUE eseguito commit Richiama nuovamente lo stesso thread nella funzione cniRun.
CCI_SUCCESS_RETURN eseguito commit Restituisce il thread al relativo pool.
CCI_FAILURE_CONTINUE eseguito rollback Richiama nuovamente lo stesso thread nella funzione cniRun.
CCI_FAILURE_RETURN eseguito rollback Restituisce il thread al relativo pool.
CCI_TIMEOUT Non applicabile. Tempo limite raggiunto periodicamente dalla funzione nell'attesa di un messaggio di input. Richiama nuovamente lo stesso thread nella funzione cniRun.
Di seguito è riportato un esempio dell'utilizzo del codice di ritorno SUCCESS_RETURN con la funzione cniDispatchThread:
{
  ...
  cniDispatchThread(&rcDispatch, ((NODE_CONTEXT_ST *)context)->nodeObject);
  ...
  if (rcDispatch == CCI_NO_THREADS_AVAILABLE) return CCI_SUCCESS_CONTINUE;  
  else return CCI_SUCCESS_RETURN;
}     

Distribuzione del messaggio

Prima di distribuire un messaggio è necessario decidere quali dati del flusso di messaggi si desidera distribuire e quale terminale deve ricevere tali dati.

terminalObject viene ricavato da un elenco che il nodo definito dall'utente mantiene egli stesso.

Ad esempio, per distribuire il messaggio al terminale di output, viene utilizzata la funzione cniPropagate:
  if (terminalObject) {
    if (cniIsTerminalAttached(&rc, terminalObject)) {
      if (rc == CCI_SUCCESS) {
        cniPropagate(&rc, terminalObject, destinationList, exceptionList, message);
      }
    }

Nell'esempio riportato in precedenza, la funzione cniIsTerminalAttached viene utilizzata per verificare se il messaggio può essere distribuito al terminale specificato. Se la funzione cniIsTerminalAttached non viene utilizzata e il terminale non è collegato ad un altro nodo mediante un connettore, il messaggio non viene distribuito e nessun messaggio di avviso viene restituito. Utilizzare la funzione cniIsTerminalAttached per evitare che ciò si verifichi.

Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
as24988_