Browse Page
The browse page is configured to return a set of records in a collection.
Create the browse section with the same name as the function. The body table is the table you are going to perform the CRUD operations on.
Post Update has no effect on the REST interface but allows the UI to move to the summary page after updating a record in the browse – similar to normal Coins ERP+ UI.
The REST Collection Path is the unique path that will address this REST page (it will be appended to /rest/pages/). You can have tokens in the path (identified with {}) which will be assigned and then can be used as variables in the definition.
The body query is used to define the rows that will be returned.
Notice that {kco} is used in the query, this will be replaced with the value in the URL request.
The initial script is run before the start of the request. It allows you to prepare any data that might be required by the REST interface. E.g. it might set variables in preparation for createAssign() to set values in a new record.
The body calculation is executed before each body insert is performed. It allows the variables to be set specific to the row being processed from the insert. In the example above it is setting a variable b to a string value equal to the input jsc_cc field. This might be useful to for example find a header record and set its RSP before adding a record to the body table.
The body form defines the fields that will be returned in the collection.
The record header form defines the fields that are used to uniquely identify a record in the body table (for a delete).
The update form defines the fields that will be available for update in the creation of new records.
They can all be linked to other pages (as shown) and are typically linked between the browse and summary pages where the same fields are required.
Fields in the body define the fields that will be returned in the REST collection in response to a request to the endpoint specified.
A sort order can be specified on a field to enable sorting of the returned records in the collection.
The definition is the same as would be used on a normal Coins ERP+ page.
The id field can be used to override the name of the field presented to the REST interface. For example you might have a field sdb-key in sysdb which you want to present to the REST interface as kco. This can be done by putting sdb-key in the field and kco in the id. The REST values in the JSON will be kco but internally the sdb-key field will be used.
Named filters can be defined. These will be presented as filter options in the REST interface. They are defined in the same way as named filters on a Coins ERP+ page.
Browse filters can also be defined in the same way as a Coins ERP+ page. They will be presented in the REST interface as filter options.
The resulting page can be run in Coins ERP+.
The link on the Cost Head field is defined like a normal Coins ERP+ link and links to the summary page (below).
The Add button allows a record to be added with the field from the record header form (the key) and the update form. This mimics the capabilities of the REST interface for this page.
Summary Page
The summary page is defined to allow the REST interface to address a single record/object in the body table.
It is defined like a summary page in Coins ERP+. The header table and body table are set the same and the summary page option is selected. The Next button option is not used by the REST interface but allows the Coins ERP+ UI to behave normally.
The REST entity path is a unique path to address this record. Again, the URL contains tokens (identified with {}) that are specified in the URL and made available as variables in the application.
Similar to the browse page the record header is defined with the fields that are required to identify the record and the update form with the fields that are required to be updateable. Both these are typically linked to the summary page equivalent forms).
The detail form defines the fields that will be returned in response to the actions on this path. The forms can point to a different set of fields (as in Coins ERP+) so that in the example the Update fields are also used to return the results in the Detail form.
The fields in the form define the fields that should be presented to the REST interface. The id field can be used to change the name of the field in the REST interface whilst retaining the field name in the workings of the page.