Development rules
Glossary Item Box
Introduction
During the creation of new functionality, bpm’online developers and partners have compiled a set of rules and recommendations. Development can be carried out by several employees simultaneously in personal development environments. Any employee with the appropriate skills can act as a developer.
Minimal required developer skills
Over 6 months of C#, JavaScript, and T-SQL (PL-SQL) programming experience.
Recommended developer skills
Over a year of C#, JavaScript and T-SQL (PL-SQL) programming experience. Expertise in WCF and OData technologies, as well as Sencha Ext.JS framework and RequireJS library.
Development rules and recommendations
Using a development environment
New functionality must only be developed in the development environment. It is forbidden to develop new functionality in a pre-production or production environment.
Developing in a configuration
The development should be carried out only in the development database in the default workspace (the [Default] configuration, sequence number 0). Developing in custom configurations is not recommended, even in case of minor changes that will not be delivered to other users.
Developing in a custom package
The development of new custom bpm’online functionality must be carried out in a separate custom package. Do not use the [Custom] package. All the necessary data (for example, lookup contents content), SQL-scripts and dependencies must be attached to the package.
Using the SVN
If the development is carried out by several developers, you must use the revision control system (SVN). When the development is carried by a single developer, it is recommended to use SVN.
Identification of the solution provider
To prevent errors associated with same package element names and their properties created by different vendors, use the following system settings:
- [Publisher] (Maintainer) - contains the package vendor name. The default value is set to “Customer”.
- [Object name prefix] (SchemaNamePrefix) contains a prefix installed in the custom schema names and names of custom columns in the objects that are inheritors to the system objects. The default value is set to “Usr”.
Using the extending and replacing modules and schemas
If you want to create a extending view model schema (for example, schema of the section record edit page), you need to add only the differences from the parent schema. Most often, those are the new attributes, methods, events, and the diff array of modifications. You must only add only new view models that are not in the parent schema to the diff array of modifications.
If you need to create a replacement module, you need to copy the module’s source code, which is replaced, and to add a new functionality. Bpm’online modules cannot be expanded.
NOTE
The [Configuration] section contains the same [Add] — [Replacing Client Module] command for creating extending and replacing schemas. That is why extending schemas are also called "replacing".
Using localizable strings
It is forbidden to use string literals in the schema source code. All string values that are displayed in the user interface must be presented as localizable strings. This is important for localization of solutions.
Data backup
Before moving changes to the production environment, it is imperative to create a backup copy of the database. The database must be backed up before installing updates and solution from third-party developers.
