User Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
en:devel:corebosws:methodreference [2015/10/24 18:49]
127.0.0.1 external edit
en:devel:corebosws:methodreference [2020/07/22 18:13] (current)
gmoshi [Retrieve Attachment]
Line 2: Line 2:
  
 =====Retrieve Attachment===== =====Retrieve Attachment=====
-^Purpose:​|Retrieve file attached ​to a document as a base64 encoded stringThis method ​was added instead ​of modifying ​the already existing Retrieve method ​to avoid having to download all attachments when only a list is required and so we wouldn'​t have to modify ​the existing interface ​of the retrieve method.| +The API gives us two functions ​to get information about what is accessible by the user. 
-^Profile:|retrievedocattachment(id:​Id,returnfile:boolean):​Map| +=====List Types===== 
-^Send as:|POST| +The List Types method ​will give us a list of module names the currently connected user has access ​to
-^Parameters:​|<​code>​ id: comma separated list of document identifiers ​to obtain +The result ​is an array called “types” with the list of module names. 
- returnfile: true if we need to really get the filefalse to just get the information of the attachment</​code>​| +Notice how this script includes ​the doLogin script, so we are logged in on each call
-^Response:|A map object ​with all the information of the attachment| +https://​github.com/​tsolucio/​coreBOSwsDevelopment/​blob/​master/​testcode/​090lib_listtypes.php 
-^URL Format:​|<​code>​http://corebos_url/​webservice.php?operation=retrievedocattachment&​sessionName=[session id]&id=[id documento]&​returnfile=[0|1]</code>| + 
-^Examples:|[[en:​devel:​corebosws:​docenhance_examples|REST Document Manipulation Enhancements]]|+ 
 +=====Restricted List Types===== 
 +If you look at the List Types profile in the reference guide you will see that it has no parametersbut the reality is that it does have one. The correct profile for this service is
 + 
 +=====Describe===== 
 +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. 
 +=====CRUD===== 
 + 
 +==== Users ==== 
 + 
 +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. 
 + 
 +====Create==== 
 +Creates a new record in the application. 
 + 
 +https://github.com/tsolucio/​coreBOSwsDevelopment/​blob/​master/​testcode/​028lib_createUser.php 
 + 
 +====Retrieve==== 
 +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. 
 + 
 +https://​github.com/​tsolucio/​coreBOSwsDevelopment/​blob/​master/​testcode/​040lib_retrieve.php 
 + 
 +====Update==== 
 +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. 
 + 
 +https://​github.com/​tsolucio/​coreBOSwsDevelopment/​blob/​master/​testcode/​060lib_updateUser.php 
 + 
 +====Delete==== 
 +With this service we can eliminate any record we have permission to delete. 
 + 
 +https://​github.com/​tsolucio/​coreBOSwsDevelopment/​blob/​master/​testcode/​070lib_deleteUser.php 
  
 =====Revise===== =====Revise=====
  
-The main difference between vtws_revise and vtws_update is that for revise you can send only those fields that needs to be changed, but for update ​api you need to send all the mandatory fields to update a record. ​+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. 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.
 +