Technical Information

Utilizing Axapta Application Layers

DISCLAIMER This material is for informational purposes only. Microsoft Business Solutions ApS disclaims all warranties and conditions with regard to use of the material for other purposes. Microsoft Business Solutions ApS shall not, at any time, be liable for any special, direct, indirect or consequential damages, whether in an action of contract, negligence or other action arising out of or in connection with the use or performance of the material. Nothing herein should be construed as constituting any kind of warranty. COPYRIGHT NOTICE Copyright 2002 Microsoft Business Solutions ApS, Denmark. TRADEMARK NOTICE Microsoft, Great Plains, bCentral and Microsoft Windows 2000 are either registered trademarks or trademarks of Microsoft Corporation or Great Plains Software, Inc. in the United States and/or other countries. Great Plains Software, Inc. and Microsoft Business Solutions ApS are whollyowned subsidiaries of Microsoft Corporation. Navision is a registered trademark of Microsoft Business Solutions ApS in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. No part of this document may be reproduced or transmitted in any form or by any means, whole or in part without the prior written permission of Microsoft Business Solutions ApS. Information in this document is subject to change without notice. Any rights not expressly granted herein are reserved. The Arial font was used. DocID: AX-300-TIP-046-v01.00-ENUS

TABLE OF CONTENTS

1INTRODUCTION ..................................................................................................1 2AXAPTA APPLICATION LAYER TECHNOLOGY.............................................................2 2.1Application Layers..........................................................................................2 2.2Patch layers....................................................................................................5 2.3Application development................................................................................5 2.4Application layer distribution..........................................................................7 2.5Application runtime- and development codes..............................................9 2.6Application upgrade......................................................................................10 3AXAPTA ADD-ON SOLUTION PROGRAM.................................................................13 3.1Implementation.............................................................................................13 3.2Implementation layer....................................................................................13 4APPENDIX 15

Technical Information Utilizing Axapta Application Layers

1 Introduction
This technical information paper describes how to utilize the Axapta application layers. The target audience for this document is anyone working with developing additional functionality for Axapta, as well as anyone guiding customers in the purchase of execution/development access to Axapta. The document will give an overview of the unique application layer technology in Axapta, the different layer components, how to distribute application developments, and how to get access to the development environment and the execution access to the created business logic. The application layer technology in Axapta is a hierarchy of application levels, which ensures that modifications and additions can be made without

interfering directly with the application objects on the level below the current level. This document will also give an introduction to the Add-on Solution Program for Axapta partners, and the consequences in regards to the utilization of the application layers.

Technical Information Utilizing Axapta Application Layers

2 Axapta Application Layer Technology

The Axapta Application layers are a hierarchy of levels in the Axapta application source code, which ensures that you can make modifications and additions without interfering with the application objects on the level below your own. The idea is that when you make an object modification on one level, the modified object overshadows the object on a lower level. For example, you could choose to add E-mail information to a standard customer form. The addition would be saved in your current level only; the revised form would replace the standard form, but you would always be able to go back to the original one on the level below your own by simply removing the new form. The layers are designed with different Axapta groups in mind. Basically three Axapta groups have an interest in adding and modifying application objects: 1. Microsoft Business Solution application developers, who create the standard application 2. Business partners 3. Axapta end-users
Each of these three groups has a set of layers in which they can add and modify application objects.

2.1 Application Layers

The application layer hierarchy consist of 16 layers divided into 8 different layer categories, each consisting of 2 layers. All application layers are able to utilize all the tools available in the Axapta MorphX Development Suite as well as all object types, tables, classes, macros, extended data types, forms, reports, and so forth. The online help is also included in the Layers technology, as well as the utilization of the label system. Having all the object types available in every application layer makes the application layer technology very flexible and dynamic especially when upgrading from one version to the next. See the Application upgrade section on page 11 for additional information. Each layer is technically saved in a separate file called Ax<layer>.aod, for example Axsys.aod for the SYS layer, Axdis.aod for the DIS layer, and so on. The .aod extension is an acronym for Application Object Data file. The files are stored in the Axapta Standard folder under Appl.

Technical Information Utilizing Axapta Application Layers

Application layer categories: Layer name System (SYS layer) Layer description This is the innermost layer where the standard Axapta application is implemented. The layer is controlled and maintained solely by Microsoft Business Solutions. The application objects in the standard application can never be deleted. ID range: 1-8000 Global Solutions (GLS layer) Microsoft Business Solutions has an option of certifying and distributing strategic global solutions that have not been developed in-house. These solutions are delivered as a standard part of the Axapta product. The solutions have been created with the same development standards as the standard application, and qualified as such. Solution examples; Shop Floor Control, Human Resource management. ID range: 8001-16000 Distributor (DIS layer)
The local Microsoft Business Solutions offices are provided with a DIS layer to include country-specific functionality, developed locally in between two releases. Local developments are to be included in the next coming global release. The local offices are maintaining this layer locally.

ID range: 16001-18000 Local Solution (LOS layer)

The local Microsoft Business Solutions offices are given the same opportunity to certify and distribute a strategic local solution that has not been developed

in-house. Solutions in the LOS layer are protected by the license code framework that the standard application utilizes. Solution examples; Payroll, EDI ID range: 18001-20000 Business solution (BUS layer) Business partners are given the opportunity to develop and distribute vertical and horizontal solutions to other partners and customers using the BUS layer.

Technical Information Utilizing Axapta Application Layers

Solutions in the BUS layer are protected by the same license code framework that the standard application utilizes. Note the BUS layer is reserved for the Add-on Solution program and requires a signed agreement to utilize for development and distribution. Dor more information, see Add-on Solution Program section on page 13. ID range: 20001-30000 Value Added Reseller (VAR layer) Business partners are provided with a separate layer that they can use without any business related restrictions. This means that any developments the partner would like to do for their customers can be added to this layer.
The business partner must keep a catalogue of what application functionality and what VAR/BUS configurations customers have been able to correctly update to their installation.

ID range: 30001-40000 Customer (CUS layer) Corporate enterprises, as well as business partners, are given the opportunity to modify their installations. If a corporate enterprise has an internal IT department with Axapta programming skills, this would be the layer to add generic enterprise modifications. The Customer and User layers are included in order to support enterprises and individual companies in their need for in-house development, without jeopardizing the modifications made by the business partner. This means that application code made in the VAR layer will not be changeable. ID range: 40001-50000 User (USR layer) Individual companies or companies within an enterprise can utilize this layer to make
customizations that are unique to the customers' installation, including reports via the report wizard.

The USR layer, in combination with the CUS layer, can be used if the corporate enterprise develops a enterprise specific vertical. However, in order to comply with local market needs, additional requirements would need to be implemented. This setup would require more than one installation as changes made in the USR layer and any other layer will be available to all company accounts within the same installation ID range: 50001-60000

Technical Information Utilizing Axapta Application Layers

2.2 Patch layers

Each application layer category has an additional application layer for handling patches, minor updates, service packs, hot fixes and additional functionality. The layers are additions to the above-described layers and are situated in-between the other layers. They can be distinguished from the other application layers by the use of the letter P in the end of the layer name. The layers are: SYP, GLP, DIP, LIP, BUP, VAP, CUP, and USP. The utilization of the patch layers are not subject to any predefined Microsoft Business Solutions rules, and can therefore be used to support the customers/business partners in any way suitable. Microsoft Business Solutions utilize the patch layer for sending out service packs to existing developments. This procedure provides the option of sending out corrections without interfering with the existing layers. When the next version of Axapta is released, the corrections will be part of the new standard application layer, and the existing patch layers can be deleted. This procedure can be used for all layers in Axapta, and help avoid implementation of corrections without needing a full upgrade.

2.3 Application development

Application development in Axapta should always be developed, tested, and implemented in separate environments. Microsoft Business Solutions recommend developing and implementing modifications with respect to environments in the following ways:

1.

Develop and pre-test modifications on a non-customer version; the business partner-environment. The modifications are developed and tested on a standard installation, complete with a separate database. However, as the environment is rarely entirely identical to the one at the customer site (for example with respect to network and number of users), verification cannot be completed at the business partner site. Separate installations also enable business partner to apply service packs and upgrades within the business partner environment first.

2.

Move the modifications to the customer site on a non-production version; the TEST-environment.

Technical Information Utilizing Axapta Application Layers

Modifications should never be made directly in a production environment. It is necessary to use the TEST-environment if additional modifications are needed at the customer's site. For more information, see the on-site development section below. It is important that modifications made to the application in the TEST-environment are synchronized with the business partner-environment. Having a system with an application that is identical to the customer's improves the customer service and the possibilities for support from home.

3.

Move the modifications to a production version at the customer's; the PRODUCTION-environment. This is the final, thoroughly tested version of the customer's modifications. Modifications should never be made in the production environment.

The application development can physical be performed in many different places, but seen from a product license point of view, there is a strong distinction between developing at the customers site using the property of the customer, and in-house application development on property of the business partner.

On-site application development On-site application development in Axapta is defined as people working on the property (computer, server, and so forth) of the customer using the license codes purchase by the customer from Microsoft Business Solutions. If customers prefer to have adjustments/new developments made to their installation on-site/locally, they must purchase the development suite (X++, MorphX and Web MorphX ) even though all developments are saved in the VAR/VAP layer. For more information see Application runtime- and development codes on page 9.

In-house application development In-house application development in Axapta is defined as people working on the property (computer, server, and so forth) of the business partner, using the license codes given to the business partner by Microsoft Business Solutions. All business partners, as a part of the agreement with Microsoft Business Solutions being a Solution Center, are given the proper license codes to utilize the entire development environment. This means that the business

Technical Information Utilizing Axapta Application Layers

partners do not have to purchase anything in order to development in Axapta. The utilization of the business partner license codes are only allowed when working on the business partner property, which means that the license codes are not allowed to be utilized in any customer installations, not even for demonstration, evaluation, or validation purposes.

2.4 Application layer distribution

The distribution of the application developments to other installations can generally be done using two principles: Ship a complete application layer as a file, e.g. the VAR layer (AxVAR.aod) Ship a subset of the application as an export file (.xpo file). When distributing the application developments, the business partner must be aware of the consequences of using the different distribution principles, for example, all objects and classes in the Data dictionary have
internal, unique Ids. Because data and functionality are linked to these Ids, misuse of them can lead to fatal results.

When shipping an entire layer file, all Ids are maintained. However, when application developments are shipped as an export file (.xpo) all objects are assigned a new Id when the export file is imported. This implies that you cannot combine the two principles. Distribution process example: 1. The business partner installs an application at the customer site. The application at the customer site corresponds exactly to the one at the business partner site 2. An error is discovered. A hotfix is produced by the business partner and sent to the customer site as an XPO file. The hotfix includes a new table. When the hotfix is imported at the customer site it is placed in the USR layer and given an Id in the range 50001-60000 3. The customer adds new functionality to the installation. The new functionality builds on the table in the hotfix

Technical Information Utilizing Axapta Application Layers

The business partner has now been working in parallel and has added some new features to the VAR layer. The business partner decides to ship a new version to the customer in a new VAR layer. 4. The new layer also includes the hotfix. Therefore the customer decides to clean up the installation by deleting the previously installed hotfix. 5. Now the code made by the customer (which was based on the table in the hotfix) does not work anymore as the id of the table has changed. The customer now has to modify the customizations to comply with the new situation by integrating with the used tables resided in the VAR layer instead of the USR layer.
6.

Technical Information Utilizing Axapta Application Layers

2.5 Application runtime- and development codes

Axapta is designed with a runtime- and development environment supporting all application layers and the entire MorphX Development Suite. The runtime environment provides access to execute business logic inside Axapta and is provided by the application layer. This means that business logic can be executed in for example the VAR layer if the VAR layer runtime license code is purchased. Axapta is shipped with default runtime codes and access to the layers; SYS, GLS, DIS, and LOS layers, and their associated patch layers. The default runtime codes are not available in the license code screen as these codes are managed by the Axapta kernel itself. Any other layer needs a runtime code to be utilized, but it is not possible to purchase separate runtime codes for the CUS and USR layer as they are a natural part of the development code X++, like the SYS, GLS, DIS, and LOS layers are a natural part of the base package. The CUS and USR layer runtime codes will also be absent on the license code screen. The only runtime codes available as separate codes are the VAR and BUS layer codes and their associated patch layers. The development codes in Axapta are divided into 2 categories; development codes for utilizing the development tools inside Axaptas MorphX Development Suite, and the development codes for opening the application layers. The development codes for MorphX Development Suite consist of Windows MorphX Development Suite, Web MorphX Development Suite, and X++ source code. The X++ development code also includes access to the BUS/BUP, VAR/VAP, CUS/CUP, and USR/USP runtime, and opens the application layers CUS/CUP and USR/USP for application development. The development codes for opening the application layers are codes utilized when starting Axapta, as they specify which layer to open and place any application development. The codes are added to the Axapta Configuration Utility in the Application Object Layers field as shown in the graphic below.

The development codes opening the layers are included in the license letter sent from Microsoft Business Solutions, and not in the license file. You need to specify the application layer into which the business logic needs to go, for example VAR, and then type the delivered codes in the Code and Confirm fields.

Technical Information Utilizing Axapta Application Layers

Note The development codes opening the layers do not give access to the development tools. These need to be purchased individually.

2.6 Application upgrade

The Add-on Solution Program utilizes the BUS layer in order to support the program and as a consequence, the BUS layer is 100% reserved. Therefore the previous utilizations of the BUS layer on Axapta 2.5 will have to be removed from Axapta 3.0 and implemented in one of the other application layers. The application merge/upgrade list below will represent the top level guidance on the process as seen from Axapta 3.0: 1. 2. 3. Make a complete backup of installation, both application and data Export all data from the Axapta installation Use the Compare layer tool to make a comparison between the BUS layer and the application layer that the current BUS layer developments should be merged into. For example, the VAR layer. For more information see the Developers Guide. Create a Development Project containing all application objects in the BUS layer using the Development Project Filter. See the Developers Guide for more details Manually implement/merge the possible comparison conflicts into for example the VAR layer, and remove the merge objects from the created BUS layer Development Project. Mark all the objects left in the Development Project, right-click, and select export. Remember to click the Select Application Objects as shown in the graphics below, and select the BUS layer

4.

5.

6.

7.

Import the exported application file into the layer where the comparison conflicts were manually implemented. Note Because the conflicts between the layers are removed from the export/development project, there should be no problem

10

Technical Information Utilizing Axapta Application Layers

importing the export files, as they would be considered as normal additions to the existing layer 8. 9. Delete the BUS layer because the merged application layer now contains everything from the BUS layer Delete all data in the Axapta installation

10. Import the exported data into the merge application

This process should always be performed in the business partner environment and the TEST-environment prior to performing the live merge process. The process described above is the standard process for performing the merge/upgrade process in one sequence, but there could be differences. The application layer merging would be performed and completed at the business partner site prior to starting the process at the customer site: 1. Perform a complete merge process in the TEST-environment: a. and data b. c. d. e. Export all data from the Axapta installation Utilize the merge application layer from the business partner (physical layer file - .aod file) Delete the BUS layer Delete the data in the Axapta installation f. Import the exported data into the merged application Backup the entire TEST-environment, application

2.

Perform a complete merge process in the Production-environment: a. b. c. d. e. f. Backup the entire Production-environment, application and data Export all data from the Axapta installation Utilize the merge application layer from the business partner (physical layer file - .aod file) Delete the BUS layer Delete the data in the Axapta installation Import the exported data into the merged application

It is very important to monitor the merge process performed in the TESTenvironment as it will provide an indication on the timeframe required,

11

Technical Information Utilizing Axapta Application Layers

potential pitfalls, and help you gain general experiences for when you perform the actual merge process in the PRODUCTION-environment.

12

Technical Information Utilizing Axapta Application Layers

3 Axapta Add-on Solution Program

The Add-on Solution Program for Axapta 3.0 and forward is an option for our business partners to protect their investments in developed add-on solutions and virtualizations, and at the same time, provide a tool for the business partners to distribute add-on solutions on a larger and safer scale. The protection of the business partner developments is managed using the same protection setup as Microsoft Business Solutions uses for protecting the standard Axapta modules.

3.1 Implementation
The protection of the add-on solution is implemented by using the new license code setup and configuration key setup developed for Axapta 3.0. Configuration keys are used to enable required system functionality. These keys are controlled by a license code object. Configuration keys can also inherit from another configuration key. When a license code is purchased, the parent configuration key that the license code object controls is enabled. Additional information on license codes and configuration keys are available in Navision Axapta. Additional information on Configuration and Security keys is available in Developers Guide.

3.2 Implementation layer

The Add-on Solution Program utilizes the BUS layer in order to support the program and therefore, the BUS layer is 100% reserved for solutions utilizing this program. This means that all previous developments made in this layer will have to be migrated to other layers. The customers with valid BUS runtime licenses have the ability to run the BUS layer as is. If the NSC needs to migrate any customizations, then they need to do it in the VAR/VAP layer or any other layer if possible. If the customers haven't bought the VAR runtime or X++, then they will be given the VAR runtime for Axapta 3.0 for free. But, for the next version of Axapta, the BUS runtime will be removed from the license unless the customer still want the BUS runtime license. If this will be the case, then they will have to pay subscription fee for both the VAR- and BUS runtime." Partners will not receive BUS development codes by default. The delivery of a BUS layer development code will require a signed agreement (Add-on

13

Technical Information Utilizing Axapta Application Layers

Solution Program Addendum) with Microsoft Business Solutions for the Addon Solution Program. The protection of modules will not be available in any layer other than the BUS layer. Please note that technical conflicts may occur between different add-on solutions. It is the responsibility of the business partner to implement the add-on solutions to make sure that does not happen.

14

Technical Information Utilizing Axapta Application Layers

4 Appendix
Important documentation references Axapta Application Development Best Practices Handbook (online help file, Ax-300-DVG-003-v01.00-ENUS.chm) Axapta Developers Guide (online help file, Ax-300-DVG-002-v01.00ENUS.chm) Add-on Solution Program for Microsoft Business Solutions Axapta (Contact your local Microsoft Business Solutions office)

15