Durante la fase de registro, se presenta al intermediario un nodo de entrada definido por el usuario escrito en Java. El nodo se registra con el intermediario a través del método getNodeName estático. Cuando se inicia un intermediario, carga todas las clases Java relevantes. Llegado este punto se llama al método estático getNodeName, y el intermediario registra el nodo de entrada con el nombre de nodo especificado en el método getNodeName. Si no especifica un nombre de nodo, el intermediario crea automáticamente un nombre para el nodo basado en el paquete en el que está contenido.
Si se utiliza un método estático el intermediario puede llamar al método antes de que se cree una instancia del propio nodo.
Se crea una instancia del nodo de entrada definido por el usuario cuando un intermediario despliega un flujo de mensajes que contiene el nodo de entrada definido por el usuario. Cuando se crea la instancia del nodo, se llama al constructor de la clase del nodo de entrada.
Cuando se crea una instancia del nodo, se crea cualquier terminal que haya especificado. Un nodo de proceso de mensajes puede tener asociados cualquier número de terminales de entrada o salida. Debe incluir los métodos createInputTerminal y createOutputTerminal en el constructor del nodo para declarar estos terminales.
Si desea manejar las excepciones que se devuelven al nodo de entrada, debe utilizar createOutputTerminal para crear un terminal de captación para el nodo de entrada. Cuando el nodo de entrada capta un error, el terminal de captación lo procesará del mismo modo que lo haría un nodo MQInput regular. Puede permitir que la mayor parte de la excepciones como, por ejemplo, las excepciones ocasionadas por problemas de despliegue, se devuelvan al intermediario, quien avisará al usuario de cualquier error de configuración posible.
Como mínimo, la clase del constructor sólo necesita crear estos terminales de salida en el nodo de entrada. No obstante, si tiene que inicializar los valores de los atributos como, por ejemplo, definir el analizador que analizará inicialmente un mensaje pasado desde el nodo de entrada, también debe incluir en este momento el código del nodo de entrada.
El proceso de mensajes para un nodo de entrada comienza cuando el intermediario llama al método run. El método run crea el mensaje de entrada y debe contener la función de proceso para el nodo de entrada.
El método run se define en MbInputNodeInterface, que es la interfaz que se utiliza en un nodo de entrada definido por el usuario que lo define como un nodo de entrada. Debe incluir un método run en el nodo. Si no incluye un método run en el nodo de entrada definido por el usuario, entonces el código del fuente del nodo no se compilará.
Cuando se despliega correctamente un flujo de mensajes que contiene un nodo de entrada definido por el usuario, el intermediario llama al método de implementación de run que contiene el nodo y continúa llamando a este método mientras espera a que se procesen los mensajes.
Cuando se inicia un flujo de mensajes, el intermediario despacha una sola hebra, y se llama a la misma en el método run del nodo de entrada. Si se llama al método dispatchThread(), pueden crearse también hebras adicionales en el mismo método run. Estas nuevas hebras llaman inmediatamente al método run del nodo de entrada y se pueden tratar del mismo modo que la hebra original. El número de hebras nuevas que puede crearse se define mediante la propiedad additionalInstances. El modelo recomendado es asegurarse de que las hebras se despachen después de que se haya creado un mensaje y antes de que se propague. Esto garantiza que solamente una hebra cada vez esté a la espera del nuevo mensaje.
El nodo definido por el usuario puede elegir un modelo distinto de trabajo con hebras y es el responsable de implementar el modelo elegido. Si el nodo de entrada soporta la propiedad additionalInstances, y se llama a dispatchThread(), el código y cualquier función invocada por el nodo, deben poder ser utilizados en las diversas tareas. Si el nodo de entrada fuerza un solo trabajo con hebras, no llama a dispatchThread(), debe indicársele claramente al usuario de ese nodo que el establecimiento de la propiedad additionalInstances no tendrá ningún efecto en el nodo de entrada.
Para obtener información acerca del modelo de hebras para los nodos de entrada definidos por el usuario, consulte Trabajo con hebras.
Un nodo de entrada definido por el usuario escrito en Java se destruye cuando se suprime el nodo o cuando el intermediario concluye. No es necesario que incluya nada en el código que especifique que el nodo debe suprimirse físicamente, debido a que esto lo puede manejar el colector de basura.
No obstante, si desea que se notifique que está a punto de suprimirse un nodo, puede utilizar el método onDelete. Es posible que desee hacerlo si desea suprimir recursos distintos a los que recogerá el colector de basura. Por ejemplo, si tiene un socket abierto, no se cerrará correctamente cuando se suprima automáticamente el nodo. Puede incluir esta instrucción en el método onDelete para asegurarse de que el socket está correctamente cerrado.