Extensions

Configuring State Transitions with Extensions

To perform state transitions, an extension can be used. Add a state transition extension from the Extensions screen, accessible from Settings. Once added, the extension can be applied from the State Transition sash on the Collection Configuration screen.

Note: Hub also provides functionality to configure state transitions using a transition graph. The transition graph is the recommended strategy, as it allows you to configure the state transitions directly within Hub's UI.

Authoring State Transition Extensions

State transition extensions are defined by a single function:

function transitionArtifact(context,transitions)

This function can return a single transition.

For a given artifact, the extension may be called multiple times. Each time the extension is called, the transition that it returns is performed. State transition extensions are called repeatedly until they return undefined, indicating that no more transitions are needed.

To prevent errors, extensions are not called again if they cause an artifact to transition to the same status more than once.

A simple state transition extension could look something like this:

function transitionArtifact(context,transitions) {

    if (context.sourceArtifact.status === 'Resolved' && context.targetRepositoryArtifact.status !== 'Resolved') {
        var transition = findTransitionWithLabel(transitions,'Resolve');
        transition.attributes.resolution = 'Fixed';

        return transition;

    }

}

function findTransitionWithLabel(transitions, label) {

    for each(var transition in transitions) {

        if (transition.label === label) {

            return transition;

        }

    }

}

Two parameters are passed to the transitionArtifact function:

• context - A context object that provides state that the extension can use to determine which transitions are needed
  • context.sourceArtifact - A JavaScript object representation of the source artifact, whose structure matches the model configured in the integration
  • context.targetRepositoryArtifact - A JavaScript object representation of the target artifact, whose structure matches the structure of the artifact in the repository
• transitions - An array of transition objects

Below is an example of a context with a target artifact from Jira:

{
    "sourceArtifact": {
        "summary": "a summary value",
        "priority": "Critical",
        "status": "Done"
    },
    "targetRepositoryArtifact": {
        "issuetype": "Bug",
        "components": null,
        "timespent": null,
        "formattedid": "TPC-144",
        "timeoriginalestimate": null,
        "project": "Test Project C",
        "description": null,
        "fixVersions": null,
        "resolution": null,
        "customfield_11500": null,
        "api-id": "JIRA",
        "attachment": null,
        "resolutiondate": null,
        "id": 14400,
        "summary": "a summary value",
        "watches": null,
        "created": "2016-09-23T15:22:20.000+0000",
        "$closed": false,
        "reporter": "****",
        "priority": "Critical",
        "labels": null,
        "revision": null,
        "customfield_11601": null,
        "customfield_11600": null,
        "customfield_11501": null,
        "environment": null,
        "customfield_11504": null,
        "customfield_11602": null,
        "timeestimate": null,
        "versions": null,
        "duedate": null,
        "web-links": null,
        "location": "http://jira.example.com/browse/TPC-144",
        "assignee": null,
        "worklog": null,
        "updated": "2016-09-23T15:22:20.000+0000",
        "status": "To Do"
    }
}

Each transition object in the array appears as follows:

 {
  id: 'an-id',
  label: 'A Label'
  attributes: {
    first-attribute: null,
    ...
  }
}

For example, transitions corresponding to the Jira artifact example above are as follows:

[{
    "attributes": {
        "project": "Test Project C",
        "issuetype": "Bug"
    },
    "id": "11",
    "label": "To Do"
}, {
    "attributes": {
        "project": "Test Project C",
        "issuetype": "Bug"
    },
    "id": "21",
    "label": "In Progress"
}, {
    "attributes": {
        "project": "Test Project C",
        "issuetype": "Bug"
    },
    "id": "31",
    "label": "Done"
}] 

Attributes of a transition are values that may be set when performing the transition. Attributes should not be set unless needed or required. 

The available attributes and whether or not they are required will vary depending on the type of repository of the collection.

Configuring Gateway Collections with Extensions

To configure a Gateway Collection with an Extension, add a payload transformation extension from the Extensions screen, accessible from Settings. Once added, the extension can be referenced from the Gateway Collection screen.

Authoring Payload Transformation Extensions

Payload transformation extensions are defined by a single function:

function transformPayload(payload)

The function must return an array of 0 or more JSON objects matching the model of the gateway collection.

Given a model representing build jobs with the following fields:

• created - A date signifying the creation date
• summary - A brief one-line description
• status - A single-select indicating the build status

A simple payload transformation extension could look something like this:

function transformPayload(payload) {
  var createdTimestamp = new Date(payload.build.completion_time).toISOString();
  var created = createdTimestamp.substring(0,createdTimestamp.indexOf('T'));
  return [
    {
      'created': created,
      'summary': payload.name + ': '+payload.build.full_url,
      'status': payload.status
    }
  ];
}

The example above corresponds to the payload provided by the Jenkins Notification plugin, which provides JSON payloads as follows:

{
	"name": "Robot Lawnmower",
	"url": "job/Robot%20Lawnmower/",
	"build": 
	{
		"full_url": "http://build.example.com:8081/job/Robot%20Lawnmower/4/",
		"number": 4.0,
		"phase": "COMPLETED",
		"status": "FAILURE",
		"url": "job/Robot%20Lawnmower/4/",
		"scm": 
		{
			
		},
		"causes": 
		[
			"Started by user admin"
		],
		"duration_string": "9 ms",
		"completion_time": 1.476313762942E12,
		"failing_since_build": 
		{
			"full_url": "http://build.example.com:8081/job/Robot%20Lawnmower/1/",
			"number": 1.0,
			"change_set": 
			[
				
			],
			"completion_time": 1.47631304791E12,
			"failing_since_time": "11 min"
		}
	}
}

function transformPayload(payload) {
  ...
  
  if (nothingToDo) {
     return [];
  }
  ...
}

Creating Multiple Artifacts From A Single Webhook Payload

There may be cases when multiple artifacts should be created from a single webhook payload depending on the use case. For example, a GitHub PushEvent can contain multiple commits. To link each commit to an artifact separately, a payload transformation extension would be used as follows:

function transformPayload(payload) {
  var gatewayPayloads = [];
  for each (var commit in payload.commits) {
     gatewayPayloads.push(createCommitPayload(commit));
  }
  return gatewayPayloads;
}

Query Parameters and HTTP headers (optional)

Payload transformations can take two additional parameters — query parameters and HTTP headers:

• Query Parameters: Provides the query parameters sent with the payload as a JavaScript object with property names corresponding to parameter names and values as arrays of values of the corresponding query parameter

• HTTP Headers: Provides the HTTP request headers sent with the payload as a JavaScript object with property names corresponding to HTTP header names and values as arrays of values of the corresponding HTTP header

This might appear as follows:

function transformPayload(payload, parameters, headers)

The Context Object

The context object provides information that the extension can use to determine which transformations are needed.

For a custom data transformation, use the following:

• context.sourceArtifact: A JavaScript object representation of the source artifact

  • If you are mapping from model to repository, this will match the structure of the artifact in the model

  • If you are mapping from repository to model, this will match the structure of the artifact in the repository

• context.targetArtifact: A JavaScript object representation of the target artifact

  • If you are mapping from model to repository, this will match the structure of the artifact in the repository

  • If you are mapping from repository to model, this will match the structure of the artifact in the model

Note: If existing scripts are utilizing targetRepositoryArtifact instead of targetArtifact, they will continue to work.

If you are creating a custom data transformation extension for test steps, use:

• context.sourceTestStep to access the source test step

  • If you are mapping from model to repository, this will match the structure of the artifact in the model

  • If you are mapping from repository to model, this will match the structure of the artifact in the repository

• context.targetTestStep to access the target test step

  • If you are mapping from model to repository, this will match the structure of the artifact in the repository

  • If you are mapping from repository to model, this will match the structure of the artifact in the model

See Planview Hub Editions to determine if your edition contains Test Step functionality

The context parameter also has field properties:

• context.sourceField: If processing a single field
• context.sourceFields: A list of field objects, if processing more than one field
• context.targetField: If processing a single field
• context.targetFields: A list of field objects, if processing more than one field

A field object only has two properties: ID, and label:

{
    id: "assignee",
    label: "Assignee"
}

Creating a Custom Data Transformation Extension

Custom data transformation extensions are created from the Extensions screen, accessible from Settings. Created extensions can be selected when configuring a field mapping of a collection.

Custom data transformation extensions appear as follows:

var inputTypes = 'String';
var outputTypes = 'String';

function transform(context, input) {
	// returns the transformation result
}

All custom data transformation extensions must declare their input and output types as shown in the example above. Transformations are only available for a field mapping if the input types and output types match the fields selected in the mapping. In the case of a mapping with multiple source and target fields, the order of the declared input and output types must match the order of the source and target fields.

A simple split-and-trim value custom data transformation extension could look like this:

var inputTypes = 'String';
var outputTypes = ['String', 'String'];

function transform(context, input) {
    if (input) {
        var values = input.split('/');
        if (values.length != 2) {
            throw 'Unexpected value ' + input;
        }
        return values.map(function(s) {
            return s.trim();
        });
    }
}

Single Select and Multi Select in Custom Data Transformation Extensions

Single Select and Multi Select values are specified using their labels. Extensions that accept a Single Select as the input type will receive a string containing the option’s label. Extensions that specify a Single Select as the output type should return a string containing the option’s label.

To specify the empty option, return undefined from the extensions instead of a value. Extensions that accept a Multi Select as the input type will receive an array of strings of the option labels. Extensions that specify a Multi Select as the output type should return an array of strings with the option labels or an empty array to specify no options.

If the field has options, field options are available on the field of the context passed into an extension. For example, the options can be accessed with something like this:

context.sourceField.options
context.targetField.options

Rich Text Support in Custom Data Transformation Extensions

To perform Rich Text transformations, Rich Text must be declared as input or output types of the extension. 
A Rich Text input parameter is passed as a valid HTML string. 

For Rich Text as output type, the extension is expected to return a valid HTML string.

To escape HTML characters, the following function is provided:

html.escape(string)

A simple String-to-Rich-Text value transformation could look like this:

var inputTypes = 'String';
var outputTypes = 'Rich Text';

function transform(context, input) {
    if (input) {
        return '<pre>' + html.escape(input) + '</pre>';
    }
}

Web Links in Custom Data Transformation Extensions

To perform a web links transformation, web links must be declared as the input or output types of the extension. A web links field consists of a list of web link objects. A web link object consists of a location and other attributes.

The following is an example of a web link output:

[
   {
      label: 'Tasktop',
      location: 'http://www.tasktop.com'
   },
   {
      location: 'http://www.alt-tasktop.com'
   }
]  

Note: The label attribute is optional and if specified will be used to populate the label of the web link.

Relationships in Custom Data Transformation Extensions

Planview Hub provides a JavaScript API for working with relationship fields. This API can retrieve, search, and get associated artifacts for artifacts.

var inputTypes = 'Relationship';
var outputTypes = 'Relationship';

function transform(context, input) {
	if (input) {
  		return findParentFolder(context.sourceArtifact);
	}
	return null;
}
  
function findParentFolder(artifact) {
	var parent = artifacts.retrieveArtifact(artifact['parent']);
	if (parent['subtype'] === 'Folder') {
		return artifact['parent'];
	} else if (parent['subtype'] === null) {
		return null;
	}
	return findParentFolder(parent);
}

var inputTypes = 'Relationship';
var outputTypes = 'Relationship';

function transform(context, input) {
	var searchDefinition = artifacts.getFormattedIdSearchDefinition();
	
	searchDefinition['formatted-id'] = 'TPA-42';
	var results = artifacts.searchByFormattedId(searchDefinition);
	if (results[0]) {
		return results[0];
	}
	return null;
}

var inputTypes = 'Relationship';
var outputTypes = 'Relationship';

function transform(context, input) {
	var searchType = getCustomSearchType();
	var searchDefinition = artifacts.getSearchDefinition(searchType);
	
	searchDefinition['domain'] = 'DEFAULT';
	searchDefinition['project'] = 'My Project';
	searchDefinition['summary'] = context.sourceArtifact.summary;
	var results = artifacts.search(searchType, searchDefinition);
	if (results[0]) {
		return results[0];
	}
	return null;
}

function getCustomSearchType() {
	var searchTypes = artifacts.listSearchTypes();
	for (var i=0; i<searchTypes.length; i++) {
		if (searchTypes[i] === 'My Custom Search') {
			return searchTypes[i];
		}
	}
	return i;
}

artifacts.toRelationship(container)

artifacts.toContainer(relationship[, summary])

var inputTypes = 'Relationship';
var outputTypes = 'Container';

function transform(context, input) {
	if (input) {
		var parentRelationship = findParentFolder(context.sourceArtifact);
  		return artifacts.toContainer(parentRelationship);
	}
	return null;
}
  
function findParentFolder(artifact){
	var parent = artifacts.retrieveArtifact(artifact['parent']);
	if (parent['subtype'] === 'Folder') {
		return artifact['parent'];
	} else if (parent['subtype'] === null) {
		return null;
	}
	return findParentFolder(parent);
}

var inputTypes = 'Container';
var outputTypes = 'Relationship';

function transform(context, input) {
	if (input) {
		var parentRelationship = artifacts.toRelationship(input);
		var parentArtifact = artifacts.retrieveArtifact(parentRelationship);
		var container = parentArtifact['parent'];
  		return artifacts.toRelationship(container);
	}
	return null;
}

Comments in Custom Data Transformation Extensions

Comment extensions can be used to achieve use cases such as:

• Splitting long comments in a source collection into multiple comments in a target collection
• Excluding comments from integration based on some set criteria
• … and more!

Once saved, the extension can be applied on the Comment Configuration screen.

To create a comment extension, comments must be declared as the input or output types of the extension.

Note: Comment extensions will only impact new comments as they flow through Planview Hub. Existing comments that have already been synchronized will not be impacted.

If you are creating a custom data transformation for comments,

• The Comments type is supported as an array of comment objects
• A comment will be a javascript object with field ids as the key

  • For example, a private comment with ID 1 and content This is a comment may look like this:

{
    "id":"1",
    "is-private":true,
    "comment-content":"<p>This is a comment</p>"
}

Here's an example of an extension that replaces user information with a default user in outbound comments:

// The following extension can be set on Collection to Model transformation on a collection. 
// It replaces user information at a repository's comment to a default user and returns comments that matches to Hub comment model.
var inputTypes = 'Comments';
var outputTypes = 'Comments';

function transform(context, input) {
    if(input.length >0){
        input.forEach(function(element) {
            replacePeople(element);
        });
    }
     return input;
}

function replacePeople(comment){
    var pattern = /user(\d*)/gi;
    comment['creator']='default';
    comment['work_notes']=comment['work_notes'].replace(pattern,'default');  //replace user information at a repository's comment contents field, work_notes
    comment['content']=comment['work_notes'];  //assign updated repository's comment content to the Hub's comment object's comment content field
}

Here's an example of an extension that adds a header to inbound comments with a default user:

// The following extension can be set on Model to Collection transformation on a collection. 
// It addes comment header with default user to the given Hub model's comment input. 
var inputTypes = 'Comments';
var outputTypes = 'Comments';

function transform(context, input) {
    if(input.length >0){
            addCommentHeader(input[0]);
    }
     return input;
}

function addCommentHeader(comment){
    var headerText = '<p>[Comment from '+'default_user'+']</p>';
    comment['content']=headerText+comment['content'];  //Hub's comment object's comment content field is comment['content']  
}

Concatenation

To concatenate two fields on the source artifact into one field on the target artifact, a custom data transformation extension can be used.

Note: You can also concatenate fields on the Field Mapping screen. Learn more here.  

Below, we've outlined how to configure a custom data transformation extension in order to concatenate the Formatted ID and Name from Broadcom Rally into the Summary model field. The concatenated values will then flow from the model to the chosen field on the target artifact.

1. Go to the Field Mapping screen for the source (Rally) collection.
2. If the Summary model field is already mapped in the source collection, delete the mapping.  
3. Choose Formatted ID and Name from the left side (repository) dropdown and Summary from the right side (model) dropdown and Press Connect.  
4. Make a note of the Type for each of the 2 fields and the order in which they are added. For example, in the below example Formatted ID was added first and is of type String and Name was added next and is of type String. The Model Field is also of type String. 
   1. 
5. Open the Settings in a different tab and go to Extensions > Manage Extensions.
6. Create a new data transformation extension. 

7. Give the extension a name and update the input types based on Step 5. In this case we have 2 Inputs of types String and String. Update the input types as follows:

   var inputTypes = ['String', 'String'];

   1. Note: This will take the Formatted ID as the 1st parameter and Name as the 2nd parameter. 

8. Update the output types based on Step 5. In this example, we have 1 output of type String. Update output types as follows: 

   1. var outputTypes = 'String';

9. In the body of the function, use the following statement to concatenate: 

   1. return 'ID: ' + input[0] + ' :: '+input[1];

10. Here's an example of the full script:

    1. var inputTypes = ['String', 'String'];
       var outputTypes = 'String';
       
       
       function transform(context, input) {
          // returns the result of the transformation
          return 'ID: ' + input[0] + ' :: '+input[1];
       }

11. Save and go back to the source collection. 
12. Configure the Summary mapping from Step 4: 
    1. 

13. You will now see the extension you created as an option for the transform on the right (model) side. Choose this extension and click Save and Done. 

    1. 

14. In your target collection, simply map the Summary model field to your chosen field on the target artifact (i.e., Summary, Name, Title, etc). 

    1. 

 This will concatenate the 2 fields (ID, Name) on the source artifact to a single Summary field on the target artifact.

Configuring Person Reconciliation with Extensions

A person reconciliation extension can be created from the Extensions screen, accessible from Settings. Created extensions are selected in the Person Reconciliation section of the Collection screen. In most cases it makes sense to have one extension per repository, since each repository will have different requirements for mapping persons to and from the repository. Person reconciliation extensions apply to all person fields of an artifact, including person fields in comments and attachments.

The Context Object

The context object provides information that the extension can use to determine how person reconciliation should be handled.

For a custom data transformation, use the following:

• context: A context object that provides information that the extension can use to determine which transformations are needed

• context.sourceArtifact: A JavaScript object representation of the source artifact

  • If you are mapping from model to repository, this will match the structure of the artifact in the model

  • If you are mapping from repository to model, this will match the structure of the artifact in the repository

• context.targetArtifact*: A JavaScript object representation of the target artifact

  • If you are mapping from model to repository, this will match the structure of the artifact in the repository

  • If you are mapping from repository to model, this will match the structure of the artifact in the model

If you are creating a custom data transformation extension for test steps, use:

• context.sourceTestStep to access the source test step

  • If you are mapping from model to repository, this will match the structure of the artifact in the model

  • If you are mapping from repository to model, this will match the structure of the artifact in the repository

•  context.targetTestStep to access the target test step
  • If you are mapping from model to repository, this will match the structure of the artifact in the repository
  • If you are mapping from repository to model, this will match the structure of the artifact in the model

See Planview Hub Editions to determine if your edition contains Test Step functionality

The context parameter also has field properties:

• context.sourceField: If processing a single field
• context.sourceFields: A list of field objects, if processing more than one field
• context.targetField: If processing a single field
• context.targetFields: A list of field objects, if processing more than one field

A field object only has two properties: ID, and label:

{
    id: "assignee",
    label: "Assignee"
}

Authoring Person Reconciliation Extensions

Person reconciliation extensions are defined by two functions:

mapPersonFromRepository(repositoryPerson, unresolvedPerson)

mapPersonToRepository(modelPerson)

Both functions are expected to return a string value corresponding to the user id of the person. Returning undefined sets the person field to empty. In the case where a user cannot be mapped and having the field empty is not an option, throw an exception as follows:

if (noMatchFoundCondition) {
    throw 'some descriptive message';
}

Such errors will cause processing of an artifact to result in an error with error code CCRRTT-17011E which will display under the Activity screen.

{
	"person-id": "userA", 
	"person-email": "userA@test.tasktop.com", 
	"person-display-name":"User A", 
	"active": true
}

{
	"person-id": "userA", 
	"person-email": "userA@test.tasktop.com"
}

{
	"id": "userId",
	"display-name": "Jane Smith"
}

function mapPersonFromRepository(repositoryPerson, unresolvedPerson, context) {
    if (repositoryPerson) {
        return repositoryPerson.id;
    }
}

function mapPersonToRepository(modelPerson, context) {
    if (modelPerson) {
        try {
            var person = persons.searchPerson('id', modelPerson.id);
            console.log("found match " + person.id);
            return person.id;
        } catch (e) {
            console.log("no match found mapping to " + context.targetField.id);
            if (context.targetField.id === "assignee") {
                return "default-assignee";
            } else if (context.targetField.id === "reporter") {
                return "default-reporter";
            } else if (context.targetField.id === "comments") {
                return "default-commenter";
            }
        }
    }
}

function mapPersonToRepository(modelPerson, context) {	
	var person;
	try {
		person = persons.searchPerson("email", modelPerson.id);
	} catch (e) {
		// no matching person found
		// select a default person by team
		if (context.sourceArtifact["team"] === "Team A") {
			person = persons.searchPerson("email", "team.a.lead@company.net");
		} else if (context.sourceArtifact["team"] === "Team B") {
			person = persons.searchPerson("email", "team.b.lead@company.net");
		}
	}
	// return a match if found
	if (person) {
		return person["person-id"];
	}
}

function mapPersonFromRepository(repositoryPerson, unresolvedPerson) {
    return repositoryPerson['Username'];
}

function mapPersonToRepository(modelPerson) {
    // persons.listPersonSearchFields(); determines the fields usable by .searchPerson(...)
    var repositoryPerson = persons.searchPerson('Username', modelPerson['id']);
    return repositoryPerson['ID'];
}

SearchPerson Example Script

Below is an example SearchPerson script. Persons.searchperson (fieldId, fieldValue) is used to search for a person in a repository using the two parameters: fieldId and fieldValue.

This person can then be used to return the matching ID of a user in that repository. 

Persons.searchPerson(fieldId, fieldValue) will find exactly one person and will throw a PersonNotFoundException if no match is found or TooManyPersonsFoundException if more than one person is found. These exceptions can be caught and handled by the extension. searchPerson() is a native Hub call, which means it is functionality that is unique to Hub.

function mapPersonFromRepository(repositoryPerson) {
    	...
}
 
function mapPersonToRepository(modelPerson) {
    	if (!modelPerson){
           	console.log('incoming model person is empty')
           	return undefined
    	}
    	
    	console.log('modelPerson = ' + modelPerson['id']);
           	
   var repoPerson = persons.searchPerson('person-username', modelPerson['id']);
  
   console.log('repoPerson = ' + repoPerson['id']);
	return repoPerson['id'];
}

Scenario 1: Mismatched E-mails

Consider an example where Repository 1 has email john.s@email.com and Repository 2 has email john.smith@email.com. The persons.searchPerson(fieldId, fieldValue) can be used to search the repository for matching person values.

Assume that the integration has one-way person flow from Repository 1 (john.s@email.com) to Repository 2 (john.smith@email.com).  In this case, the mapPersonToRepository() function should be edited and the incoming values matched by ID. A search persons call based on incoming username is made and then the matching user object is retrieved.

Scenario 2: Returning a Default ID as a Value

function mapPersonFromRepository(repositoryPerson) {
	return repositoryPerson['email'];
}
 
function mapPersonToRepository(modelPerson) {
    	var defaultUserId = 'SOMEVALUEHERE'
 
    	console.log(persons.listPersonSearchFields())
    	try{
    		var person = persons.searchPerson('email', modelPerson.id);
    		if(person != null) {
    			return person['person-username'];
    		}
	} catch(e){
		console.log(e)
	}
	console.log('Falling back to default person')
	return defaultUserId
}

The above script allows us to search for persons in the repository based on an incoming email value. In cases where a corresponding person is not found in the repository, Hub will return the defaultUserId. To return a default user ID, assign a default value (a user ID) to the var defaultUserId.

function mapPersonFromRepository(repositoryPerson) {
	return repositoryPerson['email'];
}
 
function mapPersonToRepository(modelPerson) {
    	 console.log(JSON.stringify(persons.listPersonSearchFields()))
	var person = persons.searchPerson('person-email', modelPerson.id);
	return person['person-id'];
}

 Person listSearch Fields: ["person-username","person-email","person-id","person-display-name"] 

HTTP Client API Reference

• httpClient - The globally-visible object providing the HTTP client API
• httpClient.request():RequestBuilder - Provides a RequestBuilder object
• RequestBuilder.uri(uriString):RequestBuilder - Specifies the URI of the request
• RequestBuilder.parameter(key,value):RequestBuilder - Adds a query parameter to the request with the given key and value
• RequestBuilder.header(key,value):RequestBuilder - Adds an HTTP header value to the request with the given key and value
• RequestBuilder.GET():Request - Creates a Request object for an HTTP GET request
• Request.response():Response - Creates a Response object with the result of the HTTP request
• Response.statusCode():int - Provides the HTTP status code of the response
• Response.content():String - Provides the body of the HTTP response as a string
• Response.headers():Map - Provides the HTTP response headers as a JavaScript object with property names corresponding to HTTP header names, and values as arrays of values of the corresponding HTTP header
• RequestBuilder.proxy(hostname, port[, username, password]):RequestBuilder - Specifies an HTTP proxy to be used for this request

Artifacts returned from the Artifact API are the raw JSON representation of a Repository's Artifact. These representations may include internal IDs and other fields not mapped to the model. It may be necessary to manually interpret the results of these calls on a per-repository basis to determine the exact information that is returned.

Example extension Response.headers() return value:

{
	"Transfer-Encoding": [
		"chunked"
	],
	"Server": [
		"Jetty(9.2.13.v20150730)"
	],
	"Vary": [
		"Accept-Encoding, User-Agent"
	],
	"Content-Type": [
		"application/json;charset=UTF-8"
	]
}