The API gives us two functions to get information about what is accessible by the user.
The List Types method will give us a list of module names the currently connected user has access to. The result is an array called “types” with the list of module names. Notice how this script includes the doLogin script, so we are logged in on each call. https://github.com/tsolucio/coreBOSwsDevelopment/blob/master/testcode/090lib_listtypes.php
If you look at the List Types profile in the reference guide you will see that it has no parameters, but the reality is that it does have one.
The Describe service gives us detailed information of the module which we are trying to access. It will inform us both of the types of actions permitted and all the information of the fields which we have access to. This is extremely important as it is the only way to obtain the objectid of a module. In the introduction I explained that each record in webservice has a unique identifier composed of the module webservice id and the record's crmid. The Describe service returns the module id we need to construct this unique identifier. In our example we accept a parameter in the browser called “modulename”, if this parameter is given we will retrieve all the information of that module if the connected user has access to it. If the parameter is left empty we will try to access the Contacts module. https://github.com/tsolucio/coreBOSwsDevelopment/blob/master/testcode/080_describe.php
The object returned by this service can be consulted in the reference guide but basically contains:
1. label – label name of the module. 2. name – internal name of the module. 3. createable – boolean value indicating if the connected user can create new records. 4. updateable - boolean value indicating if the connected user can update existing records. 5. deleteable - boolean value indicating if the connected user can delete existing records. 6. retrieveable - boolean value indicating if the connected user can retrieve records. 7. fields - an array which contains all the accessible fields and their related information. Each field has these values: 1. name – internal fieldname. 2. label – label name. 3. mandatory – boolean value which indicates if it is mandatory on creation or not. 4. type – array with field data type information. 5. default – the default value of the field. 6. nillable – boolean value indicating if the field can be empty. 7. editable – boolean value indicating if the field can be modified.
The API gives us a way of executing the basic operations of Create, Retrieve, Update and Delete against any module installed in the associated coreBOS. Obviously permission restrictions exist for the connected user as if he were inside coreBOS itself.
Creates a new record in the application.
Get all the values of an existent record in the application. Given a webservice ID of a record this service will return an array with all the fields and their values. All reference type fields which are pointing to another record will have valid webservice IDs. In all retrieve operations a special field called ID is included which contains the webservice ID for that record.
This service updates ALL the fields of a given record. Once again; ALL FIELDS. The API does not support updating of individual fields, so, in many cases updating becomes a two step operation; first retrieve all the records, assign the new values leaving the others untouched and update the whole record.
With this service we can eliminate any record we have permission to delete.
The main difference between vtws_revise and vtws_update is that for revise you can send only those fields that need to be changed, but for update API you need to send all the mandatory fields to update a record. If you send unknown fields then it will silently ignore them, the reason for this behavior is that the user may not have permission for few fields and the system may not know if these fields are not available in the system or the user does not have permission for these fields.