DC1 Objects Naming Reference

This section describes recommended naming rules for all objects and names connected to API programing in DC1.

DC1 Back end naming standard

Name of object is related to its functionality. All programs implementing the functions of the existing applications and called from manager programs should have names in accordance with back end naming convention (for DC1 e.g. DI*, DM*, DS*… for DIS, GDM* for GEN….). Unlike the standard applications, program manager names and related files should start with three-character prefix MGR. For customer modifications the name of program should start with Z* (example: Z1MGRR001)

For example for DC1 distribution (DIS) it will be:

  • DIR* or DMR* or DSR*… - API RPGLE black box program
  • DIL* or DML* … - API externally described parameter lists for black box
  • MGRR* - API RPGLE manager program standard DC1
  • ZnMGRR* - API Rpgle manager program which is created as customer modification

NOTE: Object names started with IA* are reserver for Aperio.

APIBNDDIR - This binding directory must be added to program during compilation. This is only for “manager” programs. It means programs which get JSON parameters and build JSON response. The default compilation options should be changed for these programs. See example bellow:

DFTACTGRP(*NO) ACTGRP(*CALLER) BNDDIR(ASWBNDDIR IBSBNDDIR APIBNDDIR) OPTION(*NODEBUGIO) DBGVIEW(*ALL) CVTOPT(*DATETIME) SRTSEQ(*JOBRUN)

There is one service program IAFS0001 in Iptor API Framework. This service program contains set of communication tools, JSON Parser and JSON builder.

There are two common objects:

  • MGRAPISRC - Common source member for all manager programs.
  • IAFLAPI - Common parameter list for all manager programs

API Method names

There is general rule how the methods should be named. First it should stick to JAVA naming rules for variables:

  • All method names must contailn only a letter of the alphabet, and dot sign (.). It is possible ti use underscore, or ( _ ), or a dollar sign ($). The convention is to always use a letter of the alphabet and dot. The dollar sign and the underscore are discouraged.
  • After the first initial letter, method names may also contain letters and the digits 0 to 9. No spaces or special characters are allowed.
  • The name can be no longer that 60 characters. Remember that you will have to type this name :o)
  • Uppercase characters are distinct from lowercase characters. Remember that method names are case-sensitive.
  • You cannot use a java keyword (reserved word) for a method name.
  • It is forbiden to use Aperio reserverd names. See aperio objects naming conventions.

There are some recommendations. We recommend to use long method names with dot “.” in between. The first part of method it should describe the “object”. For example “salesOrderLine” or “itemBatch” etc… The second part (after dot) should represent verb or rather action name. For example “.get” or “.update” etc… The main recommendation is to use “lower camel case” standard for coding method names.

Examples:

  • itemBatehes.get - This method retrieves all batches for item. The result will be multiple records
  • itemBatch.get - This method retrieves detail batch information for one item/batch
  • salesOrderLine.add - This method adds sales order line
  • salesOrderLine.update - This method updates sales order line

NOTE: The method name is case sensitive! The method name is limited to 60 characters.

Field names in JSON

All fields in JSON string should be “long” (self-descriptive). We propose to use alias defined for field name in field reference. List of parameters assigned to API method is defined in “API metadata”. The main recommendation is to use “lower camel case” standard for coding method names.

To avoid situation when warning/error messages generated by standard DMUR/DMR… programs refers to ‘short’ FRF names, for each long field parameter is possible to define list of linked short FRF fields. That list is used to translate ‘short’ FRF names in error/warning messages received from standard programs, to ‘long’ aliases used in API messages.

The recommendation is to not use reserved field names which are described in JSON structure. Although the structure of JSON allows to use the same field names. Each field is read in context. For JSON structure both: request and response see document “Iptor API Framework - JSON structure.docx”.

Vocabulary

JSON: http://www.json.org/