Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Cómo desarrollar complementos personalizados

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Edge Microgateway v. 3.3.x

Público

Este tema está dirigido a los desarrolladores que desean extender las funciones de Edge Microgateway escribiendo complementos personalizados. Si deseas escribir un nuevo complemento, se requiere experiencia con JavaScript y Node.js.

¿Qué es un complemento personalizado de Edge Microgateway?

Un complemento es un módulo de Node.js que agrega funcionalidad a Edge Microgateway. Los módulos de complementos siguen un patrón coherente y se almacenan en una ubicación conocida por Edge Microgateway, lo que permite que se descubran y ejecuten automáticamente. Cuando instalas Edge Microgateway, se proporcionan varios complementos predefinidos. Estos incluyen complementos para la autenticación, la detención de picos, la cuota y las estadísticas. Estos complementos existentes se describen en Usa complementos.

Puedes agregar nuevas funciones y capacidades al microgateway escribiendo complementos personalizados. De forma predeterminada, Edge Microgateway es básicamente un proxy de transferencia seguro que pasa solicitudes y respuestas sin cambios hacia y desde los servicios de destino. Con los complementos personalizados, puedes interactuar de forma programática con las solicitudes y respuestas que fluyen a través de la microgateway.

Dónde colocar el código del complemento personalizado

Se incluye una carpeta para complementos personalizados como parte de la instalación de Edge Microgateway aquí:

[prefix]/lib/node_modules/edgemicro/node_modules/microgateway-plugins

donde [prefix] es el directorio de prefijo npm, como se describe en "¿Dónde se instala Edge Microgateway?" en Instalación de Edge Microgateway.

Puedes cambiar este directorio de complementos predeterminado. Consulta Dónde encontrar complementos.

Revisa los complementos predefinidos

Antes de intentar desarrollar tu propio complemento, es recomendable verificar que ninguno de los complementos predefinidos cumpla con tus requisitos. Estos complementos se encuentran en las siguientes ubicaciones:

[prefix]/lib/node_modules/edgemicro/node_modules/microgateway-plugins

donde [prefix] es el directorio de prefijo de npm. Consulta también "¿Dónde se instala Edge Microgateway?" en Instalación de Edge Microgateway.

Para obtener más información, consulta también Complementos predefinidos proporcionados con Edge Microgateway.

Escribe un complemento simple

En esta sección, veremos los pasos necesarios para crear un complemento simple. Este complemento anula los datos de respuesta (cualquiera que sean) con la cadena "Hello, World!" y los imprime en la terminal.

Si Edge Microgateway se está ejecutando, deténlo ahora:
```
edgemicro stop
```
cd en el directorio de complementos personalizados:
cd [prefix]/lib/node_modules/edgemicro/plugins

donde [prefix] es el directorio de prefijo npm, como se describe en "¿Dónde se instala Edge Microgateway?" en Instalación de Edge Microgateway.
Crea un proyecto de complemento nuevo llamado response-override y cd a él:
```
mkdir response-override && cd response-override
```
Crea un proyecto de Node.js nuevo:
```
npm init
```
Presiona Intro varias veces para aceptar los valores predeterminados.
Usa un editor de texto para crear un archivo nuevo llamado index.js.
Copia el siguiente código en index.js y guarda el archivo.
```
'use strict';
var debug = require('debug')

module.exports.init = function(config, logger, stats) {

  return {
   
    ondata_response: function(req, res, data, next) {
      debug('***** plugin ondata_response');
      next(null, null);
    },
    
    onend_response: function(req, res, data, next) {
      debug('***** plugin onend_response');
      next(null, "Hello, World!\n\n");
    }
  };
}
```
Nota: Las funciones del complemento (*_response) son controladores de eventos. Se llama a la función ondata_response cada vez que Edge Microgateway recibe un fragmento de datos. La función onend_response se llama cuando se recibe el último byte de los datos de respuesta.

Nota: Importante: Todas las funciones del complemento requieren la función next(). Esta función pasa error (primer argumento) y data (segundo argumento) a la siguiente función de complemento que se llama. Ten en cuenta que, en este ejemplo, el argumento data en ondata_response es nulo. Si se establece este argumento en nulo, podemos anular los datos de respuesta en onend_response. Si no establecemos el argumento en null, de forma predeterminada, los datos se pasarán a la respuesta, ya sea que los anulemos o no en onend_response.
Ahora que creaste un complemento, debes agregarlo a la configuración de Edge Microgateway. Abre el archivo $HOME/.edgemicro/[org]-[env]-config.yaml, donde org y env son los nombres de tu organización y entorno de Edge.
Agrega el complemento response-override al elemento plugins:sequence, como se muestra a continuación.
```
      ...
      
      plugins:
        dir: ../plugins
        sequence:
          - oauth
          - response-override
          
      ...
```
Nota: Nota: Los complementos se ejecutan en el orden en que aparecen en la lista plugins:sequence.
Reinicia Edge Microgateway.
Llama a una API a través de Edge Microgateway. (Esta llamada a la API supone que configuraste la misma configuración que el instructivo con seguridad de clave de API, como se describe en Cómo configurar Edge Microgateway:
```
curl -H 'x-api-key: uAM4gBSb6YoMvTHfx5lXJizYIpr5Jd' http://localhost:8000/hello/echo
Hello, World!
```

Anatomía de un complemento

El siguiente complemento de muestra de Edge Microgateway ilustra el patrón que se debe seguir cuando desarrollas tus propios complementos. El código fuente del complemento de ejemplo que se analiza en esta sección se encuentra en plugins/header-uppercase/index.js..

Los complementos son módulos NPM estándar con un package.json y un index.js en la carpeta raíz.
Un complemento debe exportar una función init().
La función init() toma tres argumentos: config, logger y stats. Estos argumentos se describen en los argumentos de la función init() del complemento.
init() devuelve un objeto con controladores de funciones con nombre que se llaman cuando ocurren ciertos eventos durante el ciclo de vida de una solicitud.

Funciones de controlador de eventos

Un complemento debe implementar algunas o todas estas funciones de controlador de eventos. La implementación de estas funciones depende de ti. Cualquier función determinada es opcional, y un complemento típico implementará al menos un subconjunto de estas funciones.

Controladores de eventos de flujo de solicitud

Estas funciones se llaman en los eventos de solicitud en Edge Microgateway.

onrequest
ondata_request
onend_request
onclose_request
onerror_request

Función onrequest

Se llama al inicio de la solicitud del cliente. Esta función se activa cuando Edge Microgateway recibe el primer byte de la solicitud. Esta función te brinda acceso a los encabezados de la solicitud, la URL, los parámetros de consulta y el método HTTP. Si llamas a next con un primer argumento verdadero (como una instancia de Error), se detiene el procesamiento de la solicitud y no se inicia una solicitud de destino.

Ejemplo:

onrequest: function(req, res, next) {
      debug('plugin onrequest');
      req.headers['x-foo-request-start'] = Date.now();
      next();
    }

Función ondata_request

Se llama cuando se recibe un fragmento de datos del cliente. Pasa los datos de la solicitud al siguiente complemento de la secuencia. El valor devuelto del último complemento de la secuencia se envía al destino. Un caso de uso típico, que se muestra a continuación, es transformar los datos de la solicitud antes de enviarlos al destino.

Ejemplo:

ondata_request: function(req, res, data, next) {
      debug('plugin ondata_request ' + data.length);
      var transformed = data.toString().toUpperCase();
      next(null, transformed);
    }

Función onend_request

Se llama cuando se reciben todos los datos de la solicitud del cliente.

Ejemplo:

onend_request: function(req, res, data, next) {
      debug('plugin onend_request');
      next(null, data);
    }

Función onclose_request

Indica que se cerró la conexión del cliente. Puedes usar esta función en los casos en que la conexión del cliente no sea confiable. Se llama a este método cuando se cierra la conexión de socket con el cliente.

Ejemplo:

onclose_request: function(req, res, next) {
      debug('plugin onclose_request');
      next();
    }

Función onerror_request

Se llama si se produce un error al recibir la solicitud del cliente.

Ejemplo:

onerror_request: function(req, res, err, next) {
      debug('plugin onerror_request ' + err);
      next();
    }

Controladores de eventos de flujo de respuesta

Estas funciones se llaman en los eventos de respuesta en Edge Microgateway.

onresponse
ondata_response
onend_response
onclose_response
onerror_response

Función onresponse

Se llama al inicio de la respuesta del destino. Esta función se activa cuando Edge Microgateway recibe el primer byte de la respuesta. Esta función te brinda acceso a los encabezados de respuesta y al código de estado.

Ejemplo:

onresponse: function(req, res, next) {      
    debug('plugin onresponse');     
    res.setHeader('x-foo-response-time', Date.now() - req.headers['x-foo-request-start'])    
    next();    
}

Función ondata_response

Se llama cuando se recibe un fragmento de datos del destino.

Ejemplo:

ondata_response: function(req, res, data, next) {
      debug('plugin ondata_response ' + data.length);
      var transformed = data.toString().toUpperCase();
      next(null, transformed);
    }

Función onend_response

Se llama cuando se reciben todos los datos de respuesta del destino.

Ejemplo:

onend_response: function(req, res, data, next) {
      debug('plugin onend_response');
      next(null, data);
    }

Función onclose_response

Indica que se cerró la conexión de destino. Puedes usar esta función en los casos en que la conexión de destino no sea confiable. Se llama a este método cuando se cierra la conexión de socket con el destino.

Ejemplo:

onclose_response: function(req, res, next) {
      debug('plugin onclose_response');
      next();
    }

Función onerror_response

Se llama si se produce un error al recibir la respuesta del destino.

Ejemplo:

onerror_response: function(req, res, err, next) {
      debug('plugin onerror_response ' + err);
      next();
    }

Qué debes saber sobre las funciones de controlador de eventos del complemento

Las funciones de controlador de eventos de complementos se llaman en respuesta a eventos específicos que ocurren mientras Edge Microgateway procesa una solicitud a la API determinada.

Cada uno de los controladores de la función init() (ondata_request, ondata_response, etc.) debe llamar a la devolución de llamada next() cuando termine el procesamiento. Si no llamas a next(), el procesamiento se detendrá y la solicitud se quedará en espera.
El primer argumento de next() puede ser un error que hará que se detenga el procesamiento de la solicitud.
Los controladores ondata_ y onend_ deben llamar a next() con un segundo argumento que contenga los datos que se pasarán al destino o al cliente. Este argumento puede ser nulo si el complemento está almacenando en búfer y no tiene suficientes datos para transformar en el momento.
Ten en cuenta que se usa una sola instancia del complemento para atender todas las solicitudes y respuestas. Si un complemento desea conservar el estado por solicitud entre llamadas, puede guardar ese estado en una propiedad agregada al objeto request (req) proporcionado, cuya vida útil es la duración de la llamada a la API.
Ten cuidado de detectar todos los errores y llamar a next() con el error. Si no se llama a next(), la llamada a la API se bloqueará.
Ten cuidado de no introducir fugas de memoria, ya que pueden afectar el rendimiento general de Edge Microgateway y provocar que falle si se queda sin memoria suficiente.
Ten cuidado de seguir el modelo de Node.js y no realizar tareas que requieran mucha capacidad de procesamiento en el subproceso principal, ya que esto puede afectar negativamente el rendimiento de Edge Microgateway.

Acerca de la función init() del complemento

En esta sección, se describen los argumentos que se pasan a la función init(): config, logger y stats.

config

Los datos de configuración que se obtienen al combinar el archivo de configuración de Edge Microgateway con los datos descargados de Apigee Edge se colocan en un objeto llamado config.

Para agregar un parámetro de configuración llamado param con un valor de foo a un complemento llamado response-override, coloca lo siguiente en el archivo default.yaml:

response-override:
    param: foo

Luego, puedes acceder al parámetro en el código de tu complemento de la siguiente manera:

// Called when response data is received
    ondata_response: function(req, res, data, next) {
      debug('***** plugin ondata_response');
      debug('***** plugin ondata_response: config.param: ' + config.param);
      next(null, data);
    },

En este caso, verás foo impreso en el resultado de depuración del complemento:

Sun, 13 Dec 2015 21:25:08 GMT plugin:response-override ***** plugin ondata_response: config.param: foo

Puedes acceder a la configuración combinada de microgateway y a los datos descargados de Apigee Edge en el objeto secundario config.emgConfigs. Por ejemplo, puedes acceder a estos datos de configuración en la función init de la siguiente manera:

module.exports.init = function(config, logger, stats) {
   let emgconfigs = config.emgConfigs;

Nota: El objeto emgConfigs se agregó en la versión 3.1.6. El nombre de clave emgConfigs está reservado y no se puede usar para definir ninguna otra configuración en la configuración de un complemento en el archivo de configuración YAML. Si se define, el valor se reemplazará en el tiempo de ejecución.

A continuación, se muestra un ejemplo de los datos que contiene emgConfigs:

{
    edgemicro:
    {
        port: 8000,
        max_connections: 1000,
        config_change_poll_interval: 600,
        logging:
        {
            level: 'error',
            dir: '/var/tmp',
            stats_log_interval: 60,
            rotate_interval: 24,
            stack_trace: false
        },
        plugins: { sequence: [Array] },
        global: { org: 'Your Org', env: 'test' }
    },
    headers:
    {
        'x-forwarded-for': true,
        'x-forwarded-host': true,
        'x-request-id': true,
        'x-response-time': true,
        via: true
    },
    proxies:
    [    {
                max_connections: 1000,
                name: 'edgemicro_delayed',
                revision: '1',
                proxy_name: 'default',
                base_path: '/edgemicro_delayed',
                target_name: 'default',
                url: 'https://httpbin.org/delay/10',
                timeout: 0
            }
    ],
    product_to_proxy: { EdgeMicroTestProduct: [ 'edgemicro-auth','edgemicro_delayed',] },
    product_to_scopes: {prod4: [ 'Admin', 'Guest', 'Student' ] },
    product_to_api_resource: { EdgeMicroTestProduct: [ '/*' ] },
    _hash: 0,
    keys: { key: 'Your key', secret: 'Your key ' },
    uid: 'Internally generated uuid',
    targets: []
  }

logger

Es el registrador del sistema. El registrador empleado actualmente exporta estas funciones, en las que el objeto puede ser una cadena, una solicitud HTTP, una respuesta HTTP o una instancia de Error.

info(object, message)
warn(object, message)
error(object, message)
trace(object, message)
debug(object, message)

estadísticas

Es un objeto que contiene recuentos de solicitudes, respuestas, errores y otras estadísticas agregadas relacionadas con las solicitudes y las respuestas que fluyen a través de una instancia de microgateway.

treqErrors: Es la cantidad de solicitudes de destino con errores.
treqErrors: Es la cantidad de respuestas de destino con errores.
statusCodes: Es un objeto que contiene recuentos de códigos de respuesta:

{
  1: number of target responses with 1xx response codes
  2: number of target responses with 2xx response codes
  3: number of target responses with 3xx response codes
  4: number of target responses with 4xx response codes
  5: number of target responses with 5xx response codes
  }

requests: Es la cantidad total de solicitudes.
responses: Es la cantidad total de respuestas.
connections: Es la cantidad de conexiones de destino activas.

Acerca de la función next()

Todos los métodos del complemento deben llamar a next() para continuar procesando el siguiente método de la serie (de lo contrario, el proceso del complemento se bloqueará). En el ciclo de vida de la solicitud, el primer método al que se llama es onrequest(). El siguiente método al que se llama es ondata_request(). Sin embargo, ondata_request se llama solo si la solicitud incluye datos, como en el caso, por ejemplo, de una solicitud POST. El siguiente método al que se llamará será onend_request(), al que se llama cuando se completa el procesamiento de la solicitud. Las funciones onerror_* solo se llaman en caso de error y te permiten controlar los errores con código personalizado si lo deseas.

Supongamos que se envían datos en la solicitud y se llama a ondata_request(). Ten en cuenta que la función llama a next() con dos parámetros:

next(null, data);

Por convención, el primer parámetro se usa para transmitir información de errores, que luego puedes controlar en una función posterior de la cadena. Si lo establecemos en null, un argumento falso, indicamos que no hay errores y que el procesamiento de la solicitud debe continuar con normalidad. Si este argumento es verdadero (por ejemplo, un objeto Error), se detiene el procesamiento de la solicitud y se envía la solicitud al destino.

El segundo parámetro pasa los datos de la solicitud a la siguiente función de la cadena. Si no realizas ningún procesamiento adicional, los datos de la solicitud se pasan sin cambios al destino de la API. Sin embargo, tienes la oportunidad de modificar los datos de la solicitud dentro de este método y pasar la solicitud modificada al destino. Por ejemplo, si los datos de la solicitud son XML y el destino espera JSON, puedes agregar código al método ondata_request() que (a) cambie el Content-Type del encabezado de la solicitud a application/json y convierta los datos de la solicitud a JSON con los medios que desees (por ejemplo, puedes usar un convertidor xml2json de Node.js obtenido de NPM).

Veamos cómo podría verse:

ondata_request: function(req, res, data, next) {
  debug('****** plugin ondata_request');
  var translated_data = parser.toJson(data);
  next(null, translated_data);
},

En este caso, los datos de la solicitud (que se supone que están en XML) se convierten a JSON, y los datos transformados se pasan a través de next() a la siguiente función en la cadena de solicitudes, antes de pasarse al destino del backend.

Ten en cuenta que podrías agregar otra instrucción de depuración para imprimir los datos transformados con fines de depuración. Por ejemplo:

ondata_request: function(req, res, data, next) {
  debug('****** plugin ondata_request');
  var translated_data = parser.toJson(data);
  debug('****** plugin ondata_response: translated_json: ' + translated_json);
  next(null, translated_data);
},

Acerca del orden de ejecución del controlador de complementos

Si escribes complementos para Edge Microgateway, debes comprender el orden en el que se ejecutan los controladores de eventos de los complementos.

Lo importante que debes recordar es que, cuando especificas una secuencia de complementos en el archivo de configuración de Edge Microgateway, los controladores de solicitudes se ejecutan en orden ascendente, mientras que los controladores de respuestas se ejecutan en orden descendente.

El siguiente ejemplo está diseñado para ayudarte a comprender esta secuencia de ejecución.

1. Crea tres complementos simples

Considera el siguiente complemento. Lo único que hace es imprimir el resultado de la consola cuando se llaman sus controladores de eventos:

plugins/plugin-1/index.js

module.exports.init = function(config, logger, stats) {

  return {

    onrequest: function(req, res, next) {
      console.log('plugin-1: onrequest');
      next();
    },

    onend_request: function(req, res, data, next) {
      console.log('plugin-1: onend_request');
      next(null, data);
    },

    ondata_response: function(req, res, data, next) {
      console.log('plugin-1: ondata_response ' + data.length);
      next(null, data);
    },

    onend_response: function(req, res, data, next) {
      console.log('plugin-1: onend_response');
      next(null, data);
    }
  };
}

Ahora, considera crear dos complementos más, plugin-2 y plugin-3, con el mismo código (excepto que debes cambiar las instrucciones console.log() a plugin-2 y plugin-3, respectivamente).

2. Revisa el código del complemento

Las funciones de complementos exportadas en <microgateway-root-dir>/plugins/plugin-1/index.js son controladores de eventos que se ejecutan en momentos específicos durante el procesamiento de solicitudes y respuestas. Por ejemplo, onrequest se ejecuta cuando se recibe el primer byte de los encabezados de la solicitud. Mientras que onend_response se ejecuta después de que se recibe el último byte de datos de respuesta.

Echa un vistazo al controlador ondata_response: se llama cada vez que se recibe un fragmento de datos de respuesta. Lo importante que debes saber es que los datos de respuesta no necesariamente se reciben todos a la vez. En cambio, los datos se pueden recibir en fragmentos de longitud arbitraria.

3. Agrega los complementos a la secuencia de complementos.

Continuando con este ejemplo, agregaremos los complementos a la secuencia de complementos en el archivo de configuración de Edge Microgateway (~./edgemicro/config.yaml) de la siguiente manera. La secuencia es importante. Define el orden en que se ejecutan los controladores del complemento.

  plugins:
    dir: ../plugins
    sequence:
      - plugin-1
      - plugin-2
      - plugin-3

4. Examina el resultado de la depuración

Ahora, veamos el resultado que se produciría cuando se llamen a estos complementos. Estos son algunos puntos importantes que debes tener en cuenta:

La secuencia de complementos del archivo de configuración de Edge Microgateway (~./edgemicro/config.yaml) especifica el orden en el que se llaman los controladores de eventos.
Los controladores de solicitudes se llaman en orden ascendente (el orden en el que aparecen en la secuencia de complementos: 1, 2, 3).
Los controladores de respuesta se llaman en orden descendente: 3, 2 y 1.
Se llama al controlador ondata_response una vez por cada fragmento de datos que llega. En este ejemplo (el resultado se muestra a continuación), se reciben dos fragmentos.

Este es un ejemplo de la salida de depuración que se produce cuando se usan estos tres complementos y se envía una solicitud a través de Edge Microgateway. Solo observa el orden en el que se llama a los controladores:

  plugin-1: onrequest
  plugin-2: onrequest
  plugin-3: onrequest

  plugin-1: onend_request
  plugin-2: onend_request
  plugin-3: onend_request

  plugin-3: ondata_response 931
  plugin-2: ondata_response 931
  plugin-1: ondata_response 931

  plugin-3: ondata_response 1808
  plugin-3: onend_response

  plugin-2: ondata_response 1808
  plugin-2: onend_response

  plugin-1: ondata_response 1808
  plugin-1: onend_response

Resumen

Comprender el orden en el que se llaman los controladores de complementos es muy importante cuando intentas implementar funciones de complementos personalizadas, como acumular y transformar datos de solicitudes o respuestas.

Solo recuerda que los controladores de solicitudes se ejecutan en el orden en que se especifican los complementos en el archivo de configuración de Edge Microgateway, y los controladores de respuestas se ejecutan en el orden opuesto.

Acerca del uso de variables globales en complementos

Cada solicitud a Edge Microgateway se envía a la misma instancia de un complemento; por lo tanto, el estado de una segunda solicitud de otro cliente anulará el primero. El único lugar seguro para guardar el estado del complemento es almacenarlo en una propiedad del objeto de solicitud o respuesta (cuya vida útil se limita a la de la solicitud).

Cómo reescribir URLs de destino en complementos

Se agregó en la versión 2.3.3

Puedes anular la URL de destino predeterminada en un complemento de forma dinámica modificando estas variables en el código del complemento: req.targetHostname y req.targetPath.

Se agregó en la versión 2.4.x

También puedes anular el puerto del extremo de destino y elegir entre HTTP y HTTPS. Modifica estas variables en el código de tu complemento: req.targetPort y req.targetSecure. Para elegir HTTPS, configura req.targetSecure como verdadero; para HTTP, configúralo como falso. Si configuras req.targetSecure como verdadero, consulta este hilo de discusión para obtener más información.

Se quitó en la versión 3.3.3

El complemento de muestra llamado eurekaclient se quitó de Edge Microgateway en la versión 3.3.3. Consulta las notas de la versión.

La eliminación de esta función no afecta la funcionalidad principal de Edge Microgateway ni la reescritura de URLs de destino. Puedes configurar la búsqueda dinámica de extremos y anular variables de destino como req.targetHostname, req.targetPath, req.targetPort y req.targetSecure a nivel del complemento. Consulta Cómo reescribir URLs de destino en complementos.

Complementos de ejemplo

Estos complementos se proporcionan con la instalación de Edge Microgateway. Puedes encontrarlos en la instalación de Edge Microgateway aquí:

[prefix]/lib/node_modules/edgemicro/plugins

donde [prefix] es el directorio de prefijo npm, como se describe en "¿Dónde se instala Edge Microgateway?" en Instalación de Edge Microgateway.

accumulate-request

Este complemento acumula fragmentos de datos del cliente en una propiedad de array adjunta al objeto de solicitud. Cuando se reciben todos los datos de la solicitud, el array se concatena en un búfer que luego se pasa al siguiente complemento de la secuencia. Este complemento debe ser el primero de la secuencia para que los complementos posteriores reciban los datos de la solicitud acumulados.

module.exports.init = function(config, logger, stats) {

  function accumulate(req, data) {

    if (!req._chunks) req._chunks = [];
    req._chunks.push(data);

  }

  return {

    ondata_request: function(req, res, data, next) {

      if (data && data.length > 0) accumulate(req, data);

      next(null, null);

    },


    onend_request: function(req, res, data, next) {

      if (data && data.length > 0) accumulate(req, data);

      var content = null;

      if (req._chunks && req._chunks.length) {

        content = Buffer.concat(req._chunks);

      }

      delete req._chunks;

      next(null, content);

    }

  };

}

acumular-respuesta

Este complemento acumula fragmentos de datos del destino en una propiedad de array adjunta al objeto de respuesta. Cuando se reciben todos los datos de respuesta, el array se concatena en un búfer que luego se pasa al siguiente complemento de la secuencia. Dado que este complemento opera en las respuestas, que se procesan en orden inverso, debes colocarlo como el último complemento de la secuencia.

module.exports.init = function(config, logger, stats) {

  function accumulate(res, data) {
    if (!res._chunks) res._chunks = [];
    res._chunks.push(data);
  }

  return {

    ondata_response: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(res, data);
      next(null, null);
    },

    onend_response: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(res, data);
      var content = Buffer.concat(res._chunks);
      delete res._chunks;
      next(null, content);
    }

  };

}

Complemento header-uppercase

Las distribuciones de Edge Microgateway incluyen un complemento de muestra llamado <microgateway-root-dir>/plugins/header-uppercase. La muestra incluye comentarios que describen cada uno de los controladores de funciones. En este ejemplo, se realiza una transformación de datos simple de la respuesta de destino y se agregan encabezados personalizados a la solicitud del cliente y a la respuesta de destino.

Este es el código fuente de <microgateway-root-dir>/plugins/header-uppercase/index.js:

'use strict';

var debug = require('debug')('plugin:header-uppercase');

// required
module.exports.init = function(config, logger, stats) {

  var counter = 0;

  return {

    // indicates start of client request
    // request headers, url, query params, method should be available at this time
    // request processing stops (and a target request is not initiated) if
    // next is called with a truthy first argument (an instance of Error, for example)
    onrequest: function(req, res, next) {
      debug('plugin onrequest');
      req.headers['x-foo-request-id'] = counter++;
      req.headers['x-foo-request-start'] = Date.now();
      next();
    },

    // indicates start of target response
    // response headers and status code should be available at this time
    onresponse: function(req, res, next) {
      debug('plugin onresponse');
      res.setHeader('x-foo-response-id', req.headers['x-foo-request-id']);
      res.setHeader('x-foo-response-time', Date.now() - req.headers['x-foo-request-start']);
      next();
    },

    // chunk of request body data received from client
    // should return (potentially) transformed data for next plugin in chain
    // the returned value from the last plugin in the chain is written to the target
    ondata_request: function(req, res, data, next) {
      debug('plugin ondata_request ' + data.length);
      var transformed = data.toString().toUpperCase();
      next(null, transformed);
    },

    // chunk of response body data received from target
    // should return (potentially) transformed data for next plugin in chain
    // the returned value from the last plugin in the chain is written to the client
    ondata_response: function(req, res, data, next) {
      debug('plugin ondata_response ' + data.length);
      var transformed = data.toString().toUpperCase();
      next(null, transformed);
    },

    // indicates end of client request
    onend_request: function(req, res, data, next) {
      debug('plugin onend_request');
      next(null, data);
    },

    // indicates end of target response
    onend_response: function(req, res, data, next) {
      debug('plugin onend_response');
      next(null, data);
    },

    // error receiving client request
    onerror_request: function(req, res, err, next) {
      debug('plugin onerror_request ' + err);
      next();
    },

    // error receiving target response
    onerror_response: function(req, res, err, next) {
      debug('plugin onerror_response ' + err);
      next();
    },

    // indicates client connection closed
    onclose_request: function(req, res, next) {
      debug('plugin onclose_request');
      next();
    },

    // indicates target connection closed
    onclose_response: function(req, res, next) {
      debug('plugin onclose_response');
      next();
    }

  };

}

transform-uppercase

Este es un complemento de transformación general que puedes modificar para realizar cualquier tipo de transformación que desees. En este ejemplo, simplemente se transforman los datos de respuesta y solicitud a mayúsculas.

 */
module.exports.init = function(config, logger, stats) {

  // perform content transformation here
  // the result of the transformation must be another Buffer
  function transform(data) {
    return new Buffer(data.toString().toUpperCase());
  }

  return {

    ondata_response: function(req, res, data, next) {
      // transform each chunk as it is received
      next(null, data ? transform(data) : null);
    },

    onend_response: function(req, res, data, next) {
      // transform accumulated data, if any
      next(null, data ? transform(data) : null);
    },

    ondata_request: function(req, res, data, next) {
      // transform each chunk as it is received
      next(null, data ? transform(data) : null);
    },

    onend_request: function(req, res, data, next) {
      // transform accumulated data, if any
      next(null, data ? transform(data) : null);
    }

  };

}