Bienvenido a la parte #5 de nuestro sorprendentemente blogpost y webinar ¡serie! En nuestra serie te ayudamos a analizar todas tus aplicaciones de Domino.
El título de la webinar para esto blogLa publicación fue "No termines en una zanja porque no estabas al tanto de los obstáculos en tu código fuente".
Esta vez compartimos por qué, qué y cómo se debe analizar en las aplicaciones de Domino.
Un prólogo para no desarrolladores
Si no eres desarrollador: la siguiente introducción puede ayudarte a comprender mejor el resto de esta publicación.
Cada base de datos de su entorno contiene elementos de diseño y código. Esto es para mostrar todos los documentos allí. Ya sea para crearlos, editarlos o leerlos.
Las vistas muestran sus documentos en formato de lista. Estos pueden ser ordenados y/o categorizados. Por ejemplo, por fecha, nombre de usuario o lo que se ajuste a la respectiva aplicación y vista.
Además de las vistas, vale la pena destacar dos elementos de diseño más. Estos lo ayudan a crear, editar o leer documentos en sus bases de datos:
- Acciones en vistas (generalmente disponibles a través de botones u opciones de menú en la parte superior de las vistas)
- y Formularios, así como campos en formularios
Una base de datos puede constar de muchos más tipos de elementos de diseño. Cada uno de ellos puede utilizar uno o varios de los siguientes lenguajes de programación:
@Fórmulas, LotusScript, JavaScript y Java.
Ese código nuevamente puede tener una variedad de interfaces y dependencias:
- otras bases de datos de Notes/Domino,
- otras aplicaciones, como Microsoft Excel o SAP,
- el sistema de archivos, ya sea en clientes o servidores,
- El sistema operativo,
- y muchas, muchas otras dependencias.
Una aplicación puede comprender una o varias bases de datos y estar disponible en uno o varios servidores. La replicación mantiene las mismas bases de datos sincronizadas entre servidores. Esto da como resultado un gran rendimiento, balanceo de carga y alta disponibilidad a través de geografías/redes.
Cuando busque optimizar, modernizar o migrar una aplicación, debe saber:
- qué tan compleja es una aplicación (piense en los tipos y la cantidad de elementos de diseño, así como en las líneas de código),
- lo que hace todo el código,
- y si será fácil trabajar con el código en su proyecto respectivo.
Entonces, comencemos con ¿Por qué?
La mayoría de los desarrolladores no desarrollaron todas las aplicaciones por sí mismos. Incluso si lo hicieran (¡capítulo!), lo más probable es que no haya sucedido “todo ayer”, sino durante un par de años. ¿Todavía recuerdas el código en todas tus aplicaciones lo suficientemente bien?
Además, algunas empresas ya ni siquiera tienen un desarrollador de Domino. Por no hablar de todos los que ayudaron a construir el panorama de aplicaciones actual a lo largo de los años.
A continuación, conocer el código fuente de una aplicación es excelente para ejecutarla/mantenerla en Domino tal como está.
Finalmente, desea encontrar todos los obstáculos, así como el código útil, si no en general, lo bueno, lo malo y lo feo.
Si desea optimizar, modernizar o migrar sus aplicaciones:
Considerándolo todo, ¿no sería genial si pudiera ahorrarse un tiempo valioso, frustraciones y trampas? Conociendo a las partes interesadas de sus aplicaciones, se vuelve mucho más poderoso cuando se combina con el análisis del diseño y el código de sus aplicaciones.
Una vez que conozca a sus partes interesadas, también sabrá:
- ¿Quién se verá afectado por los cambios que realice en una aplicación?
- ¿Cómo se verán afectados?
- ¿A quién debe consultar antes de comenzar a hacer cambios?
- ¿Quién está recibiendo el beneficio del trabajo que está haciendo?
Lo que nos lleva al Qué
Antes de sumergirnos en "¿Qué debe analizar su código", recuerde:
Hay muchos otros puntos de datos importantes a considerar antes de analizar el código:
- ¿Cuáles son sus aplicaciones más utilizadas y menos complejas?
Estos se pagan rápido. ¡Y no deberías perder el tiempo con aplicaciones que nadie usa! Para más detalles, consulte también esta página y esta página. - ¿Qué usuarios finales necesitan réplicas locales por motivos de rendimiento o uso sin conexión?
- ¿Qué aplicaciones utilizan sus VIP o sus centros de beneficio más importantes?
Estos son solo algunos ejemplos a tener en cuenta; se pueden encontrar más aquí (ver diapositivas 17-21).
Ahora, ¿qué código debe analizar y qué debe buscar en él?
Todo ello. Período. En *todas* sus aplicaciones. Y para cada uno de ellos, eso significa
- Todo el código: @Formulas, Java, JavaScript y LotusScript
- Todos los elementos de diseño (piense en "contenedores de código"). Estos pueden ser formularios, subformularios, vistas, columnas, acciones, agentes, botones, bibliotecas de scripts, etc.
- Los siguientes elementos de diseño a menudo merecen una atención especial:
XPages, Java Classes, Applets, archivos Jar, servicios web, funciones de aplicaciones compuestas y similares
Análisis adecuado de ambos elementos de diseño de la aplicación. y El código responde a dos preguntas esenciales:
- ¿Dónde vive todo tu código? ¿Cuánto es dónde? y que tipo de codigo es?
- ¿Qué hace ese código?
Los siguientes dos ejemplos muestran el valor de analizar tanto el diseño como el código:
a) Cuantos más formularios, campos y código tenga una aplicación, más tiempo llevará modernizarla o migrarla
b) Una aplicación que usa Java Code no es un candidato ideal para migrar a SharePoint. Sí, esto depende en parte de lo que haga el código correspondiente. Sin embargo, le ayuda a clasificar sus aplicaciones y prevent trampas.
LO QUE HACEMOS debes buscar en tu código
Buscar en el código puede ser cualquier cosa, desde divertido hasta frustrante.
Después exportar el diseño de sus aplicaciones a DXL (Lenguaje XML de Domino), aquí hay tres consejos para empezar:
- Inicie el bloc de notas o similar y explore el resultado. Para tener una primera idea, intente encontrar algo de su código buscando partes de él. Además, busque nombres de usuario, nombres de servidor y similares
- Pruebe LotusScript Manager o Source Sniffer de OpenNTF
(¡*no* use Lotus Analyzer! Tiene un diseño oculto y llama a casa) - Pro-Challenge: divida el código del DXL en documentos en una base de datos de Notes. Esto facilita la categorización, la búsqueda y el procesamiento posterior (para contar elementos de diseño, por ejemplo)
Si probó alguno de los anteriores, es posible que haya notado un par de deficiencias en el camino:
a) Sus búsquedas también coinciden con comentarios/observaciones en su código
b) Las búsquedas combinadas como @Db(Column OR Lookup) piden abordar primero el desafío anterior.
(= dividir el código en documentos de Notes/Domino o una base de datos SQL). Las búsquedas separadas conducen a resultados duplicados. Esto, a su vez, va en contra de su objetivo de revisar la menor cantidad de código posible.
c) Sus búsquedas también coinciden con el código que no estaba buscando. Por ejemplo:
- Si busca "Abrir", encontrará NotesDatabase[Object].Open y NotesStream[Object].Open
- La búsqueda de "@DbLookup" incluye búsquedas en la misma base de datos donde se encuentra el código. Sin embargo, es posible que solo desee realizar búsquedas en otras bases de datos externas. O bien, su resultado también incluye búsquedas que no son de Notes, como ODBC. Sin embargo, es posible que solo busque búsquedas de Notes.
entoncesAntes de continuar nuestra búsqueda, debemos optimizar el código
Para obtener buenos resultados de búsqueda, debemos eliminar todos y cada uno de los comentarios de todo el código. Sí, es bueno tener comentarios en su código para comprenderlo mejor más tarde. Pero sesgan nuestros resultados de búsqueda.
Las siguientes imágenes ilustran cómo un desarrollador puede comentar en LotusScript y @Formulas:
En @Fórmulas, los comentarios comienzan con REM, seguidos de cualquier cantidad de espacios en blanco (=espacios en blanco o tabuladores). Luego viene el comentario real entre comillas dobles o corchetes.
Ya hemos preparado lo anterior para que lo pruebes GRATIS
Todo este artículo lo ayuda a comprender y realizar su propio análisis de aplicaciones independiente. Sin embargo, es posible que desee ahorrarse un tiempo valioso y ponerse en marcha rápidamente. Todo lo que tienes que hacer es regístrese para nuestro juego listo para jugar iDNA Applications arenero. Tan pronto como se haya registrado, todo lo que necesita hacer es iniciar sesión y navegar a nuestro búsqueda de código instantánea lista para usar. De acuerdo, no muestra sus propias aplicaciones, pero le da una buena idea de cómo debería funcionar la búsqueda de código.
Para la prueba, use la búsqueda de texto usando "florian", "vogler", "servidor", "/acme", "/O=acme" y "workflow". Además, intente una búsqueda de expresión regular como “(?iw)@db(búsqueda|columna)”.
Ahora profundicemos en QUÉ buscar *en* todo el (diseño y) código de sus aplicaciones:
Si quieres optimizar
- Busque GetNthDocument: es más lento que GetFirst/GetNextDocument
- Busque nombres de servidor codificados, nombres de usuario, nombres de archivo de base de datos, direcciones IP, direcciones de correo electrónico, ID de réplica, etc.
- Busque el código antiguo (@V2If, @V3Username, @V4UserAccess, @UserPrivileges, @IfError)
- Independiente del código: encuentre sus bases de datos más utilizadas/populares y dele un poco de amor. ¡Hazlos más bonitos y modernos!
Si quieres modernizar
- Compruebe si una aplicación depende en gran medida de las clases de NotesUI*. Eso no funciona en los navegadores web y necesita algunas modificaciones.
Compruebe si hay código que no sea compatible con los navegadores. Sugerencia: busque en la ayuda de Designer "No puede usar esta función en aplicaciones web". - ¿Ya hay mucho código que sugiere compatibilidad con el navegador?
es decir, @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands, … - ¿Su aplicación/código depende de la impresión? Eso puede ser un desafío desde un navegador.
- Analice su código para ver si funciona en HCL Nomad
- ¿La aplicación depende de XPages, Java u ODBC? Esto no funciona en HCL Nomad.
- ¿La aplicación utiliza llamadas C-API? En caso afirmativo, ¿el código también funciona en iOS y Android?
- Independiente del código: encuentra tus bases de datos más usadas/populares y dales un poco de amor. ¡Hazlos más bonitos y modernos!
Si quieres migrar
- ¿Cuántos formularios, campos, vistas, etc. tiene una aplicación? No elija primero los más complejos.
- ¿Su aplicación depende de elementos de código o diseño que no funcionan bien en su plataforma de destino respectiva?
Por ejemplo: Java <> SharePoint, demasiadas carpetas <> SharePoint. C-API. Libreta de direcciones pública o privada, Correo (Enviar y) Encriptar. UseLSX, ODBC, DB2, DOS/cmd, OLE, archivos, directorios, MIME, enlaces de documentos, etc. - ¿Una aplicación depende de otras bases de datos?
Piense en @DbLookups que se conectan a otras bases de datos (sin usar, por ejemplo, "":"" como servidor: nombre de archivo, por ejemplo). Lo mismo ocurre con New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose], etc. - Independiente del código y la migración: dele un poco de amor a una de sus bases de datos sobrantes, hágala más bonita y moderna.
Finalmente, veamos CÓMO buscar mejor su código
En parte, ya explicamos por qué la búsqueda de código con solo (sub)cadenas no lo llevará demasiado lejos. Coincide demasiado o demasiado poco en demasiados casos. También analizamos por qué es necesario eliminar todos los comentarios antes de buscar su código.
Además, lo siguiente es muy, muy, muy importante al buscar código:
NO busque código pensando en cómo lo habría desarrollado. Piensa en términos más amplios y te sorprenderá bastante saber cómo codifican otras personas.
Entonces, ¿cuáles son mejores enfoques para buscar código que solo coincidencias de subcadenas?
Un índice de texto completo que admite comodines como "*" (asterisco) lo lleva un poco más lejos en el juego. Por ejemplo, al buscar „@dbcolumn* O @dblookup*“, pero carece de soporte para una negación precisa. La negación precisa de las partes del código es vital para, por ejemplo, encontrar solo @DbLookups que no apunten a la misma base de datos.
El siguiente @DbLookup busca datos de la misma base de datos en la que se ejecuta el código. Lo hace a través de "":"" como segundo parámetro:
El siguiente @DbLookup busca datos de la libreta de direcciones "local" (cliente o servidor, dependiendo de dónde se ejecute):
Buscar cualquier @DbLookup que busque datos de "names.nsf" es bastante fácil. Incluso con solo comodines: @dblookup(:“nombres.nsf“). Eso es hasta que te encuentras con un código como este:
Ahora, de repente, necesitamos buscar código en varias líneas; sí, hemos visto código como ese.
Donde empeora aún más es cuando las variables, por no hablar de las @funciones, entran en juego como parámetro:
El código anterior busca datos de la misma base de datos. La variable ht_filename es el resultado de @Subset(@DbName;-1). Esto nuevamente da como resultado el nombre de archivo de la base de datos en la que se ejecuta el código.
De manera similar, el siguiente ejemplo de código busca datos de la libreta de direcciones local:
La mejor solución para buscar código sería si uno pudiera analizar el código. Esto nos permitiría resolver el valor de ht_filename en los ejemplos anteriores. Sin embargo, no hemos encontrado una solución inteligente para esto.
Para lo que sí encontramos una solución inteligente es para buscar código con negación precisa:
Usamos expresiones regulares.
La siguiente expresión regular es un gran paso adelante. Nos permite buscar cualquier @DbLookup que no busque datos de la misma base de datos desde donde se ejecuta:
@dblookup([^;];(?!””(:””)?).*| @dblookup( | El corchete abierto debe escaparse en expresiones regulares, por lo tanto, \( |
| [^;]*; | seguido de "cualquier cosa menos un punto y coma" hasta el siguiente punto y coma. Buscar „.*;“ sería incorrecto ya que esa expresión sería codiciosa. Buscaría hasta el último punto y coma. |
| (?!””(:””)?) | A continuación, negar ““, seguido de otro opcional:““: el segundo parámetro puede ser ““ o ““:““ |
| .* | hasta el final de la línea |
Este ejemplo todavía requiere algunos ajustes para
- también admite cualquier cantidad de espacios en blanco prácticamente en todas partes,
- y atender situaciones en las que @dbname o @subset(@dbname;1):@subset(@dbname;-1) usan la misma base de datos
- y solo encuentre aquellos @DbLookups para los cuales la Clase es "" o "Notas" (sin distinción entre mayúsculas y minúsculas)
Como puntos de bonificación, es posible que también desee encontrar @dblookups utilizados en LotusScript Evaluates. A menudo, las comillas también deben escaparse.
La expresión regular que cumple con todos los requisitos anteriores (excepto el análisis de código) es... posiblemente lo más feo que verá hoy:
Podría seguir y seguir durante horas
Si superaste las cosas realmente espeluznantes de arriba: ¡me quito el sombrero ante ti! Eres un desarrollador de superhéroes y un sobreviviente de expresiones regulares.
La buena noticia para todos los lectores es: Nosotros en panagenda ya han hecho una buena parte del trabajo pesado. Y nos encanta compartir.
Si echas un vistazo a nuestro iDNA Applications arenero, Se encuentra más de 70 expresiones regulares listas para usar. Estos buscan más de 300 hallazgos de código diferentes. Puede usar todos esos patrones en su propia solución de búsqueda de código GRATIS.
Y en caso de que tenga una idea más inteligente que usar expresiones regulares o se le ocurran algunas expresiones regulares nuevas o mejoradas: háganoslo saber y, a su vez, compartiremos con el community.
En caso de que no tenga tiempo para construir su propio código solución de búsqueda:
Hay una serie de soluciones de terceros que pueden ayudar. Algunos de ellos están disponibles en OpenNTF. Algunas de ellas son soluciones comerciales como las nuestras. panagenda iDNA Applications.
Resumiendo hasta
El análisis adecuado de sus aplicaciones tiene tres objetivos principales:
- Ahorrando (mucho) tiempo, frustración y dinero
- Centrarse en las cosas correctas y estar informado
- Habilitación de la transformación exitosa de su entorno de Domino
Optimización, modernización o migración
- Hagas lo que hagas, no olvides darle un poco de cariño a al menos una de tus aplicaciones de Domino. Te lo devolverá. muchos ti
Siguiente en nuestra serie
Reporte de progreso. Son parte de cada proyecto y no son divertidos de producir. No es solo tu progreso lo que tienes que compartir. También debe proporcionar a los equipos de proyecto los datos que necesitan para hacer su trabajo. Es difícil de coordinar y nunca termina. ¡Pero los informes de progreso pueden ser su amigo cuando informa sobre el éxito!
Los proyectos de migración y modernización son enormemente costosos y de muy alto perfil. Desde el principio, muchos ojos estarán puestos en ti. Las expectativas serán altas. ¿Cómo puedes evitar que tu proyecto fracase? A veces no puedes. Algunos proyectos están condenados incluso antes de comenzar. Deberías saberlo antes de ir.
De aquí en adelante será una continua ampliación del círculo de aplicaciones en las que estamos trabajando. Cada paso será más costoso y una planificación prudente producirá beneficios cada vez mayores.
Sobre esta serie:
Muchas empresas de todo el mundo se han comprometido a HCL Notes/Domino* durante años. Conocen los muchos beneficios que se derivan de esa relación. Además, Notes/Domino se encuentra en el centro de sus procesos y de su funcionamiento. A pesar de todo esto, los responsables de la toma de decisiones de TI de todo el mundo están empezando a imaginar un futuro en el que Notes/Domino puede desempeñar un papel reducido o no desempeñar ningún papel.
*anteriormente IBM Notes/Domino
