cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction Notification

Former Member
0 Kudos

Hola a todos,

A proposito de un post de Humberto Neira, me entro la curiosidad de que estan haciendo con el stored procedure SBO_SP_TransactionNotification.

En lineas generales yo veo que desde que nosotros nos enteramos de su existencia, las implementaciones han mejorado notablemente, sobre todo al poder dar la posibilidad de poder agregar validaciones.

Por ejemplo, un tema que antes era un dolor de cabeza era que en Peru, las cuentas de gastos necesariamente requieren de un centro de costos asociado. Sin validacion debia correr una consulta a fin de mes para ver cuales asientos no tienen centro de costos, el resultado podia ser realmente grande y corregirlo podia traer mas de un dolor de cabeza. Obviamente existia la posibilidad de crear un add-on (aun considerando que las maquinas fueran tan super potentes como para aguantar un add-on adicional al de localizacion), pero hacer obligatorio un campo con el UI-API no es suficiente.

¿Que pasa si se quiere validar lo que se ingrese con el DI-API, por ejemplo DTW, programas externos, DI-Server (Ok, si quieren que sea mas estricto es el Observer dll)? Sin TN lo unico que nos queda es asegurarnos que el programa que usemos lo haga correctamente.

¿Que pasa si lo que queremos validar recien lo podemos hacer despues que ya se tienen todos los datos en el sistema? ¿De que nos serviria consultar la pantalla con el UI-API?

¿Se dan cuenta que tan inconveniente puede ser tener que validar en todos y cada uno de estos puntos? Pero con el TN nos podemos asegurar que en todas las entradas que se hagan a SBO sean validadas y hasta con el mensaje de error que le querramos poner! Que gran mejora!

Eso hasta que salio la version 2007 que o bien no valida (ver DTW: dice que todo esta OK, pero hizo rollback y si lo corres por segunda vez ni siquiera entra al TN) o bien aparece un mensaje de error totalmente inconsistente ("invalid index"). Este error lo reporte en agosto o setiembre del 2007, y van tres veces que me dicen que el tema ya esta solucionado y nada. Esto realmente ha sido muy malo para nosotros como implementadores y para SBO como producto. Aca solo espero no encontrar una respuesta como "te dijimos que no lo usaras para validar".

Problemas aparte, quisiera saber que opinan sobre el asunto. Esto no es tanto una pregunta, sino quisiera que sea un punto abierto a que todos los de habla hispana (este tema creo que ha sido bastante discutido en el foro en ingles) donde compartamos un espacio donde poner sus ideas acerca de este ilustre stored procedure.

Saludos,

Ian

Accepted Solutions (0)

Answers (1)

Answers (1)

Humberto_Neira
Product and Topic Expert
Product and Topic Expert
0 Kudos

Ian y aquellos interesados en esta Herramienta,

El tema con este Store Procedure es relevante y desde mi punto de vista los mayores cuidados son:

(a) No abusar de la herramienta.

(b) Tener claro que esta herramienta nace para permitir capturar los datos que van a la Base de datos y ser capaces de enviarlos a otra BD, otro txt, etc; tal que ayude a la integración. revisar la documentación del B1i para entender como aparece este store procedure.

(c) Tengan presente esto, pues la herramienta no nace para cortar flujos mediante validaciones, sino que para agregar pasos a operaciones que hace B1. Tener cuidado con cortar TRANSACCIONES mediante el SP.

(d) Considerar bajar la carga de trabajo de este store procedure en ambientes muy intensos (mucho usuario; mucha transacción), pues en vez de ayudar es muy probable que estés provocando LENTITUD en el sistema cada vez que CREAS una nueva transacción o cada vez que ACTUALIZAS un documento.

Finalmente, es importante como consultores Business One, ser capaces de dicernir de las validaciones ESENCIALES de aquellas que no lo son, pues el implementar TODO lo que se quiera validar por el usuario final, usando este mecanismo es un camino que si o si te llevará a problemas más graves:

-. problemas graves de performance, que no son causados por el producto sino por tanta validación.

-. problema de datos ante algún error en la lógica de decisiones dentro de este store procedure. Recordar que la data no se puede manipular por SQL una vez que ya queda en la Base de datos.

y este camino, que les traerá muchos problemas con los usuarios, finalmente los llevará a tener que sentarse a analizar que validación se puede desactivar, lo que finalmente se debió haber hecho desde el principio.

Es importante que aqui el CRITERIO sea lo que valga.!!.

saludos

Former Member
0 Kudos

Hola Humberto,

Me parece importante lo que dices y justamente a este nivel de comentarios queria llegar con este thread. Te doy mis comentarios sobre los puntos que tu mencionas:

(a) Es claro.

(b) B1i 2007 ya no usa el stored procedure para notificar transacciones. Ahora lo hace escribiendo directamente en tablas del SBO-COMMON. Si considero que uno de los objetivos del transaction notification es justamente ese, notificar y asi lo hemos hecho en varias ocasiones.

(c) No entiendo para que entonces permitieron desde un principio hacer rollbacks desde la herramienta si la intencion no era esa! Hasta ahora no he tenido ningun problema de transacciones inconsistentes debido al uso del SP y ya llevo algun tiempo usandolo. Podrias explicarte un poco mas cuando hablas de transacciones?

(d) Aparte de bastantes optimizaciones de codigo, lo que hemos hecho es separar por objetos de negocio las llamadas. El criterio aca hace la diferencia entre el buen uso y el abuso. La performance fue para nosotros prioridad uno al hacer uso de este SP.

Te doy toda la razon cuando dices que el criterio debe mandar, sobre todo en este punto, pero creo tambien que existe una linea muy delgada entre lo que es obligatorio validar y lo esperamos que el usuario haga sin errores.

Saludos,

Ian

Humberto_Neira
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hola,

A ver si ayudo a aclarar la historia, y ojo que yo tampoco conozco bien el origen de este SP pero te doy mi visión:

-. Me parece que esta herramienta tuvo un origen para ser usada del modo A pero luego de que se supo de su existencia y su potencial comenzo a tener un uso B. Dado esto, es que a mi entender el que se abuse de esta herramienta podría dejar a la luz los límites de este SP_, pues me parece que no fue armado para la intensidad, que muchas validaciones podrían darle.

Cuando me refiero a transacciones, estoy pensando en clientes muy intensos en CREACION DE DOCUMENTOS, sean de compras, ventas, inventario, etc. Sobre todo cuando esta métrica la cruzas con el hecho de que es un cliente con muchos usuarios.

Finalmente, creo que es importante darles la alternativas existentes para el mismo problema:

PUERTA A: SP Transaction notification

PUERTA B: Desarrollos SDK adhoc.

PUERTA C: Existe un addon B1UP que permite definir validaciones de usuario a nivel UI. (Boyum IT http://www.b1up.net )

PUERTA 😧 mejorar capacitaciones, proponer opciones al cliente para evitar tanta validación.

Mejor opción para cada caso, lo dejo a revisión caso a caso, pero es importante abrirse a otros caminos sobre todo en casos más complejos.

Finalmente recordar siempre, que cualquier cosa que puedan resolver desde la implementación, siempre es importante pedir a DESARROLLO para que sea incluída en algún momento en alguna versión de B1 en el futuro. No te digo que todo se vaya o se pueda hacer, pero al menos es importante que quede el registro de petición.

Recordar que en el foro en inglés, existe un tópico de PRODUCT COLLABORATION.

saludos

Former Member
0 Kudos

Estimados,

En la mayoria de las empresa que he visto se ha cambiado un sistema computacional bien basico por SAP BO, que exige que el ingreso de datos se haga bien a la primera, ya que corregir una factura requiere de una nota de credito y vuelta ingresar la factura. tambien la mayoria de los usuarios no estan acostumbrados a un sistema como Sap Bo, como una manera de enseñar a ingresar bien cada dato estoy usando este procedimiento almacenado (por solicitud del cliente) y ha dado excelentes resultados, cada vez se cometen menos errores.

Att,

Manuel Lazcano

Exxis

Chile

Former Member
0 Kudos

Hola Manuel,

Exactamente a eso me refiero. La solucion del TN no es mala, para nada. El tema es por que tiene tanta resistencia a usar por parte de SAP? No lo digo por los comentarios de Humberto sino en general por lo que he leido en el foro en ingles.

Alguien mas??

Saludos,

Ian