Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 6 Next »

Getting Started with the API

PCR-360 offers a REST API which allows an outside application to search and make use of your raw data. Using the API, you may retrieve your current Services, Cable, GLA, Equipment, and Service Desk records. Experience in software development is required.

To use the API, you'll need a unique API Key, which is used to identify yourself to the PCR-360 server and to protect your data. API keys are assigned permissions that dictate the API access. These are available on the API Permissions page. (Note: Do not share this unique key.)

Installations using the Shibboleth single sign-on integration for authentication will require an alternate URL/domain to make HTTP(s) requests to the API.

API Response Codes

Here is the list of Response Status Codes the API might return to your Requests.

Status

What it means

200

The Request was received and executed successfully.

400

The Request was received, but contained Bad Data, so was not executed.

401

The Request was received, but your User permissions are not authorized to perform the requested operation.

403

The Request was received, but you lack the User permissions to perform the requested operation.

404

The Request was received, but the desired End Point was not found.

405

The Request was received, but you are not allowed to perform the requested operation.

503

This Response indicates PCR-360 is presently unavailable, and likely is in a Maintenance Window.


Configuring REST Headers

Depending on the desired formatting of the request, there are two headers that can be sent. Depending on the 'Access Mode' for a User's Requests, other headers may be required.  Please see the API Permissions page for more details

Content Type: JSON

Encoding as JSON can be useful, but by default all API parameters are passed formatted as query-strings.

To activate JSON Content Encoding on a request, a header needs to be added to the request:

Content-Type:application/json

HTML Decoding

Special characters can be decoded on a per request basis. If special characters are being sent in your request, you can pass a special header to tell the API to decode each parameter.

To activate HTML decoding on a request, a header needs to be added to the request:

Pcr-Html-Encoded:true

Logging

Logging can be enabled on a per request basis. This can be useful for debugging purposes; it will return a copy of the parameters that were submitted in the request.

To activate logging on a request, a header needs to be added to the request:

Pcr-Debug-Api:true


If the logging header is provided and the value is "true", the API Request will be returned in the response.

    <equipment>
        <status>success</status>
        <page>1</page>
        <count>20</count>
        <total_count>3174</total_count>
        <equipment> ... </equipment>
    </equipment>
    <debug> .... </debug>

Output Formats

There are three formats the API can use for return data.

We currently offer JSON , PHP , and XML output formats.
(PHP returns a serialized array which can be converted back to an array using the unserialize() function)

What a Request Looks like

A basic request looks like this:

CALLTYPE http://DOMAIN/api/API_KEY/REQUEST.OUTPUT


In this basic request example, a user of the API would replace the following:

Parameter

Replace With

CALLTYPE

We support GET and POST call types, depending on the type of request.

DOMAIN

The URL used to access your PCR-360 application

API_KEY

The unique key generated by your admin

REQUEST_TYPE

The type of request being made. Recommended type is "sql". Other available (deprecated) types are: "servicedesk", "services", and "equipment"

OUTPUT

The desired output format.

More specific requests can be done by attaching more fields at the end of the URL in a query string:

GET http://DOMAIN/api/API_KEY/REQUEST_TYPE.OUTPUT?field1=value1 ...

Reading Data

When reading data via the API, the recommended method is to use the "sql" REQUEST type and specify a raw SQL query in the request. This will return the results of the SQL query in the response.

Request Types

SQL

The recommended method for reading data in the API is using the SQL REQUEST type. This allows you to specify a raw SQL query to the API and get back the results in the specified format. The SQL API request requires using the POST HTTP method.

Using CURL this example queries all records in the SERVICES table and specifies the content type is JSON encoded and requests data returned JSON encoded:

curl -X POST -d '{"sql":"SELECT * FROM SERVICES"}' http://DOMAIN/api/API_KEY/sql.json -H Content-Type:application/json


Using cURL this example queries all records in the SERVICES table using the default content encoding of HTTP query string parameters and requests data returned in XML format:

curl -X POST -d "sql=SELECT * FROM SERVICES" http://DOMAIN/api/API_KEY/sql.xml


For more details, see API:SQL .

Cable

This REQUEST type is deprecated.

The cable REQUEST type allows access to PCR-360 Cables and related data. View full details on Cable API Calls.

Services

This REQUEST type is deprecated.

The services REQUEST type allows access to PCR-360 Services and related data. View full details on Services API Calls.

Equipment

This REQUEST type is deprecated.

The equipment REQUEST type allows access to PCR-360 Equipment and related data. View full details on Equipment API Calls.

GLA

This REQUEST type is deprecated.

The gla REQUEST type allows access to PCR-360 Service Desk items and related data. View full details on GLA API Calls.

Service Desk

This REQUEST type is deprecated.

This servicedesk REQUEST variant allows access to PCR-360 Service Desk items and related data. View full details on Service Desk API Calls.

Service Desk Actions

This REQUEST type is deprecated.

The servicedesk REQUEST type allows access to PCR-360 Service Desk items and related data. View full details on Service Desk Action API Calls.

Getting LIST Values

To retrieve LIST values from the API send a request structured as below:

https://url/endpoint.json?LIST=VALUE

The List Call is used to locate the proper List RECID value that needs to be passed in the endpoint call

All List Types will be returned from the Endpoint the request was sent to. The format is different depending on the LIST requested but should look similar to the example below.

{
    "status": "success",
    "page": 1,
    "count": 11,
    "total_count": 3,
    "sd_action": [
        {
            "RECID": 237,
            "VALUE": "Add"
        },
        {
            "RECID": 238,
            "VALUE": "Change Types"
        },
        {
            "RECID": 239,
            "VALUE": "Add Locations"
        }
    ]
}



Writing Data

The PCR-360 API allows an outside application to create or update Service, Equipment, or Service Desk items or submit SNMP traps. The basic write request is much like a read request; the URL is built in a similar fashion. Like the read requests, all API write operations are done via an HTTP(s) request (using cURL or some other method). You will need to build the URL to describe the request you are making.

The primary difference between an INSERT and an UPDATE is the presence of a “RECID” (unique record identifier). If a RECID is present, the system assumes you are trying to update that record. Whereas if there is no RECID present, it will perform an insert to create a new record and return specific information from the new record. The only exception to this is UDFs. An update can be made by supplying the RECID of the UDF value record or by supplying the Service/Equipment/Service Desk RECID and the UDF RECID. If an existing UDF value record is found containing these two RECIDs, it is updated rather than creating a new value record.

Use of HTML Tags

Some fields within PCR-360 allow Users to input HTML tags to make displaying that information a richer experience for those that are expected to consume it. For more information on HTML tag usage, please see the wiki entry for it.

Using POST Calls

  • POST requests will ignore parameters supplied as a query string and need any additional parameters in the request Body.

  • To configure the number of Pages/Results returned by the API (this is most useful for the SQL Endpoint), you can send these as additional Parameter's in the Body.

    Parameter

    Data Type

    Default

    Description

    limit

    Interger

    20

    Number of listings to show.

    page

    Interger

    1

    Page number to show.


  • API fields are not case sensitive, and will always be returned in the lower case format.


Failed Inserts / Updates

Business logic and database integrity checks are enforced when inserting or updating data. If the required data is missing or incorrect, an error will be returned with a status of "failure" and a description of the failure. Possible failures include missing required data, incorrect or missing foreign keys, non-compliance to application business rules or logic, and Custom Validation rules.

A common error that occurs is a required field missing from the write request. It is important to keep in mind that any required user-defined fields that are created for a specific service desk type will also need to be defined when creating or updating a record.

Request Types

Cable

The cable REQUEST type allows writing PCR-360 Cables and related data. View full details on Cable API Calls.

Services

The services REQUEST type allows writing PCR-360 Services and related data. View full details on Services API Calls.

Equipment

The equipment REQUEST type allows writing PCR-360 Equipment and related data. View full details on Equipment API Calls.

Service Desk

The servicedesk REQUEST type allows writing PCR-360 Service Desk items and related data. View full details on Service Desk API Calls.

Service Desk Actions

The servicedesk REQUEST type variant allows writing PCR-360 Service Desk Action and related data. View full details on Service Desk Action API Calls.

GLA

The gla REQUEST type allows writing PCR-360 GLA Records and related data. View full details on GLA API Calls.

Contact

The contact REQUEST type allows for adding and updating PCR-360 Contact Records and related data.  View full details on Contact API Calls.

Barcode

The barcode REQUEST type allows PCR-360 to interface with Barcode Scanning Devices to update Equipment Records.  View full details on the Barcode API Calls.

Custom

The Custom REQUEST type allows the API to invoke custom PHP logic that is saved in the application. This is very useful when interfacing with an application where you cannot control the format or data in the outbound requests. The structure of a custom request type is dependent on the identifier specified in the Custom Logic > API entry. For more information on the syntax and capabilities available in the Custom Logic > API interface, see Custom Logic Syntax.

Using cURL, this example invokes a Custom API called hello-world and the header specifies the content type is JSON encoded and requests data returned JSON encoded:

curl -X POST -d '{"foo":"bar"}' http://DOMAIN/api/API_KEY/hello-world.json -H Content-Type:application/json


Using cURL this example invokes a Custom API called example using the default content encoding of HTTP query string parameters and requests data returned in XML format:

curl -X POST -d "foo=bar" http://DOMAIN/api/API_KEY/example.xml


Writing UDFs

All the Request Types (Equipment, Services, and Service Desk) support writing to associated UDFs. Updating UDF values requires using specific syntax in the request data. Prefix the UDFs unique identifier with "udf_" and submit the values with the other request data.

{
    "udf_IDENTIFIER1" : "VALUE1"
    "udf_IDENTIFIER2" : "VALUE2"
    "udf_IDENTIFIER3" : "VALUE3"
}

API Request Log

For troubleshooting API Requests, navigate to 'Admin > API > API Request Log' to view a record of all Requests made to the API and the Response.  For more details, see the API Request Log page.

RECID vs. ROW ID

The usage of RECID or ROW ID is for clarity about what the RECID or ROW ID represents.

ROW IDs - Row Identification Numbers (ROW IDs) are unique IDs to the row of data in the grid they're assigned to. Some grids do not have a RECID but all grids have ROW IDs.

RECIDs - Record Identification Numbers (RECIDs) are unique IDs for records within a given table. When a grid references a specific record from a table, the Table Name is usually the column name of the RECID that the grid is referencing.

  1. IE: SERVICES_RECID in any given grid is referencing the RECID value from the SERVICES Table.

  2. Some table names are long and need to be abbreviated to meet the 30 character limit imposed by Oracle Databases.

There are several reasons both are used. 

  1. Some grids have multiple RECIDs and a ROW ID is unique to that row of data in the grid.

  2. Some grids don’t have a RECID and the ROW ID is unique to that row of data.

  3. Some ROW IDs are actually combined RECIDs for two or more records in the row.

SNMP

Simple Network Management Protocol (SNMP) will capture events from network device(s). It is used for collecting information used on a form and configuring, network devices, such as servers, printers, hubs, switches, and routers. PCR-360 can listen for SNMP Events and set up automatic Notifications and Escalations according to the User or organizational needs. Currently PCR-360 supports both SNMPv1 and SNMPv2c. There is no support for SNMPv3 at this point in time.  For more information see the SNMP page.


  • No labels