Step 1: Submit your app idea for pre-approval
We will review your app idea, provide any relevant feedback, and pre-approve. Submit your idea here: Microsoft AppSource.
After pre-approval, you will receive a unique object range for your app along with additional information to guide you through the development, validation, and publishing of your app.
El enlace para realizar la solicitud, nos lleva a un formulario online donde debemos especificar una serie de datos nuestros y de la extensión que pretendemos desarrollar y publicar.
La información que debemos facilitar es la siguiente:
- Datos de contacto
- Nombre y apellidos
- E-mail
- Rol dentro de la empresa
- País
- Datos de la empresa
- Nombre de la empresa
- Página web
- E-mail de nuestro contacto en Microsoft (si es que tenemos alguno)
- Información de la Extensión
- Nombre de la extensión
- Sector principal al que está destinada la extensión
- Descripción de la extensión
- Producto de Microsoft al que aplica la extensión
- Si la extensión tiene activado el método de autenticación Azure Active Directory Federated Sign-on (AAD federated SSO)
- Enlace a la página web de la versión de prueba de la extensión
- Cómo hemos conocido la AppSource de Microsoft
Información de la Extensión
La primera extensión que vamos a desarrollar y publicar en CipPlatform será una pequeña funcionalidad en la que los usuarios puedan indicar en la ficha del cliente una dirección de envío predeterminada, y en el momento de crear un documento de venta para el cliente, el sistema se encargue de informar de la dirección de envío teniendo en cuenta la dirección de envío predeterminada especificada en la ficha del cliente.
Se trata, de hecho, de la extensión que desarrollamos a lo largo del libro Programación de Extensiones para Dynamics NAV 2018.
La información que hemos facilitado a Microsoft sobre esta extensión es la siguiente:
- Nombre: CLIP Default Ship-To Address
- Sector: Distribución
- Descripción:On sales documents, users have the ability to select a specific “Ship-To Code” to ship the goods to an address different than the social or fiscal address of the customer.If a customer has an address to which goods should be always shipped, the users have no place in the application to specify such a request. They have to always remember to select that specific address when creating a new sales order.This extensión will provide users with the ability to set a “Default Ship-To Address” on the Customer Card and let the system automatically fill in the “Ship-To Code” field when creating new sales documents.
- Producto: Microsoft Dynamics 365 for Financials, Business Edition
- La extensión tiene activado el método de autenticación Azure Active Directory Federated Sign-on (AAD federated SSO): No
- Enlace a la página web de la versión de prueba de la extensión: No disponemos de una página aún para la extensión, de modo que he dejado este campo vacío
Siguiente paso
La solicitud está hecha. Unas 5-6 horas más tarde recibí este e-mail:
Ahora toca esperar a recibir una respuesta por parte de Microsoft. Esperemos que sea positiva.
En principio, si nos aprueban la extensión, deberían también asignarnos ya un rango de numeración en el que desarrollar.
Al cabo de un par de días recibimos el email:
Adjunto al e-mail, un Excel en el que rellenar una serie de datos referentes a la extensión que queremos publicar, y que tiene la siguiente pinta:
La información requerida en el documento para poder publicar la extensión en AppSoruce es la siguiente:
- Información básica sobre la organización
- MPN ID
- Nombre del Partner
- País de origen
- Número de Cuenta de PartnerSource Business Center (PSBC)
- Nombre de la persona que rellena este formulario
- E-mail de la persona que rellena este formulario
- Información sobre la App
- Nombre de la Extensión
- Descripción de la Extensión
- Tipo de app que se está desarrollando (tipo y propósito)
- Tipo – Es una extensión de productividad o una extensión para un sector determinado?
- Propósito – Si es una extensión de productividad, en qué área se mejora la productividad?
- Propósito – Si es una extensión para un sector determinado, a qué sector se dirige?
- Cuándo estará la extensión disponible para ser distribuida
- En qué trimestre estará la extensión disponible
- En qué año estará la extensión disponible
- Para qué países estará disponible
- Qué rango de numeración solicitas
- Cuantos objetos crees que necesitará la extensión
- Qué nivel de preparación tienes
- Has publicado alguna otra extensión en la AppSource?
- En caso afirmativo, especifica el nombre de las otras extensiones
Información sobre la App
La información que nos piden en este formulario no es nueva. Hemos utilizado exactamente los mismos textos que escribimos para la solicitud inicial
Nombre: CLIP Default Ship-To Address
Descripción: On sales documents, users have the ability to select a specific “Ship-To Code” to ship the goods to an address different than the social or fiscal address of the customer.If a customer has an address to which goods should be always shipped, the users have no place in the application to specify such a request. They have to always remember to select that specific address when creating a new sales order.This extensión will provide users with the ability to set a “Default Ship-To Address” on the Customer Card and let the system automatically fill in the “Ship-To Code” field when creating new sales documents.
Tipo de app que se está desarrollando
En este apartado hay 3 preguntas, de las cuales sólo hay que responder 2. Las posibles respuestas vienen determinadas por un menú desplegable.
Tipo – Es una extensión de productividad o una extensión para un sector determinado?
Las respuestas posibles son: Productivity, o Industry.
En nuestro caso, hemos seleccionado la opción de productividad.
Propósito – Si es una extensión de productividad, en qué área se mejora la productividad?
Las respuestas posibles son:
- Productivity – Payroll
- Productivity – Tax Services
- Productivity – Payment Processing
- Productivity – Shipping
- Productivity – Ecommerce
- Productivity – Other
- Productivity – Expense
- Productivity – Supply Chain Enhancement
- Productivity – Competitive Import
- Productivity – Accounting Enhancement
En nuestro caso hemos seleccionado la opción de mejora en los envíos.
Propósito – Si es una extensión para un sector determinado, a qué sector se dirige?
Las respuestas posibles son:
- Industry – Professional Services
- Industry – Health Care
- Industry – Banking/Financial
- Industry – Discrete Manufacturing
- Industry – Retail
- Industry – Process Manufacturing
- Industry – Information & Media
- Industry – Other Services
- Industry – Telecommunications
- Industry – Insurance
- Industry – Wholesale
- Industry – Life Sciences
- Industry – Transportation
- Industry – Construction
- Industry – Utilities
- Industry – Real Estate
- Industry – Hospitality
- Industry – Pharmaceuticals
- Industry – Agriculture/Mining
En nuestro caso, no hemos respondido a esta pregunta, pues la extensión que queremos publicar no está destinada a un sector en concreto.
Cuando estará la extensión disponible para ser distribuida
En esta sección debemos especificar año y trimestre en el que estimamos que la extensión estará completada. En nuestro caso, creemos que puede estar a punto para el segundo trimestre de 2018.
También debemos especificar los países en los que estará disponible la App. Como nota, Microsoft nos recuerda que por ahora las Apps sólo están disponibles para Canadá, Estados Unidos, Reino Unido y Dinamarca.
Para que una extensión se pueda publicar en un país, es imprescindible que ésta esté completamente traducida a los idiomas incluidos en cada una de las localizaciones.
Si seleccionamos todos los países disponibles por ahora, tenemos que tener claro qué deberemos proporcionar traducciones en Inglés de Estados Unidos, Inglés del Reino Unido, Inglés de Canadá, Francés de Canadá y Danés.
En nuestro caso, hemos seleccionado todos los países disponibles. Con las traducciones al inglés y al francés nos podremos apañar nosotras mismas. Para la traducción al danés tendremos que buscar un colaborador que quiera ayudarnos.
Que rango de numeración solicitas
Una única pregunta, tres posibles respuestas: 50, 200 o 500.
Debemos estimar grosso modo cuantos objetos creemos que necesitaremos para el desarrollo de la extensión.
Para nuestra extensión, necesitaremos 1 tabla, 2-3 páginas y 2-3 codeunits. De modo que hemos optado por el rango más pequeño, el de 50.
Hay que tener en cuenta que un mismo número se puede repetir para distintos tipos de objetos, de modo que debemos solicitar el rango de numeración en función del tipo de objetos del cual estimemos que necesitamos el número mayor.
Me explico con un ejemplo: Imaginemos que voy a desarrollar una extensión para la que estimo que voy a necesitar
- 10-15 tablas
- 30-40 páginas
- 10-20 codeunits
- 10-20 reports
- 2-3 xmlports
Sumados, tendremos entre 62 y 98 objetos. Podríamos estar tentados de pedir un rango de numeración de 200. Pero no es necesario, porque el objeto individual que más vamos a usar son las páginas, y como mucho creemos que necesitaremos 40. De modo que con un rango de 50 tenemos suficiente.
Que nivel de preparación tienes
Nuestro nivel de preparación por ahora es nulo, puesto que esta es la primera extensión que pretendemos publicar en la AppSource.
Siguientes pasos.
Una vez hemos completado el Excel y lo hemos enviado tocará esperar a obtener una respuesta y una numeración para poder empezar con el desarrollo.
–> Cuatro días más tarde, recibí un e-mail en el que Microsoft me confirmaba que la solicitud había sido aprobada y me especificaba el rango de objetos que me habían asignado.
A partir de aquí, hay que realizar 3 pasos distintos:
- Descargar una licencia de desarrollo que contenga el nuevo rango asignado
- Solicitar acceso al Cloud Partner Portal
- Desarrollar la extensión
Vamos a repasar cada uno de ellos.
Descargar una licencia de desarrollo para Dynamics NAV
En el e-mail, Microsoft me envía un pdf con las instrucciones paso a paso para descargar una licencia de desarrollo para Dynamics NAV que contenga la nueva numeración que nos han asignado.
El procedimiento es exactamente el mismo que para generar y descargar cualquier licencia de Dynamics NAV. Pero hay una diferencia importante. En un punto de la configuración de la licencia, hay un sitio donde dice “Do you want ISV insert rights included?“. Hay que marcar que Sí.
Los pasos completos para configurar y descargar una licencia de Navision son los siguientes:
- Conectarse a la PartnerSource Business Center
- Ir a Herramientas para desarrolladores
- Ir a License Key Configuration
- En el campo Tipo de programa, seleccionar Consultant Demo and Dev
- Clicar en Crear nueva configuración
- En el campo Tipo de programa, seleccionar Consultant Demo and Dev
- En el campo País de licencia, seleccionar España
- En el campo Nombre de configuración, darle un nombre a la licencia que nos permita reconocerla. En mi caso, le he dado el nombre NAV2018 con ISV (1)
- En el campo Línea de productos, seleccionar Microsoft Dynamics NAV Perpetual
- Tras esta selección, nos aparece un nuevo campo llamado Versión principal en el que he seleccionado 2018
- Tras esta selección, nos aparece un nuevo campo llamado Country Code en el que he seleccionado Country Code: Spain
- Tras esta selección, nos aparece un nuevo campo llamado Product Edition en el que he seleccionado 610 Partner Demo/Dev Module
- En el campo Plantilla, seleccionar NAV 2018 Consultant Demo/Dev
- En el campo Nombre de la empresa, seleccionar nuestra empresa
- Clicar en Seleccione los módulos
- En los módulos, podemos especificar el números de usuarios completos y limitados que queremos que contenga la licencia que estamos configurando. En mi caso, le doy a Seleccionar todo para que el sistema configure la licencia con el máximo de usuarios a los que tengo acceso.
- Clicar en Guardar
- Ahora vamos a una nueva pantalla dónde debemos seleccionar Sí en el campo ISV insert rights. Éste es un punto importante para que la licencia tenga acceso al nuevo rango de objetos que nos ha asignado Microsoft
- Para comprobar que esté todo correcto, podemos seleccionar la opción Permission Report Detailed (txt) y darle a Mostrar informe de permiso. Esto nos generará un archivo de texto en el que deberíamos ver la numeración que tenemos asignada para desarrollar la extensión
- Clicar en Descargar licencia/clave de registro actual, para que se genere el archivo .flf y nos lo podamos descargar
Y con esto ya tenemos una licencia con la nueva numeración que podemos cargar en una base de datos de Navision.
Solicitar acceso al Cloud Partner Portal
En el e-mail, Microsoft nos dice que para tener acceso al Cloud Partner Portal debemos enviar un e-mail a una dirección de correo electrónico muy concreta.
En este e-mail debemos especificar:
- El nombre de nuestra empresa tal y como queremos que se muestre en la AppStore una vez publiquemos nuestra extensión
- El e-mail con el que queremos acceder al Portal. Nos recomiendan que sea un e-mail genérico que puedan consultar múltiples usuarios. Es decir, que no sea un e-mail de una persona concreta, sino algo más genérico como info@miempresa.com.
He enviado el e-mail y tan solo unos minutos después ya he recibido una respuesta diciendo que ya tengo el acceso disponible.
Desarrollar la extensión
Los dos puntos anteriores se podían completar en poco tiempo.
El desarrollo de la extensión, sin embargo, es un proceso más laborioso.
Microsoft nos proporciona dos enlaces que nos pueden interesar:
Seguimos para poder publicar nuestra extensión en AppSource
Ya lo tenemos todo para desarrollar la extensión. Un desarrollo que no se puede realizar de cualquier manera, sino que tiene que cumplir una serie de requisitos técnicos obligatorios, una lista que a día de hoy cuenta con 16 requisitos distintos.
Es importante revisar la lista de requisitos técnicos obligatorios regularmente. Justo unos días después de publicar este artículo, la lista creció a 17 requisitos.
Algunos de ellos son consideraciones previas. Otros son requisitos a tener en cuenta mientras realizamos el desarrollo. Y otros son requisitos que deberemos cumplir cuando hayamos terminado con el desarrollo.
Vamos a hablar hoy de un par de requisitos previos: aprender a desarrollar en Visual Studio Code y reservar un prefijo o sufijo.
Desarrollar la extensión en Visual Studio Code
La AppSource de Microsoft ya no acepta extensiones desarrolladas en C/SIDE (extensiones V1.0), toda extensión que desarrollemos a partir de ahora tiene que ser una extensión V2.0 desarrollada en Visual Studio Code. De modo que el primer paso es familiarizarnos con el nuevo entorno de desarrollo.
Os dejo algunos enlaces que os pueden ayudar a conocer esta nueva herramienta:
Utilizar prefijos o sufijos para eliminar la colisión entre extensiones
Imaginad que vuestra extensión crea, en la tabla de clientes, un campo llamado “Default Ship-To Address”.
Imaginad también que otra extensión crea, en la misma tabla, un campo llamado “Default Ship-To Address”.
Misma tabla, mismo nombre de campo. Seguramente el ID del campo será distinto, porque cada extensión tendrá asignado su propio rango de numeración, pero el hecho de coincidir en nombre genera una colisión.
Dynamics NAV no permite que haya en una misma tabla dos campos con el mismo nombre, aunque tengan IDs distintos.
Del mismo modo que no permite dos tablas distintas con el mismo nombre, aunque tengan numeraciones distintas. Ni dos páginas distintas con el mismo nombre, ni en general dos objetos del mismo tipo con el mismo nombre.
Tampoco permite dentro de una página, mostrar dos campos con el mismo nombre, ni tener dos acciones con el mismo nombre, etc.
Volvamos a las dos extensiones distintas que crean en la misma tabla dos campos distintos pero que tienen el mismo nombre. Se generará una colisión. La primera de las extensiones que se publique e instalé no tendrá ningún problema, pero no conseguiremos publicar ni instalar la segunda.
La solución pasa por utilizar nombres únicos. Y para conseguirlo, podemos hacer uso de un prefijo o sufijo.
Si mi campo se hubiera llamado “CLIP Default Ship-To Address” y el de la otra extensión se hubiera llamado “Default Ship-To Address EXT”, no existiría la colisión.
Así que debemos escoger un prefijo o sufijo y utilizarlo en las siguientes situaciones:
- Al nombrar objetos
- Al crear campos en tablas estándar
- Al mostrar campos en páginas estándar
- Al crear acciones en páginas estándar
No sería necesario para crear campos en una tabla propia o para cualquier otro elemento que requiere un nombre dentro de objetos propios, como al crear variables o funciones en codeunits o páginas propias.
Reservar el prefijo o sufijo elegido
Dos extensiones distintas pueden haber elegido el mismo prefijo o sufijo, generar los mismos campos con los mismos nombres en las mismas tablas, y acabar generando colisiones igualmente. Por lo que es importante reservar el prefijo o sufijo que hayamos escogido. Si existe colisión entre dos extensiones que utilizan el mismo prefijo o sufijo, ganará la que lo tenga reservado.
Se puede escoger un prefijo o sufijo general, a nivel de empresa, y utilizarlo en todas las extensiones que desarrollemos.
O podemos escoger un prefijo o sufijo distinto para cada extensión que desarrollemos.
En CipPlatform hemos escogido el prefijo CLIP, que vamos a utilizar en todas las extensiones que desarrollemos. Ya lo tenemos reservado.
La reserva se hace enviando un e-mail a la dirección d365val@microsoft.com.
Para más información, te invito a leer el artículo Benefits and Guidelines for using a Prefix or Suffix.
Comentarios