De la Web 2.0 a la Web 3.0: La evolución del desarrollo web en la era digital

El desarrollo web ha evolucionado significativamente en las últimas décadas, pasando de ser un medio informativo a una plataforma interactiva. La web 2.0 permitió a los usuarios interactuar entre sí y compartir información, lo que llevó a un auge en el desarrollo de redes sociales y sitios web orientados a la comunidad. Sin embargo, con la llegada del web 3.0, se espera un cambio radical en la forma en que los usuarios interactúan con los sitios web y cómo estos últimos responden a las necesidades de sus usuarios.

La web 3.0, también conocida como la web semántica, está orientada a la inteligencia artificial y el aprendizaje automático, lo que permite a los usuarios obtener información personalizada y relevante en función de sus intereses y comportamiento en línea. Los sitios web del web 3.0 están diseñados para brindar experiencias más personalizadas y enfocadas en el usuario, lo que implica un mayor enfoque en la privacidad y la seguridad de los datos.

En este nuevo modelo de desarrollo web, los desarrolladores deben pensar en cómo pueden utilizar la inteligencia artificial para mejorar la experiencia del usuario y brindar servicios personalizados. Los sitios web deben estar diseñados para anticipar las necesidades de los usuarios y proporcionar soluciones intuitivas y eficientes. Por lo tanto, el desarrollo de software debe centrarse en la construcción de sistemas de inteligencia artificial capaces de comprender el lenguaje natural, la interpretación de datos y el procesamiento del lenguaje natural.

Además, el web 3.0 también se enfoca en la descentralización y la seguridad de los datos. La tecnología blockchain, por ejemplo, permite la creación de sistemas de almacenamiento de datos descentralizados, lo que significa que los datos no están almacenados en un solo servidor centralizado. Esto proporciona una mayor seguridad y privacidad de los datos para los usuarios, evitando el riesgo de pérdida o robo de información.

En conclusión, el desarrollo web ha evolucionado significativamente desde la web 2.0 hasta la web 3.0. Con el advenimiento de la inteligencia artificial y la tecnología blockchain, los desarrolladores de software deben enfocarse en construir sistemas que brinden experiencias personalizadas y seguras para los usuarios. Esto implica un mayor enfoque en la privacidad y seguridad de los datos, así como en la construcción de sistemas de inteligencia artificial capaces de comprender y procesar el lenguaje natural. El futuro del desarrollo web se enfoca en la creación de sitios web que anticipen las necesidades de los usuarios y brinden soluciones intuitivas y eficientes.

Como realizar trasportes en SAP PI

1. Ingrese a la url

https://<SERVIDOR>:<PUERTO>/dir/start/index.jsp

2. De las opciones que se visualizan seleccione la siguiente:

3. Enterprise Service Repository

2. Ingrese a la opción trasferir objetos de diseño

5. Una vez seleccionada la opción se abre el wizard de transporte de objetos; se da la opción de exportar utilizando el CTS o de realizar exportación vía archivos

6. Paso siguiente es seleccionar que deseamos exportar, se tienen 4 opciones.

la primera opción es todos los objetos de un componente de software, es la mas indicada para sobreescribir un objeto o para una creación de un nuevo objeto; las demás permiten realizar transportes de manera selectiva

7. Se procede a seleccionar la orden de transporte y se finaliza el proceso

Cual es la contraseña por defecto en Apache Tomcat?

Tomcat 7 and Tomcat 8

Los usuarios para Tomcat se encuentran definidos en el archivo – $TOMCAT_HOME/conf/tomcat-users.xml, sin embargo por defecto no estan habilitados, esto significa que no se puede utilizar ninguno para acceder a la pa´gina de administración del servidor Apache Tomcat.

Para habilitar el acceso a la página de administración de Apache Tomcat, se debe:

Adicionar el role manager-gui.

$TOMCAT_HOME/conf/tomcat-users.xml (Original)

<tomcat-users>

<!--

  <role rolename="tomcat"/>

  <role rolename="role1"/>

  <user username="tomcat" password="tomcat" roles="tomcat"/>

  <user username="both" password="tomcat" roles="tomcat,role1"/>

  <user username="role1" password="tomcat" roles="role1"/>

-->

</tomcat-users>

Copy

$TOMCAT_HOME/conf/tomcat-users.xml (Actualizado)

<tomcat-users>

<!--

  <role rolename="tomcat"/>

  <role rolename="role1"/>

  <user username="tomcat" password="tomcat" roles="tomcat"/>

  <user username="both" password="tomcat" roles="tomcat,role1"/>

  <user username="role1" password="tomcat" roles="role1"/>

-->

        <role rolename="manager-gui"/>

        <user username="admin" password="admin" roles="manager-gui"/>

</tomcat-users>

Copy

Una vez realice las modificaciones debe proceder a reiniciar Apache Tomcat y de esta manera podra acceder a la página de administración (http://localhost:8080/manager) con el usuario = “admin” y la contraseña = “admin”

Nota
Para mayores detalles por favor utilice la guía Tomcat Manager App HOW-TO

Como hacer Debug en los Mapeos en SAP PO

En algun momento de nuestra trayectoria como consultores en SAP PI, hemos construido Mapeos complejos y hemos tenido problemas con las pruebas durante el proceso de ejecucion, esto debido a que no siempre podemos contemplar las dependencias.

Una aproximaciòn para solucionar esta situaciòn implica la creaciòn dentro del message mapping de una funciòn personalizada que permita validar el còdigo en el mapeo adicionando mensajrìa en el log standar del sistema.





Còdigo Fuente
AbstractTrace importanttrace;
importanttrace = container.getTrace(); 
importanttrace.addDebugMessage(traceMessage + " " + traceContext + inputValue + " ");
 
return inputValue;

Esta funciòn debe insertarse dentro de su Mapeo, en el punto en el cual se desee revisar un valor especifico; una ve haya insertado la funcion, haga doble click en ella y diligencie los valores trace message and the trace context. El valor recibido serà escrito en el trace pero este pasarà a traves de la funciòn sin sufrir modificaciòn alguna.








Versiòn original en http://shoosthuizen-integration.blogspot.com/

Limpiar el cache en PI 7.1

Para limpiar el cache en SAP PI 7.1, se debe utilizar lo siguiente:

http://host:50000/CPACache/refresh?mode=full

1. Se debe proceder a loguearse en el sistema

2. Se procede a ejecutar el proceso de limpiar el cache

3. Una vez se ha finalizado el proceso, se visualiza el siguiente mensaje

SAP FI - Curiosidades de la tabla BSEG

La tabla BSEG al igual que la transacción SPRO, son el pan de cada día para muchos consultores SAP, haciéndolas en muchas ocasiones que sea imposible que pasen desapercibidas.

El origen de la tabla BSEG se remonta a las primeras versiones de SAP, lo que se refleja en el diseño de la misma, aunque considerando que en las décadas de los 70 y 80, en las cuales el principal foco de las estrategias de diseño se encontraban en el rendimiento y optimización de los recursos de hardware.
SAP decide entonces orientar su desarrollo hasta una arquitectura universal de sistemas operativos y bases de datos, por lo que se hacia necesario implementar una capa de abstracción que sirviese de interprete entre las funciones de alto nivel y los diferentes entornos de ejecución.

¿Pero y donde entra la tabla BSEG?

Justamente considerando la decisión de soportar varias bases de datos, tales como: Oracle, MSSQL, SAPdb, Sybase, Informix, DB2, etc. Se tiene como resultado encontrar restricciones de diseño en todos lados, relacionadas especialmente con funcionalidades que no son estándar, esto es que solo unos cuantos RDBMS hacen y otros no.La tabla BSEG sirve esencialmente a un propósito funcional muy importante, esto es permitir la persistencia de los documentos de contabilidad, conteniendo todos los datos necesarios para las integraciones con los módulos de CO, MM, FI-AA, SD, etc. Es por esto que se plantea  que la tabla deberá contener muchos campos, lo que se traduce en un conflicto con la capa de abstracción, frente a lo que se presenta una pequeña "solución", esto es diseñar la tabla BSEG como un cluster, es decir, la estructura de la tabla lógica es diferente de la tabla física en la base de datos.BSEG: Tabla Cluster,
RFBLG: Tabla POOL.

Tabla RFBLG

Então os dados da Tabela BSEG é armazenada em formato RAW, ou seja, concatenam-se todos os bytes de dados de cada campo em uma só "linguiça" e fatia-se em tamanhos de 3800 bytes.

Por isto não se acostuma-se utilizar "select's" na tabela BSEG, pois se é necessário filtrar por um simples campo de conta contábil, o SAP irá solicitar todos os registros do banco e verificar para cada registro a equivalência de bytes posicionais de cada registro com a conta contábil.

Só é permitido o uso através do uso de leitura da tabela pela sua chave primária.

La nota 1892354 permite transformar la tabla BSEG desde una tabla cluster a una tabla.

 

De tal manera que desde este punto  se genera una nueva lista de programas, integraciones, Jobs, exits, etcs... que no requerirán acceder a las tablas auxiliares BSIS, BSAS, BSAD, BSID, BSAK, BSIK.

 

1)  En la tabla BSEG para todas las bases de daros el tamaño de registro corresponde a un registro de la tabla  RFBLG, por lo que no necesita leer dos o más registros para conformar un registro de la tabla BSEG.

 

2) La transferencia de datos entre RFBLG y BSEG se realiza directamente en el direccionamiento de memoria, no existe la necesidad de conversión.

 

3) Debido a la existencia de tablas de índice, la mayor parte del tratamiento de los datos de lectura y la actualización se lleva a cabo a través de estas tablas y la tabla BSEG no se consulta.

 

4) La ganancia en el procesamiento de inserción en la base de datos es insignificante y distribuido en toda transacción comercial. Debido a esto, probablemente se presentan los retrasos en la actualización de la BSEG.

 

Para aplicaciones, transacciones, informes de código de cliente, se abre toda una nueva gama de aplicaciones.

1) Permite realizar consultas en la tabla BSEG haciendo uso de campos diferentes a la clave primaria.

2) Permite la creación de índices para optimizar las consultas.

3) Permite la creación de vistas Trasparentes con otras tablas.

4) Permite el uso de la tabla BSEG haciendo uso de Queries para atender soluciones puntuales e inmediatas.

 

Versión original del artículo

Verificación de Carga de Extractos Electronicos en SAP

Utilizando la transacción FF67 se visualiza el estado del proceso de carga del extracto

Busco con los últimos 4 dígitos de la cuenta bancaria

Paso siguiente es utilizar la transacción FEBA, para visualizar las partidas que quedaron compensadas y las que no, así.

Se ejecuta

Se señala en otra representación y se abre el detalle, los registros marcados con color verde se encuentran compensados,  los marcados con rojo quedan en estado pendiente,