Movilizer

Hace muchos años que no publicaba nada sobre programación, unos 5 años si paso por alto las publicaciones de Arduino o algún código sencillo que he publicado. Esto se ha debido principalmente por las tecnologías que uso donde trabajo, la gran mayoría de ellas propietarias por lo que tenía poco e incluso ningún sentido hablar de ellas.

Sin embargo, como necesito desempolvar el teclado he decidido hablar de ellas, aun sabiendo que la información que voy a publicar en esta y próximas entradas no le va a resultar útil a prácticamente nadie, pero como digo lo necesito para volver a coger practica escribiendo y grabando vídeos para el próximo este año.

Antes de empezar con el código quizás deba hablar un poco sobre de dónde vienen las tecnologías y las empresas que están detrás, no es mi fuerte este tema pero espero que se entienda algo para ponerse en situación.

Movilizer

El producto que utilizo a diario tiene el nombre de Movilizer, el cual permite movilizar los distintos procesos de las empresas, también llamado MEAP. Permite crear aplicaciones multi-plataforma (Android, iOS, Windows Mobile, Windows Phone, Windows Desktop, Linux, Blackberry, Web) abstrayendote casi por completo del sistema operativo y del hardware del dispositivo, de modo que programando una única vez tienes el programa en todas las plataformas.

Movilizer fue creado por la empresa Movilitas, después se dividió en las empresas Movilizer y Movilitas Consulting para separar lo que era el desarrollo del producto y lo que era su utilización, esta última fue comprada posteriormente por una empresa americana. Finalmente en 2016 la parte del producto fue comprada por Honeywell. (En realidad esto está bastante resumido, es aún más complejo/rollo)

La tecnología de Movilizer se divide en tres partes:

Cliente

La parte principal es el cliente de Movilizer que se programa para la plataforma en la que se desea utilizar y es ahí donde se ejecutan las aplicaciones. Es muy parecido a la máquina virtual de Java que se puede instalar en multitud de dispositivos y después permite ejecutar programas programados en Java.

En el caso de Movilizer las aplicaciones se diseñan con lenguaje XML y se les da dinamismo con el lenguaje de programación MEL (Movilizer Expression Language).

Nube

La nube almacena las aplicaciones creadas con XML/MEL para posteriormente ser descargadas al dispositivo, también almacena las credenciales de los usuarios necesarios para poder utilizar el cliente de Movilizer, y otro tipo de datos como Master Data o documentos.

Además centraliza todas las conexiones de entrada de los clientes hacia el backend para que este último solo tenga que abrir los puertos/acceso a la nube, esto puede parecer una tontería pero es algo por lo que todas las empresas preguntan como es lógico por temas de seguridad.

El panel web de la nube permite realizar muchísimas cosas más pero eso es lo mas destacable.

Backend

Por ultimo esta la programación en el servidor, en mi caso SAP, donde se instala el add-on de Movilizer que se encarga de muchas cosas, entre ellas te permite crear las aplicaciones directamente con lenguaje ABAP (sin necesidad de XML), gestionar todas las conexiones, usuarios, etc.

Esto mismo se podría hacer también importando el WSDL como clases Java, .Net, etc. a nuestro proyecto y crear las aplicaciones sin necesidad de hacerlo en XML, o hacerlo en XML/Velocity pera añadirle cierta lógica adicional mediante otro lenguaje de programación.

Movelet

Las aplicaciones creadas para Movilizer se hacen llamar Movelets. Cada Movelet debe tener una o varias pantallas llamadas Questions, y a su vez cada pantalla debe tener uno o varios campos llamados Answers. Con eso se puede crear la aplicación entera.

Question

Las Questions o pantallas disponibles son de un tipo concreto, según el tipo la pantalla tendrá una u otra interfaz. Hay de tipo mensaje, formulario, menú, lectura de escáner, lectura de RFID, Google Maps, HTML5, etc.

Link
Complex UI

Por defecto cada pantalla que se visualiza en el dispositivo está compuesta por una única question, sin embargo se pueden agrupar varias de ellas para darle más complejidad y mostrar más datos, por ejemplo juntando una pantalla de formulario con una de mapas y una botonera.

Answer

Las Answers son los campos que forman la pantalla, según el tipo de question/pantalla las answers/elementos podrán ser de un tipo u otro, para una pantalla de formulario podríamos tener campos de texto, numéricos, checkbox, desplegables, etc. para una pantalla de menú pues tendremos botones, para una de mapas habrá puntos de interés, rutas entre puntos, etc.

Cada Answer debe apuntar obligatoriamente a la siguiente question/pantalla o a END/CANCEL en caso de ser la última pantalla. Por tanto, si la Movelet/aplicación está compuesta de 3 questions/pantallas, sus answer/elementos de la pantalla 1 deberán apuntar a la 2 y los de la 2 a la 3… por norma general. Todo este flujo de navegación puede ser cambiado por menús y restricciones, pero digamos que para que «compile» no puede haber pantallas sin enlazar a excepción de la última.

 

Programación MEL

Para que las pantallas tengan alguna utilidad necesitamos algo para poder recuperar los valores de las pantallas, tratarlos, guardarlos, enviarlos al backend o a otras pantallas, etc. Todo eso se hace con el lenguaje de programación MEL, Movilizer Expression Language, parecido a Javascript en cuanto a sintaxis aunque con ciertas limitaciones.

El código MEL debe insertarse dentro de unas etiquetas del XML, en caso de diseñar las aplicaciones en XML de lo contrario deberá insertarse en el método adecuado. Hay multitud de etiquetas o bloques en las que se puede insertar el código, la diferencia está en el momento en el que ese código se ejecutara, hay bloques para insertar código que se ejecutara al arranar el cliente, o la movelet/aplicación, o una question/pantalla concreta, o al salir de la question/pantalla, etc.

Link

Según ha ido avanzando el producto se ha ido mejorando unas u otras cosas, en la versión 2.6 por fin han dedicado tiempo al aspecto y se han incluido multitud de atributos para personalizar la interfaz de las Movelets/aplicaciones.

Mostraron las novedades hace poco mediante un artículo en la documentación y veo que el vídeo está en Youtube así que eso parece que voy a poder insertarlo aquí:

Backend

Programación MAF

Aunque lo típico seria elegir nuestro propio backend en nuestro servidor ya sea SAP o uno programado en Java, .Net, etc. recientemente se está haciendo mucho hincapié en MAF, Movilizer Application Framework, que se corresponde con el lenguaje de programación que se puede aplicar en la nube para realizar ciertas tareas sin necesidad de otro backend o como apoyo a este.

En realidad en esta ocasión no se han inventado un lenguaje como con MEL… si no que todo se programa en Groovy, que es el lenguaje de scripting de Java. Desde ahí se pueden interceptar tres de los cinco tipos de comunicación (Offline Replies, Offline Sync, Online Sync, Direct Offline Sync, Direct Online Sync) que habría normalmente entre frontend y backend.

Una vez con esos datos es posible tratarlos y si se trata de una comunicación síncrona devolver una respuesta. A la hora de tratarlos se podrían guardar como Master Data, como documento, como evento EPCIS, enviarlos por correo, o dejar que sigan hacia el backend. En realidad seguramente se puedan hacer más cosas pero el desarrollo de MAF está en pañales por lo que hay poca documentación publicada disponible, y todo se obtiene boca a boca… para darle más emoción a la vida…

SAP

Movilizer dispone de un conector instalable en SAP que se encarga de todo: programación de Movelets desde ABAP, envió de Movelets, monitorización, captura de eventos estándar de SAP (creación/edición de avisos y ordenes de mantenimiento, etc.), gestión de conexiones, etc.

Veremos sus posibilidades en profundidad en próximas entradas.

Escriba aquí su comentario