Best practice developing processes

The purpose of this document is to provide best practice guidelines when developing in Version 7.

The following rules are considered ‘best practice’ when developing processes:

Naming convention

When adding a process to a data class or a representation class, Sage X3 People displays the default code. This code starts with the class/representation code. It is recommended that you use the default codes, and follow the same convention for any other process files. This will make it easier to find all processes for a particular data class or representation class.

Function and subroutine names

Use meaningful names. When dealing with a child class, prefix the subroutine and function names with the name of the child class. This will make clear which subroutine is for which class.

Comments

Use comments to explain your code. All comments must be in English.

Variable definitions

Define all variables in your functions and subroutines as Local. Do not define any global variables.

Error handling

Error handling must be carried out using the variable ASTATUS and the method ASETERROR. For example:

CODECODE CODE[L]ASTATUS=Fmet ASETERROR("AMOUNT","the amount has been successfully updated", [V]CST_AINFO)</code></pre>
CODECODE CODE[L]ASTATUS=Fmet ASETERROR("MYPROP","The value of MYPROP is exceeding a usual value", [V]CST_AWARNING)<pre><code></code></pre>
CODECODE CODE[L]ASTATUS=Fmet ASETERROR("","Global inconsistency for the class xxx", [V]CST_AERROR)<pre><code></code></pre>
CODECODE CODE[L]ASTATUS=Fmet ASETERROR("","A fatal error occured", [V]CST_AFATAL)

Use constants

Use standard constants. This makes code more readable. See Developer Guide Constants.

Single Entry/Exit point for functions and subroutines

You should have a single entry point and a single exit point for all functions and subroutines. You should also avoid using ‘Goto’ in your code.

Indent code

Indenting code makes it more readable.

Developing processes best practice summary