Decía en una entrada anterior que el formador pasó por el procesamiento por lotes de puntillas, en plan «existe, pero es terriblemente complicado». Me he leído varias veces la documentación al respecto y sigo sin entender cómo montar el payload de una petición de procesamiento por lotes.

Pero con el cliente OData es otro cantar. Es tan simple como esto:

For Each Documento In Documentos
    oDocumentoSAP = New Document
    Documento.RellenarDocumento(oDocumentoSAP)
    Context.AddDocument(oDocumentoSAP, Documento.DocType)
Next
Dim responses = Await Context.SaveChangesAsync(options:=SaveChangesOptions.BatchWithSingleChangeset)

Hay dos opciones a indicar en el SaveChanges:

• BatchWithIndependentOperations procesaría las operaciones de forma secuencial e independiente. Si se produce un error se para, pero todo lo que se haya creado o modificado antes queda hecho.
• BatchWithSingleChangeset mete todo en una única transacción, como ocurría en Di Server. Si falla uno, falla todo.

La limitación con respecto a Di Server es que allí podíamos incluir cierres y cancelaciones dentro del lote de operaciones y aquí, no, al no ser operaciones propias de OData sino funciones específicas.

Esta pequeña serie sobre scripts en Service Layer consta de tres partes:

Preparando el entorno
El script
Consumirlo desde .Net

La parte realmente difícil de todo el tema de los scripts ha sido combinarlo con el cliente OData. Confieso que, entre unas cosas y otras, se me fueron 50 horas de trabajo hasta conseguir algo funcional. La documentación de Microsoft de un tiempo a esta parte no es ninguna maravilla y con OData es especialmente parca. Intentar salirme de lo básico me ha dado muchos dolores de cabeza.

Resumiendo, que tampoco quiero aburrir, mi idea original era utilizar el context y las entidades ya creadas y hacer algo como:

Dim cosa As New BodyOperationParameter("Recibo", oRecibo)
Dim cosa2 As New BodyOperationParameter("Emision", oEmision)
Dim responses = context.Execute(url, "POST", {cosa, cosa2})

Sigue leyendo →

Esta pequeña serie sobre scripts en Service Layer consta de tres partes:

Preparando el entorno
El script
Consumirlo desde .Net

Como dije en la anterior entrada, mi primer script iba a ser de una operación sencilla: crear dos documentos, un recibo de producción y su emisión de componentes correspondiente, en una transacción.

Como siempre, nuestro punto de partida es el manual de Service Layer que tenemos en nuestro servidor (https://<miservidor>:50000/Working_with_SAP_Business_One_Service_Layer.pdf) y que también podemos consultar aquí. Todo el apartado 3.20 está dedicado a esto. El código de ejemplo que trae lo tenemos también en la carpeta de instalación de Service Layer y es un buen punto de partida.

Sigue leyendo →

Esta pequeña serie sobre scripts en Service Layer consta de tres partes:

Preparando el entorno
El script
Consumirlo desde .Net

Una vez montado el cliente OData de Service Layer, realizar las operaciones individuales que hasta ahora hacía por B1WS, como, no sé, hacer traslados, crear y modificar ofertas y pedidos, crear y modificar UDOs varios, ha sido sencillo. Otra cosa muy distinta son las operaciones complejas que encapsulo en una transacción por Di Server, algo que no permite B1WS.

En Service Layer tenemos dos opciones para atacar este problema: uno es el procesamiento por lotes. El formador que tuvimos para Service Layer ni lo tocó por lo complicado que es preparar la petición, pero podemos hacer casi lo mismo que en Di Server. La otra es a través de su propio SDK, que nos permite hacer una suerte de addons en JavaScript que, sin ser tan potentes como lo que podemos hacer por Di Api, es, en algunos aspectos, más potente que lo que nos ofrece Di Server.

Me he lanzado a probar este extraño mundo con una operación sencilla en mente, pero que en la empresa se hace con mucha frecuencia: un recibo de producción con su emisión de componentes correspondiente.

Sigue leyendo →

En las primeras pruebas con SAP Service Layer y su cliente OData para .Net me he encontrado con un problema que, por otra parte, me esperaba. Quiero decir que la actualización en OData se basa en enviar el conjunto de los cambios y no toda la entidad, para tener un flujo de datos lo más reducido posible. En Service Layer esto implica que si, por ejemplo, quiero actualizar un pedido de ventas, enviaré los campos de la cabecera que cambian, así como las líneas que se cambian o se añaden.

Pero, ¿y si lo que quiero es eliminar una línea? En Di Server/B1WS debíamos enviar todas las líneas, por lo que, si faltaba alguna, SAP entendía que la queríamos eliminar.

¿Es posible hacer eso en Service Layer?

Atendiendo al manual del usuario que tenemos en https://<miservidor>:50000/Working_with_SAP_Business_One_Service_Layer.pdf, no.

Sigue leyendo →

Después de meses de retrasos y problemas (que si falla la controladora RAID del nuevo servidor, que si hay que esperar a un parche de SAP que se retrasa, que si pruebas por aquí y por allá), en noviembre por fin actualizamos a SAP 10. De lo más interesante de esta versión es que por fin tenemos Service Layer en la versión para SQL Server (hasta entonces, estaba sólo para Hana).

Service Layer es una nueva api de datos para que nuestras aplicaciones puedan trabajar con SAP Business One. Es una api web moderna, Restful, con protocolo OData. Por supuesto, con algunas cosillas particulares, que para algo hablamos de SAP.

Yo esperaba con muchas ganas el poder meterle mano a Service Layer. El venerable Di Server se nos ha quedado pequeño y nos da mil y un extraños problemas. No cuento con que Service Layer sea la panacea, pero se supone que debe funcionar mejor que algo marcado como obsoleto años antes de que yo empezara a usarlo. El problema, como siempre, es la formación y la documentación. O la falta de. Como es habitual, me toca buscarme las habichuelas.

Sigue leyendo →

Hace poco tuve que modificar unos documentos de márketing (ofertas y pedidos de ventas) vía B1WS/Di Server. Hasta el momento, sólo había creado documentos de SAP y supuse que la edición seguiría el mismo proceso que con los UDO, con los que tengo bastante más manejo. Básicamente, el proceso con un UDO es:

• Obtengo el objeto sin modificar vía B1WS.
  
• Modifico los campos de la cabecera con los datos nuevos.
  
• Con el array de líneas, agrego las nuevas, elimino las que hay que borrar y modifico los campos de las que hay que modificar.
  
• Le vuelvo a enviar todo a SAP.
  

Con las líneas, que es lo que me importa aquí, el proceso es como éste, siendo Origen el objeto con los cambios que envía la capa de lógica de negocio y Destino, el objeto sin modificar recuperado de SAP. Como pueden observar, hay una propiedad en las filas origen que me indica qué debo hacer con ellas:

Sigue leyendo →