Product Documentation

The REstful API is a set of programmable HTTP calls. These calls operate on the ExtraView application to return data and metadata to the calling program or to update items within the ExtraView database.

API command summary

Authentication

All API commands require an active ExtraView username and password unless anonymous access is enabled with the behavior setting named ALLOW_ANONYMOUS_API_ACCESS. It is sometimes useful to allow anonymous access to ExtraView. Most commonly, this is used to provide a web page that you have designed to perform transactions, or to query the ExtraView database, not to need a hard-coded username and password.

To preserve a secure environment, it is necessary to perform the following steps to set up anonymous access:

1. Within the ExtraView administration section, under the Systems Control tab and within the API Settings section, set the behavior setting named ALLOW_ANONYMOUS_API_ACCESS to have a value of YES
2. In the same section, set the application default named ANONYMOUS_API_USER_ID to the user ID that you will use for the anonymous access
3. All entries made in an anonymous fashion will use this user ID to log their activities
4. Ensure that you only give security privileges to the user group to which this user ID belongs that is in keeping with the fact that this user is used to log all activities. Normally this means that this user group will have limited access to fields, especially in write and query modes
5. It is recommended that when you allow users to enter issues in an anonymous fashion, that you have ExtraView fields that capture their names and other contact details

Once you have set up anonymous access, the parameters named user_id and password in all API commands become optional. If they are provided, they must be valid combinations of user names and passwords.

Requests Passed to the API

To create an API call, the user creates an HTTP request (HTTPRequest object) and submits this to the server. This request can be composed within virtually any computer language. Each HTTP request is composed of the following parts:

• The server domain name, including the path to the servlet where ExtraView is running. For example, http://www.myserver.com/evj/ExtraView
• The class and method which accesses the API. Usually this is ev_api.action
• The user_id and password for the user, passed as name / value pairs
• The statevar, passed as a name / value pair. This parameter defines the specific API call being made
• A list of name / value pairs providing the parameters and their values for the API call, and which are necessary or optional to execute the API call. Note that the user is responsible to provide a correct list of parameters for each call. If the API does not recognize a parameter, then it is ignored and no warning is given to the user.

If you are creating your own HTTPRequest object from a programming environment to call the ExtraView API, then you must also set the standard parts of the HTTPRequest object, such as the USER_AGENT. There will most probably be standard libraries for your environment to assist in doing this.

XML Data Returned From API Calls

Much of the data returned by an API call is in XML format. This has some significance to the user of the API, in that Extraview's XML data may embed your own XML within its results. To accommodate this, ExtraView uses Base64 encoding whenever it sees XML data returned from the application to ensure that the XML returned by API commands through the API must be well-formed. This means that the contents of a CDATA string must not contain the character string "]]>", because that is the end sentinel for a CDATA section. So, if the original data contains this string, there must be some way to escape the data. For easy recognition of an escaped CDATA string, ExtraView prepend the characters %25S to the front of the string. These characters are merely a sentinel and are not part of the output string. The encoding used for the rest of the CDATA string is called Base64, and algorithms for encoding/decoding are widely available. Furthermore, ExtraView ensures that the %25S sentinel string does not appear in the CDATA raw character string by encoding any CDATA raw character string to Base64 as well. It is the responsibility of the receiver, therefore, to test each CDATA section for the sentinel characters %25S at the beginning of the CDATA, and, if present, perform the Base64 decode function on the remainder of the character data to get the raw character values in the field.

Server-side Templates

Server-side templates can be defined for many API commands. These templates allow you to control the presentation of the output from the API command. Most commonly this is used to allow the administrator to integrate ExtraView with their company’s own web site. For example, a page within your company’s web site can perform a search of the ExtraView database and return the results formatted with the same look and feel as the web site.

Templates allow you to use “tags” that are substituted at runtime, with the actual value in a record. For example, the tag __STATUS__ refers to the value of the STATUS field of the current record. Tags are available for most fields in the data dictionary. In addition, if you place a data dictionary field on a template, it must exist on the Detailed Report layout inherited by the specific Business Area and Project. The user must also have read permission to the field.

See this page for full details of server-side templates.

Repeating Row Records and the API

Output from ExtraView using repeating rows can be turned off, to simplify the XML returned from a command. To use repeating rows within the API, you must set the behavior setting named MULTI_RELEASE_XML to a value of YES within the administration section.

The following API commands support repeating rows:

• GET
• GET_FIELDS
• HISTORY
• INSERT – note that you can only insert a single repeating row when inserting an issue, but you can then update that issue with additional repeating rows
• RUN_REPORT
• UPDATE – note that you can only update a single repeating row with a single update command.

The commands that return XML will do so as shown in the following example:

The data structures here are:

1. Repeating Rows Element -- at most one per issue extracted:

   <REPEATING_ROWS TITLE=’Repeating Rows’ REPEATING_ROWS='1'>
   ... (repeating row elements)
   </REPEATING_ROWS>

2. Repeating Row Elements – as many as there are repeating rows in the issue extracted:

   <REPEATING_ROW REPEATING_ROW_ID='nnnnnnn'>
   ... (repeating row field elements)
   </REPEATING_ROW>

3. Repeating Row Field Elements – one for each field inside the repeating row:

   <fieldTag TITLE='fieldTitle'>
   <![CDATA[fieldData]]>
   </fieldTag>

   where –

   fieldTag = data dictionary field name
   fieldTitle = title of the field
   fieldData = data contained in the field (in CDATA-encoded format)

Updating and Inserting Fields in Repeating Row Data

Previous to release 4.2.2.8, the API did not handle repeating row records, therefore the previous format for for update of fields within an issue is maintained for backward compatibility. An extension is made to allow for the insertion or the update of one or more specific repeating row fields as follows.

Updating Repeating Rows

To update an existing repeating row field, there must be a parameter named PROBLEM_RELEASE_ID in the update parameter set. This parameter may have multiple values, each one specifying a specific repeating row ID (i.e. the ITEM_ID of the repeating row within the issue). The field values associated with these repeating rows are specified in a parallel set of parameters, named for the field name within the repeating row. Each such parameter may be given mutiple values, each of which maps to a repeating row as specified by the multiple values of PROBLEM_RELEASE_ID.

As an example, assume that there are 5 repeating rows in issue #100, numbered 201, 202, 203, 204, and 205.

Then with PROBLEM_RELEASE_ID set to the values (202, 204), the value of FRED_RR, a repeating row-resident field, might take on the values ("fred202", "fred204") in the input parameters.

Then, the repeating rows with the ID’s of 202 and 204 are updated with the value of FRED_RR being set to "fred202" and "fred204" respectively. No other repeating rows would be affected by the update.

Inserting Repeating Rows

Inserting repeating rows is similar to updating repeating rows, except no PROBLEM_RELEASE_ID is given as a parameter. When no PROBLEM_RELEASE_ID is present, ExtraView will insert the remaining fields as a new repeating ROW.

You can insert multiple repeating rows with a single API call. For example, the following parameter string will insert three repeating row records, each within a single field named FRED_RR:

&FRED_RR=val1&FRED_RR=val2&FRED_RR=val3

Repeating Row Example

First, make sure you have set the behavior setting named MULTI_RELEASE_XML to YES. The following examples assume you have an ExtraView server located at http@//extraview.myserver.com/evj/ExtraView.

Retrieving an Issue

We will first retrieve issue number 26788 from ExtraView. This issue has existing repeating rows.

http@//extraview.myserver.com/evj/ExtraView/ev_api.action?user_id=myname&password=mypass&statevar=get&id=26788

ExtraView returns XML data that includes a section about Repeating Rows. The XML is shown indented here for clarity.

The important data you need is located at . This provides the unique identifier for the particular repeating row of the issue.

Updating an Issue

To update the field named RELEASE_CHILD_STATUS field within the repeating record field just retrieved from the example above:

http://extraview.myserver.com/evj/ExtraView/ev_api.action?user_id=myname
&password=mypass&statevar=update&id=26788&problem_release_id=1073788412
&RELEASE_CHILD_STATUS=6936

Inserting an Issue

To insert a new issue, including one repeating row:

http://extraview.myserver.com/evj/ExtraView/ev_api.action?user_id=myname
&password=mypass&statevar=insert&area_id=4&project_id=8&category=SOFTWARE
&short_descr=Testing&product_name=EVJAVA&module_name=DATABASE&RELEASE_CHILD_STATUS=6936
&description=blah

The presence of the field named RELEASE_CHILD_STATUS, as the only field in the example that has exists within a repeating row record, causes a new repeating row record to be created.