Available versions:
English
Spanish

---

English Version

The easy way to SDK: The 8 SDK programmer principles

Programming, as in religion, needs some kind of faith compromises that lay the foundations of the developments that we do day after day. Some of these principles help us create more robust applications, other give us the limits for the “sins” in our developer lives.

Before and during the development of any SAP Business One Application I have found that there are 8 basic principles that have to be on every developer mind in order to get the best of the SDK and achieve the goals for any Add-On.

Luckily, the SDK religion is not a dogmatic one so each of the principles that are going to be exposed, more than absolute rules, are a conceptual framework for those who are planning to develop for SAP Business One.

The 8 Principles of the SDK programmer
Principle 1:	Exploit the SDK to its maximum
Principle 2: .	Exploit your programming language to its maximum
Principle3:	Windows is my domain.
Principle 4:	SAP Business one is home.
Principle 5:	What happens in my world is my responsibility
Principle 6:	The others are important
Principle 7:	SAP Business One is multiuser
Principle 8:	Never forget the other 7 principles

 

Principle 1: Exploit the SDK to its maximum (Top)
The SDK is a very powerful tool and as such it has many unknown options that give the power to do virtually every operation that SAP Business One has. For this reason it must be treated as a living organism that evolves and that must be constantly analyzed as deep as possible.Each of the objects, methods, services and properties are there for a reason and we must be very attentive of their evolution (and as far as possible predict where things are going). We must know how they work as a single system and not look at them as isolated options in a non connected world.<span>If there is an SDK way to do things, this is always the preferable way even though is some occasions seems there is a shorter path to reach your goal.</span>

Principle 2: Exploit your programming language to its maximum. (Top)
Even though the first principle is very important we must never forget that the SDK is used inside a programming language that in most cases has advanced features that can be used.

Concepts like reflection, garbage collector and SOA for example, complement SDK programming and should be on every programmer mind when developing an Add-On for SAP Business One. To use the features options to their peak is an effective way to power up the developments that use SDK.

Principle 3: Windows is my domain.(Top)
Something that must never be forgotten is that SAP Business One is a Windows application. If we have that constantly in mind we would never forget that the operating system can be used in our favor. You can create Windows services, use the registry, make use of the operating system options or even reuse already available features that in another way must be developed from the beginning.Never the less we should never forget the other side of the coin.

Because of this we are also inheriting all the problems of the operating system and of the others applications that are running. As a Windows application we are not the only application that is fighting for resources or exclusives access that sometimes we take for granted.

Principle 4: SAP Business one is home.(Top)
If Windows is our domain, SAP Business One is home so any operation that is done that could unbalance it will affect the application. The database structure, ignoring the internal logic or any other operation that goes against the application must be avoided at all costs.

There will be a day when you as a programmer will feel confident of the internal functionality of the system and you will know it to the point that you will think that you know perfectly the internal logic. When this day arrives, you must avoid at all costs resist the temptation of programming based on this knowledge.

Principle 5: What happens in my world is my responsibility.(Top)
Every Add-On has the total responsibility of the things that happens within them. No matter how simple a function seems, you must never forget to capture the exceptions that rise at the application, Windows or SAP Business One levels.

Every created or used function must be aware of the errors that can occur and the Add-On must be in the capacity to react to them. Expect the unexpected is impossible, but trying to predict the results is a reality that programmers must have in mind in each line of code they write.

Principle 6: The others are important.(Top)
A lot of times when we are programming for SAP Business One we forget that there can be other Add-Ons that can change the way we interact with the system. You should never take for granted that you will have a standard system and the fifth principle must be applied each time you interact with a form, button or option in SAP Business One.

Maybe the field you depend on in your Add-On will not be there when you need it.

Principle 7: SAP Business One is multiuser.(Top)
When you are designing an Add-On for SAP Business One you should never forget that the system is multiuser. This can be sound obvious, but a lot of times is a north we don’t have in mind during the Add-On design face.For this reason is important to understand how the standard system reacts (with other Add-Ons too!) before the Add-On that is being developed goes to production, so that it’s also design adequate for a multiuser environment.

Principle 8: Never forget the other 7 principles.(Top)
Every time you finish a part of your functionality can be very helpful to reread the code with the other 7 principles in mind to verify their compliant. A validation of the sort can show a better functionality, give the principles of a faster application or find a bug.

I believe that having in mind these principles can help develop stronger and better Add-Ons that interact in a more harmonic and natural way with the system. I am also sure that there are many more that could help maintain the order of the SAP Business One universe. But hey, as we said in the beginning: this is a non dogmatic religion.

---

Spanish Version

The easy way to SDK: Los 8 principios del programador SDK

La programación, como la religión, implica compromisos de fe que fundamentan los desarrollos que hacemos día a día. Algunos de estos principios nos ayudan a crear aplicaciones robustas, otros nos restringen para no cometer “pecados” dentro de la vida del desarrollo.

Antes de comenzar y durante el desarrollo de cualquier aplicación para SAP Business One he encontrado que existen 8 principios que se deben tener en cuenta para sacar un mejor provecho y lograr las metas que se plantean como retos para un Add-On.

Por fortuna, la religión del SDK no es dogmatica por lo que cada uno de los principios que se plantearán a continuación, más que reglas absolutas, son un marco de referencia para aquellas personas que están planeando desarrollar para SAP Business One.

Los 8 principios del programador SDK
Principio 1	Aprovechar al máximo el SDK
Principio 2	Aprovechar al máximo el lenguaje de programación
Principio 3	Windows es mi terreno
Principio 4	SAP Business One es mi casa
Principio 5	Lo que pasa en mi mundo es mi responsabilidad
Principio 6	Los otros son importantes
Principio 7	SAP Business One es multiusuario
Principio 8	Nunca olvide los demás principios

Principio 1: Aprovechar al máximo el SDK.(Top)
El SDK es una herramienta supremamente poderosa y como tal tiene opciones insospechadas que permiten realizar casi la totalidad de las operaciones que SAP Business One ofrece. Por esta razón hay que tratarlo como un ser vivo que evoluciona y que constantemente debe ser analizado con toda la profundidad posible. Cada uno de los objetos, métodos, servicios o propiedades están por alguna razón y por tanto se debe estar pendientes todo el tiempo de su evolución (y en la medida de lo posible predecir hacia dónde va). Se debe conocer cómo funcionan como sistema único y no verlos como opciones aisladas dentro de un mundo no conectado.<span>Si la opción está disponible en el SDK es siempre preferible usar esta opción sobre otras, así en algunas ocasiones parezca que existe un camino más corto para llegar a la meta.</span>

Principio 2: Aprovechar al máximo el lenguaje de programación. (Top)
Si bien el Principio 1 es importante nunca se debe olvidar que el SDK se utiliza dentro de un lenguaje de programación que por lo general tiene opciones avanzadas que se pueden utilizar.

Reflection, Garbage collector, SOA, etc., son principios que complementan la programación con el SDK y que se deben tener en el horizonte de la programación de cualquier Add-On para SAP Business One. Potencializar las opciones que ofrece el lenguaje es una forma efectiva de potencializar los desarrollos que utilizan el SDK.

Principio 3: Windows es mi terreno. (Top)
Algo que nunca se debe olvidar es que SAP Business One es una aplicación Windows. Si se recuerda esto constantemente no se olvidará que se puede utilizar el sistema operativo a nuestro favor. Se pueden crear servicios de Windows, utilizar el registro, aprovechar las opciones del sistema operativo y reutilizar funcionalidades existentes que de otra forma se tendrían que desarrollar desde la base.

Esto también puede jugar en contra ya que se está heredando cualquier problema del sistema operativo o de las aplicaciones que se estén ejecutando en su memoria. Como aplicación Windows estamos en un terreno en el cual no se es el único programa peleando por recursos o por accesos exclusivos que se puede llegar a dar por hecho.

Principio 4: SAP Business One es mi casa.(Top)
Si Windows es el terreno que se está pisando, SAP Business One es la casa en la que se habita, por lo que cualquier operación que haga que se desestabilice puede echarla abajo. La estructura de la base de datos, los saltos sobre la lógica de negocio o cualquier otra operación que vaya en contra del funcionamiento del sistema deben ser evitados a toda costa.

Llega el momento en que los programadores se sienten confiados del funcionamiento interno del mismo y en el que llegan a conocerlo a un nivel que parece que la lógica interna ha sido descifrada. Si ese es el caso, se debe evitar a toda costa la tentación de programar basados en ese conocimiento.

Principio 5: Lo que pasa en mi mundo es mi responsabilidad. (Top)
Los Add-On tienen total responsabilidad de lo que sucede dentro de ellos. Sin importar lo simple que parezca una función nunca se debe olvidar que se deben capturar las excepciones que se levanten a nivel de la aplicación, de Windows o de SAP Business One.

Cada función que se cree o utilice debe contemplar los errores que se pueden generar y se debe estar en la capacidad de reaccionar ante dicha eventualidad. Esperar lo inesperado es un imposible, pero tratar de predecir los resultados es una realidad que los programadores deben tener en mente con cada línea de código que escriben.

Principio 6: Los otros son importantes. (Top)
Muchas veces cuando se está programando para SAP Business One nos olvidamos que pueden existir otros Add-On que pueden cambiar la forma en que se interactúa con el sistema. Nunca se debe dar por hecho que se va a tener a disposición un sistema estándar y debe aplicarse el Principio 5 cada vez que estoy interactuando con un formulario, botón u opción de SAP Business One.

Puede que el campo del que depende el Add-On no esté allí cuando lo necesite.

Principio 7: SAP Business One es multiusuario. (Top)
Cuando se esté diseñando un Add-On para SAP Business One no se debe olvidar que el sistema es multiusuario. Esto puede sonar obvio, pero muchas veces es un norte que perdemos rápidamente durante el diseño de nuestra funcionalidad.

Por esta razón es importante entender cómo reacciona el sistema estándar (y con otros Add-On) antes de que el Add-On que se está desarrollando entre a funcionar, para reaccionar de forma adecuada al ambiente multiusuario.

Principio 8: Nunca olvide los demás principios.(Top)
Cada vez que se termine una funcionalidad puede ser de mucho provecho repasar cada uno de los anteriores principios para verificar el cumplimiento de los mismos dentro de la aplicación. Una validación de este estilo puede hacer que una funcionalidad mejore, sea más rápida o se encuentre un error que sólo se vería en producción.

Creo sinceramente que aplicar de los anteriores principios puede ayudar a tener Add-On más robustos y que interactúen de forma más natural y harmónica con los otros.  Seguramente existirán muchos más que pueden ayudar a mantener el orden el universo que es SAP Business One. Pero como lo dije al principio: esta es una religión poco dogmática.