You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The following entity APIs are provided: Asset, Authority, Lookup, Repair Order, User, and Work Order. These entities are described in more detail in the following sections.

Asset

Use the Asset API entity to work with assets in the AgileAssets system as well as inventories associated with the assets. This entity allows both GET and POST calls.

The following GET calls may be made to request data from the AgileAssets system via the API:

{baseURL}/asset

This call retrieves all asset types in the system. An example of this type is shown below:

http://vega:8080/ams_ky/rest/v1/asset?q={"projection":["ASSET_TYPE_ID", "ASSET_TYPE_NAME"],"page":{"number":4,"size":2}}  


 {
 "SETUP_ASSET_TYPE": [
 {
"ASSET_TYPE_ID": 3,
"ASSET_TYPE_NAME": "Equipment"
},
 {
"ASSET_TYPE_ID": 5,
"ASSET_TYPE_NAME": "Employee"
}
]
}  


{baseURL}/asset/{id}

This call retrieves asset type information for a particular asset ID. An example of this type is shown below:

http://vega:8080/ams_ky/rest/v1/asset/639 

{
ASSET_TYPE_ID: 639,
ASSET_TYPE_NAME: "Signals",
PARENT_ID: 2,
LEVEL_ID: 3,
INVENTORY_TABLE_NAME: "SIGNAL_INVENTORY",
NUM_CHILD: 0,
USER_UPDATE: "EUGENE",
DATE_UPDATE: "20110531173140",
ORDER_ID: 50,
PM_APPL: 1,
DEFECT_SURV_APPL: 0,
LOCATION_APPL: 1,
MODULE_ID: 3,
INVENTORY_MEASURE_EXP: "1"
}


 {baseURL}/asset/{name}

This call retrieves the header inventory table for the asset with name {name}. This is not case sensitive. If the name contains spaces or slashes, omit them entirely in the URL. An example of this type is shown below:

http://vega:8080/ams_ky/rest/v1/asset/sign

{
ASSET_TYPE_ID: 6,
ASSET_TYPE_NAME: "Sign",
PARENT_ID: 1,
LEVEL_ID: 2,
INVENTORY_TABLE_NAME: "SIGN_INVENTORY",
NUM_CHILD: 0,
USER_UPDATE: "BABAK",
DATE_UPDATE: "20100909121727",
MODULE_ID: 3,
MOBILE_LAYER_NAME: "ASSET_LOC_POINT"
}


{baseURL}/asset/{name}/parent

This call retrieves the parent asset type for an asset with name {name} Note: This is not case sensitive. If the name contains spaces or slashes, omit them entirely in the URL. An example of this type is shown below:

http://vega:8080/ams_ky/rest/v1/asset/walls/parent 

{
ASSET_TYPE_ID: 2,
ASSET_TYPE_NAME: "Road Sections",
PARENT_ID: 1,
LEVEL_ID: 2,
INVENTORY_TABLE_NAME: "SECTION_INVENTORY",
NUM_CHILD: 0,
USER_UPDATE: "EUGENE",
DATE_UPDATE: "20110531173148",
ASSET_TYPE_CAT: 2,
ORDER_ID: 1,
PM_APPL: 1,
DEFECT_SURV_APPL: 1,
LOCATION_APPL: 1,
MODULE_ID: 3,
INVENTORY_MEASURE_EXP: "1"
}

{baseURL}/asset/{id}/parent

This call retrieves the parent asset type for asset with ID {id}. An example of this type is shown below:

http://vega:8080/ams_ky/rest/v1/asset/963/parent 

{
ASSET_TYPE_ID: 2,
ASSET_TYPE_NAME: "Road Sections",
PARENT_ID: 1,
LEVEL_ID: 2,
INVENTORY_TABLE_NAME: "SECTION_INVENTORY",
NUM_CHILD: 0,
USER_UPDATE: "EUGENE",
DATE_UPDATE: "20110531173148",
ASSET_TYPE_CAT: 2,
ORDER_ID: 1,
PM_APPL: 1,
DEFECT_SURV_APPL: 1,
LOCATION_APPL: 1,
MODULE_ID: 3,
INVENTORY_MEASURE_EXP: "1"
}

{baseURL}/asset/{id}/inventory

This call retrieves the  inventory table for an asset with this numeric ID. An example of this call is shown below:

http://vega:8080/ams_ky/rest/v1/asset/639/inventory

{baseURL}/asset/{name}/inventory

This call retrieves the header inventory table for the asset with name {name}. Note: This is not case sensitive. If the name contains spaces, tabs, line breaks, or slashes, omit them entirely in the URL. An example of this call for the Road Sections inventory is shown below (note that since "Road Sections" contains spaces, these are omitted in the call):

http://vega:8080/ams_ky/rest/v1/asset/roadsections/inventory

{baseURL}/asset/{id}/group

This call retrieves inventory class codes for the asset identified by the {id} asset ID. An example of this type is shown below:


{baseURL}/asset/{name}/group
This call retrieves all inventory class codes for the asset identified by the {name} asset name. An example of this type is shown below:


{baseURL}/asset/{id}/key
This call retrieves the inventory table key column name, where {id} is the numeric ID of the asset. An example of this type is shown below:


{baseURL}/asset/{name}/key
This call retrieves the inventory table key column name, where {name} is the name of the asset. An example of this type is shown below:


{baseURL}/asset/{id}/inventory/{invenId}
This call retrieves a particular inventory element {invenId} from an inventory table for the asset with the {id} id. An example of this type is shown below:


{baseURL}/asset/{name}/inventory/{invenId}
This call retrieves a particular inventory element {invenId} from an inventory table for the asset named {name}. An example of this type is shown below:


{baseURL}/asset/{id}/inventory/{invenId}/detail
This call retrieves details for a particular inventory element {invenId} from an inventory table for the asset with {id} id. An example of this type is shown below:



{baseUrl}/asset/{name}/inventory/{invenId}/detail
This call retrieves details for a particular inventory element {invenId} from an inventory table for the asset named {name}. An example of this type is shown below:

POST calls are made to create data in the AgileAssets system through the API. When a new item is created, the correct ID is returned to the caller (providing the inventory element ID via a POST call is useless because POST is assumed to only create data). The following POST calls are available:

  • {baseUrl}/asset/{id}/inventory
    This call creates new inventory element. The call should include:
    • Header: Content-Type: application/json
    • Data: JSON array that represents one or more records of the inventory table. The required fields are the minimum set of fields that may appear in the array (with the exception of ID fields that are assigned by the system).

For example, the following POST call will insert two sign assemblies (in this example, the URL provides the asset type ID and the system uses this to identify the correct inventory table name):

	curl -i -X POST -H 'Content-Type: application/json' http://localhost:8080/ams_dev/rest/v1/asset/638/inventory/ -d '[{"SIGN_NAME":"Alex Protyagov1"},{"SIGN_NAME":"Protyagov"}]'

The system returns the following: [2416662,2416661]

Authority

Use the Authority API entity to retrieve authorities from an AgileAssets system. This entity allows only GET calls.

The following GET calls may be made to request data from the AgileAssets system via the API:

{baseURL}/authority
This call retrieves records for authorities in the system. Use the projection of a Q object to limit the number of returned columns. An example of this call is shown below:
http://vega:8080/ams_la/rest/v1/authority

{baseURL}/authority/{id}
This call retrieves authorities for the administrative unit identified by the ID {id}. Use the projection of a Q object to limit the number of returned columns. An example of this type is shown below:


{baseURL}/authority/{id}/name
This call retrieves the name of a particular authority unit identified by the ID {id}. An example of this type is shown below:



{baseURL}/authority/{id}/labor
This call retrieves retrieves the labor inventory of a particular authority unit identified by the ID {id}. Use the projection of a Q object to limit the number of returned columns. An example of this type is shown below:



{baseURL}/authority/{id}/child
This call retrieves the child units of a particular authority unit identified by the ID {id}. An example of this type is shown below:


{baseURL}/authority/{id}/parent
This call retrieves the parent unit of a particular authority unit identified by the ID {id}. An example of this type is shown below:


{baseURL}/authority/{id}/user
This call retrieves the users assigned to a particular authority unit identified by the ID {id}. An example of this type is shown below:


{baseURL}/authority/{id}/labor/shortlist
This call retrieves the labor shortlist for a particular authority unit identified by the ID {id}. (Note: If {id} is omitted, the shortlists of all authority units is returned.) An example of this type is shown below:


{baseURL}/authority/{id}/equipment
This call retrieves the equipment shortlist for a particular authority unit identified by the ID {id}. (Note: If {id} is omitted, the shortlists of all authority units is returned.) An example of this type is shown below:


{baseURL}/authority/{id}/material/shortlist
This call retrieves the material shortlist for a particular authority unit identified by the ID {id}. (Note: If {id} is omitted, the shortlists of all authority units is returned.) An example of this type is shown below:


{baseURL}/authority/{id}/project
This call retrieves projects that belong to particular owner identified by {id}. (If {id} is omitted, all projects of all authority units are returned.) An example of this type is shown below:


{baseURL}/authority/{oid}/project/{pid}
This call retrieves a project identified by {pid} that belongs to particular owner identified by {oid}. (If {pid} is omitted, all projects for the identified owner are returned. If {oid} is omitted, all projects identified by {pid} are returned.) An example of this type is shown below:


{baseURL}/authority/{oid}/project/{pid}/asset/{iid}
This call retrieves the asset identified by {iid} associated with the project identified by {pid} that belongs to particular owner identified by {oid}. (The {iid}, {pid}, and {oid} terms are optional. If the {iid} term is omitted, all assets associated with project {pid} are returned. If {pid} is omitted, either asset(s) for all projects for the identified owner are returned. If {oid} is omitted, all assets for all projects identified are returned.) An example of this type is shown below:


{baseURL}/authority/{oid}/project/{pid}/asset/{iid}/activity/{aid}
This call retrieves the asset identified by {iid} associated with the activity identified by {aid} performed in the project identified by {pid} that belongs to particular owner identified by {oid}. (The {aid}, {iid}, {pid}, and {oid} terms are optional.) An example of this type where all optional terms are included is shown below:


Another example where all optional terms other than asset ID are omitted is shown below:

Lookup

Use the Lookup API entity to extract metadata. For example, mapping column IDs to the actual labels that a user wants to see on his or her computer or obtaining error messages by their IDs. This entity allows only GET calls.

The following GET calls may be made to request data from the AgileAssets system via the API:
{baseURL}/lookup/column
This call retrieves all column metadata from the system as an object. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this call is shown below:


{baseURL}/lookup/column/{id}
This call retrieves column metadata for the column identified by {id} as a collection. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this call is shown below:


{baseURL}/lookup/column/{id}/map
This call retrieves the key-value-pair object that represents all possible values for the particular column identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this call is shown below:


{baseURL}/lookup/column/{id}/map/{idd}
This call retrieves the key-value-pair object that includes the value {idd} for the particular column identified by {id}. This call is useful for performing quick-search functions such as for type-ahead controls. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this call is shown below:


{baseURL}/lookup/column/{id}/value
For columns of view type T (List) or H (Huge List), this call retrieves the values to populate the list. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this call is shown below:


{baseURL}/lookup/column/{id}/barcode/{bc}
For columns of view type T (List) or H (Huge List) whose look-up tables contain bar codes, this call retrieves the values-key/value map that matches the bar code. The search for the specified bar code is performed in both keys and values, with all matches being returned. An example of this call is shown below:

Repair Order

Note: The Repair Order API entity will only function if the Fleet Management module is part of the AgileAssets system being queried and only if that module is assigned a module ID of 5. (This is because repair orders are only used in the Fleet Management module.)

Use the Repair Order API entity to work with repair orders in the AgileAssets Fleet Management module. This entity allows GET, POST, PUT, and DELETE calls.

The following GET calls may be made to request repair order data from the AgileAssets system via the API:
{baseURL}/repairOrder
This call retrieves all repair orders in the Fleet Management module. Use the projection of a Q object to prevent the amount of returned data from being excessive. (If input Q does not specify pagination, a default one will be used.) An example of this type is shown below:


{baseURL}/repairOrder/{id}
This call retrieves the repair order identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/search/{word}
This call retrieves all repair orders that have {word} in a vehicle's name, plate, or VIN. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/barcodesearch/{word}
This call retrieves the repair orders that contain the bar code {word}. Use the projection of a Q object to prevent the amount of returned data from being excessive.


{baseURL}/repairOrder/{id}/DirectCost
This call retrieves the direct costs for the repair order identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/{id}/DirectCost/Sum
This call retrieves the sum of labor and equipment costs for all direct costs associated with the repair order identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/DirectCost/{id}
This call retrieves the direct cost identified by particular direct cost record ID number {id} as a JSON object. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/{id}/vendor
This call retrieves the vendor information for the repair order identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive.


{baseURL}/repairOrder/vendor
This call retrieves all vendors in the Fleet Management module. Use the projection of a Q object to prevent the amount of returned data from being excessive.


{baseURL}/repairOrder/vendor/map
This call retrieves all vendors in the Fleet Management module where each element is a JSON object key-value-pair or vendor ID to vendor name. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/vendor/map/{id}
This call retrieves all vendors in the Fleet Management module where each element is a JSON object key-value-pair or vendor ID to vendor name and where the vendor name contains the string given in {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/{id}/activity
This call retrieves all activities performed in the repair order identified by {id}. At most, two fields are returned: ID and name of activity. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:


{baseURL}/repairOrder/{id}/warranty
This call retrieves all active warranties for the repair order identified by {id}. Use the projection of a Q object to prevent the amount of returned data from being excessive. An example of this type is shown below:

When a new item is created, the correct ID is returned to the caller. Hence, providing the inventory element ID via a POST call is useless because POST is assumed to only create data.
The following POST calls may be made to the Fleet Management module via the API:

{baseURL}/repairOrder
This call creates a new repair order. The inputs should include:

  • Header: Content-Type: application/json
  • Data: JSON object that represents a new repair order. The system automatically sets MODULE_ID to be 5 and the STATUS to be 4. The PROJECT_ID is assigned as the next one in sequence. The PROJECT_NAME is required, along with any other required fields.

The output is a JSON array of new PROJECT_ID values. It also automatically creates inventory PM activities for today.
An example of this type is shown below:



{baseURL}/repairOrder/{id}/warranty
This call creates warranty information for the already-existing repair order {id}. The inputs should include:

  • Header: Content-Type: application/json
  • Data: JSON object that represents a new warranty record. It must contain EQUIPMENT_WARRANTY_NAME; EQUIPMENT_ID; WARRANTY_LENGTH_DAY or/and WARRANTY_LENGTH_DAY; EFF_DATE; and START_ODOMETER.

The output is a JSON array of new WARRANTY_ID values.

{baseURL}/repairOrder/{id}/directcost
This call creates a direct cost record(s) for the already-existing repair order {id}. The inputs should include:

  • Header: Content-Type: application/json
  • Data: JSON object or JSON array of objects that represents the direct costs. The minimum set of fields is the required fields (with the exception of the ID fields automatically created by the system).

The output is a JSON array of new RECORD_ID values for newly created direct costs.

The following PUT calls may be made to modify records in the Fleet Management module via the API:

{baseURL}/repairOrder/{id}
The call updates the particular repair order that is identified by {id}. The input should include:

  • Header: Content-Type: application/json
  • Data: JSON object that represent record fields that are to be updated. Only those fields in the input JSON object should be updated in database.

The output is an HTTP status code unless there is an error.

{baseURL}/repairOrder/{id}/directcost
The call updates the direct costs associated with the particular repair order that is identified by {id}. The input should include:

  • Header: Content-Type: application/json
  • Data: JSON object or array of objects that represent record fields that are to be updated. Only those fields in the input JSON object should be updated in database. It must contain the RECORD_ID field and it cannot be null.

The output is an HTTP status code unless there is an error.

The following DELETE calls may be made to delete data in the Fleet Management module via the API:

{baseURL}/repairOrder/{id}
The call deletes the repair order that is identified by {id}. The operation will fail if the repair order is approved or if any of the day cards associated with the repair order are approved.
The output is an HTTP status code unless there is an error.


{baseURL}/repairOrder/directcost/{id}
The call deletes the direct cost records associated with the repair order that is identified by {id}. The operation will fail if the records are approved.
The output is an HTTP status code unless there is an error.


{baseURL}/repairOrder/{id}/activity/{idd}
The call deletes the activity records identified by {idd} associated with repair order {id}. The operation will fail if the records are approved.
The output is an HTTP status code unless there is an error.

User

Use the User API entity to retrieve user information from an AgileAssets system. User IDs are stored in upper case in the AgileAssets database, but the URL is not case sensitive and therefore the User ID may be written in any case. This entity allows only GET calls.

The following GET calls may be made to request user information from the AgileAssets system via the API:
{baseUrl}/rest/v1/user/{id}
This call retrieves the user record for the User ID identified by {id}. (The USER_PASSWORD field is not returned.) Use the projection of a Q object to limit the number of returned columns. An example of this call is shown below:
http://vega:8080/ams_la/rest/v1/authority

 
{baseUrl}/rest/v1/user/{id}
This call retrieves the user record for the User ID identified by {id}. (The USER_PASSWORD field is not returned.) Use the projection of a Q object to limit the number of returned columns. An example of this call is shown below:


{baseUrl}/rest/v1/user
This call retrieves all user records. (The USER_PASSWORD fields are not returned.) Use the projection of a Q object to limit the number of returned columns. An example of this call is shown below:


{baseUrl}/rest/v1/user/{id}/authority
This call returns the mapping between OWNER_ID and OWNER_NAME for a user identified by {id}. An example of this call is shown below:


{baseUrl}/rest/v1/user/{id}/authority/id
This call returns the authority IDs to which the user identified by {id} is assigned. An example of this call is shown below:


{baseUrl}/rest/v1/user/{id}/authority/name
This call returns the authority names to which the user identified by {id} is assigned. An example of this call is shown below:

Work Order

Use the Work Order API entity to work with work orders in the AgileAssets system. This entity allows GET, POST, PUT, and DELETE calls.

The following GET calls may be made to request work order data from the AgileAssets system via the API:
{baseUrl}/workOrder/<workOrderId>/DayCard/<DayCardType>/<Year>/<Month>/<Day>
This call retrieves work orders, with the parameters determining which work orders are returned. (Q objects may also be used to determine what is returned.) The following parameters are available in this call:

  • workOrderId – This parameter is optional. When given, it is the ID of the work order whose data is to be returned.
  • DayCardType – This parameter is optional. When given, it determines what type(s) of day cards will be returned rather than all day cards. The valid values are: labor, equipment, cost, location, material, contract, and accomplishment. More than one value may be specified.
  • Year – This parameter is optional. When given it is the four-digit year of the start date of the work order(s).
  • Month – This parameter is optional. When given it is the two-digit month of the start date of the work order(s).
  • Day – This parameter is optional. When given it is the two-digit day of the start date of the work order(s).

Note: The data is retrieved from the Day Cards table. If the Day Cards table does not exist, an error is not returned.

The response is a JSON array of JSONObjects. Each object is always a single pair of {key:value}, where key is the field name and value is the field value of this record.
Following are several examples of GET calls for this type:
o To retrieve data for work order 1273:
http://localhost:8080/ams_dev/rest/workOrder/1273
o To retrieve all day cards for work order 1273 that were created in 2010:
http://localhost:8080/ams_dev/rest/v1/workOrder/1273/DayCard/2010
o To retrieve all day cards created in 2010:
http://localhost:8080/ams_dev/rest/v1/workOrder/daycard/2010
o To retrieve all day cards created in September 2010:
http://localhost:8080/ams_dev/rest/workOrder/daycard/2010/09
o To retrieve all equipment day cards:
http://localhost:8080/ams_trunk/rest/v1/workorder/daycard/equipment
o To retrieve equipment day cards created on September 16, 2010:
http://localhost:8080/ams_dev/rest/workOrder/DayCard/equipment/2010/09/16
o To retrieve all day cards in the system:
http://localhost:8080/ams_dev/rest/workOrder/DayCard/
o To retrieve all contract day cards in the system:
http://localhost:8080/ams_dev/rest/workOrder/DayCard/Contract
o To retrieve all approved labor day cards in the system:
http://localhost:8080/ams_dev/rest/workOrder/DayCard/labor?q=\{filter:[[APPROVED,'=',1]]}
o To retrieve all approved cost day cards in the system created in 2010:
http://localhost:8080/ams_dev/rest/workOrder/DayCard/cost/2010?q=\{filter:[[APPROVED,'=',1]]}
{baseUrl}/workOrder
This call retrieves a collection of work orders. Rather than using parameters as in the previous call, you only use a Q object to determine what data is returned. Several examples of using Q objects are provided below.
To retrieve the fourth page of a set of work orders where two records appear on each page:



To retrieve the seventh page of a set of work orders with four records on each page:



To retrieve two fields of each open work order and sort by START_DATE column:



{baseUrl}/workOrder/project/{id}
This call retrieves all work orders for the project identified as {id}. An example of this call is shown below:

POST calls create work orders and/or day cards. Creating a work order via a POST call creates a new work order and assigns it a new ID, which is returned to the client as a JSON array. Creating a day card via a POST call inserts a day card for a given work order ID. The ID is provided in the URL string or, when provided in a JSON array, in the request object. The advantage of creating a day card via a POST call rather than a PUT call is that a POST call always inserts a day card and so if a day card already exists, the operation would fail.
The following POST calls may be made to the AgileAssets system via the API:
{baseUrl}/workOrder
This call creates a new work order. The inputs should include:

  • Header: Content-Type: application/json
  • Data: JSON object that represents a single new work order or a JSON array of multiple new work orders. The minimum set of fields is the required fields, except for the ID fields that the system automatically sets. Depending on the client, the usual set of required values are project, asset, activity, and sub-activity.
Note: Other constraints may exist on the server, such as triggers, that must be satisfied to successfully create a record. This is client-specific functionality.

An example of this type is shown below:
curl -i -X POST -H "Content-Type: application/json" http://localhost:8080/ams_dev/rest/v1/workOrder -d '{"PROJECT_ID":1213,"ASSET_TYPE_ID":638,"ACTIVITY_ID":408}'
{baseUrl}/workOrder/{id}/DayCard
This call creates a new day card for the already existing work order identified by {id}. The inputs should include:

  • Header: Content-Type: application/json
  • Data: JSON array that represents the collection of JSON objects, one object per day card. Each of those objects is identified by key, day card table name and each of those objects value is a JSON array that represents the collection of day card records. The minimum set of fields is the required fields with the exception of the ID fields that are assigned by the system. Depending on the client, the usual set of required values is project, asset, activity, and sub-activity.

For example, to insert a labor day card with one employee for work order 1643, use the following POST call:
curl -i -X POST -H 'Content-Type: application/json' http://localhost:8080/ams_dev/rest/v1/workOrder/1643/DayCard/ -d '{"WORK_ORDERS_LABOR_DC":[{"LABOR_ID":2412555,"DATE_WORK":"20130314","TOTAL_HOURS":0.5,"TRC_ID":1}]}'

Note: Errors are file-driven.

The aim of PUT calls is to update already existing work orders and day cards. Updating a work order via a PUT call modifies an existing work order. Updating a day card via a PUT call modifies an existing day card for a given work order ID. The ID is provided in the URL string or, when provided in a JSON array, in the request object.
The following PUT call may be made to the AgileAssets system via the API:

{baseURL}/rest/workOrder/{workOrderId}/DayCard/
This call updates an existing work order and day card.
Two examples of this PUT call are shown below:

Note: The JSON Object must include all columns that are part of the Primary Key. Also, since the WORK_ORDER_ID is given via the request URL, if the JSON Object also included WORK_ORDER_ID, it would be ignored.

Use the following DELETE calls to delete data in the AgileAssets system via the API:
{baseUrl}/workOrder/{id}
The call deletes the work order that is identified by {id}. Only one work order may be specified. The operation will fail if the work order is approved or if any of the day cards associated with the work order are approved.
For example, to delete work order 1620, use the following DELETE call:
curl -i -X DELETE http://localhost:8080/ams_dev/rest/workOrder/1620


{baseUrl}/workOrder/{id}/DayCard/{type}/{year}/{month}/{day}
The call deletes the day card records associated with the work order that is identified by {id}. The {id} parameter is required, but the other parameters are optional. (When provided, they specify the type of day card to be deleted and/or the date when the day cards were created.) The operation will fail if the records are approved.
See two examples of DELETE calls below:

  • No labels

Provide Feedback