During the development stage, you develop the customization, which involves implementing your planned changes by using customization tools and facilities. You modify the appearance and logic of the Acumatica ERP application or another Acumatica Framework-based application to meet the requirements you have defined.
Although this topic describes the customization process primarily by using examples with an Acumatica ERP application instance, the customization guidelines are similar for Acumatica Framework-based applications. For more details about add-on solutions, see Add-On Solution.
Follow this recommended workflow during the development process:
• Create the development application instance, which is a standard installation of Acumatica ERP (or your Acumatica Framework-based application) that consists of the website and the database. All further actions must be performed on this instance.
If the production instance had been customized before, you must update the development application instance with all the customization packages, which are currently published on the production instance.
• Start the development application instance, create a new customization project or select an existing one, and open the project.
| Customization Stages | 89
• Split the customization process into discrete steps, such as adding a UI element or extending business logic, and perform the needed changes step by step. (For details, see Customization Steps and Session Cycles.) Depending on the customization scope, you use appropriate tools and facilities.
As a rule, you enter page design mode mostly to use the tools and facilities of UI customization (see
Page Design Mode). While working within a customization project, you can also use the following: • Tools and facilities designed to support functional customization: Acumatica Customization
Engine or Acumatica Extensibility Framework
• Auxiliary customization facilities: The Generic Inquiry and Site Map webpages, and the Report Designer
• After the completion of every step, validate the changes you have performed.
Before the validation process begins, the system automatically saves the inner content of the project and all the external files of the project to the database of the application instance that is currently being customized. Therefore, we recommend that you download a package that may be used as an archive copy of the current state of the project before you make changes within the current customization session; you may also create an archive copy before saving new changes to database or before validating the changes. This copy may be useful if the validation process fails. In this case, you can upload the latest archive file to restore the previous state of the customization project.
• Publish the project, and perform local testing of the customized application instance (for details, see Understanding the Publication of a Project).
The content of each customization project available within the application is stored in the database, including all external files. The Published status of every customization project is also stored in the database. When you publish a customization project, the system generates or regenerates the common package and stores it in the database (if the database has been successfully applied on the website). You can view the successfully stored and applied common customization package by selecting View Published Customization XML on the Customization menu.
When you publish a customization project by using the Validate and Publish item of the Customization menu or the Validate and Publish (or Publish without Validation) button of the Customization Projects webpage, the application creates the common customization package content. This content represents the joined content of the current project and all previously published ones.
You can use the Publish without Validation option during the application upgrade process to resolve possible issues with functional customization that were created while you used the Acumatica Customization Engine. (For details, see Updating a Customization Project.)
When you publish multiple projects by using the Publish Customization webpage (as described in Managing Multiple Projects), the common customization package content is created with only the projects you have selected. Pay attention to the use of the Level column of this webpage, which is described in the referenced topic.
In some cases, you may need to upload an archive copy after you have saved the customization project to the database (and therefore, cannot restore the content of the project)—for instance, when you have found out that saved content is erroneous and decided to cancel all changes of the most recent development step. To learn the best actions in these cases, see how to upload the customization code of the project from the archive file (or deployment package) in Final Testing and Deployment Stage.
• To start the final testing and deployment stage, download the deployment package after the successful local testing.
We recommend that you use a separate application instance for each developer within a single project or a group of projects. Multiple developers should not work simultaneously with the same project or projects.
| Customization Stages | 90
You should divide customization tasks among the developers so that they are radically different and each developer works with a separate application instance. Created customization projects (with different names) can be sequentially uploaded to the customer's production application and employed as if all divided tasks had been resolved as a single common one.