On this page:
This page describes the AppDynamics API methods you can use to import and export various types of configuration settings in the Controller.
About the Configuration Import/Export APIs
The Configuration Import/Export APIs enables you to migrate configuration settings across Controller accounts, business applications, or Controller instances. You can also use it to add configuration artifacts—such as transaction detection rules, health rules or custom dashboards—to an existing configuration programmatically.
An exported configuration is an XML or JSON representation of the configuration artifact. After exporting the file, you can upload it to another account or application, optionally modifying the configuration.
Export Actions from an Application
Exports all actions in the specified application to a JSON file.
To be able to export actions, the user account you use to make the API call must have permissions to view an action or action template in the application you are exporting from.
Format
GET /controller/actions/application_id
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/actions/7
[
{
actionType: "EmailAction",
name: "6DA8942B-DF4A-417A-E1NF-59F14231D670",
priority: 1,
description: null,
toAddress: "user1@example.com",
subject: "",
timeZone: null
},
{
actionType: "DiagnosticSessionAction",
name: "MyDiagnotic",
priority: 0,
description: null,
businessTransactionTemplates: [ ],
numberOfSnapshotsPerMinute: 5,
durationInMinutes: 10,
adjudicate: false,
adjudicatorEmail: null
}
]
Import Actions into an Application
After you have exported actions, you can import them to a different application passing the JSON file created by the export operation as the payload to a POST request.
The user account you use to make the API call must have permissions to create an action or action template in the account.
Actions in the import file that have conflicting names with actions in the existing configuration are not imported. The import for those actions fail, while new actions are imported successfully.
This call takes data as multipart/form-data content. Use UTF-8 URL encoding of the URI before posting; for example, do not replace a space (" ") with "%20" in the URI.
Format
POST /controller/actions/application_id
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/actions/38 -F file=@ExportActions.json
{"success":true,"errors":[],"warnings":[]}
If there are actions in the file with the same name as ones in the configuration, those actions are not imported, and the response indicates the success of the request as false, as follows:
{"success":false,"errors":["Not importing Action with name: DuplicateExportedDiagnosticAction, since it already exists."],"warnings":["Imported 1 out of 2 actions"]}
Export Email Action Templates from an Account
This API exports all the email action templates in the current account in JSON format.
Format
GET /controller/actiontemplate/email
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/actiontemplate/email
[ {
"actionPlanType" : "email",
"name" : "MyCustomEmailTemplate",
"oneEmailPerEvent" : true,
"eventClampLimit" : 100,
"defaultCustomProperties" : [ {
"id" : 0,
"version" : 0,
"name" : "env",
"value" : "%OS"
} ],
"allowCustomRecipients" : true,
"toRecipients" : [ ],
"ccRecipients" : [ ],
"bccRecipients" : [ ],
"headers" : [ ],
"subject" : "We've got a situation...",
"includeTextBody" : true,
"textBody" : "<h1>Summary of events occurring during the ${policy.digestDurationInMins}+ minute(s) prior to ${action.triggerTime}:</h1> <table> #foreach(${eventList} in ${fullEventsByTypeMap.values()}) #foreach(${event} in ${eventList}) <tr> <td> <!-- Event icon --> <img src="${event.severityImage.mimeContentRef}" alt="${event.severity}" /> </td> <td> <!-- Event name with event link --> <a href="${event.deepLink}">${event.displayName}</a> </td> <td> <!-- Event message --> ${event.eventMessage} </td> </tr> #end #end </table>"",
"includeHtmlBody" : true,
"htmlBody" : "<p>Please look into it.</p>",
"testLogLevel" : "DEBUG",
"testPropertiesPairs" : [ ],
"testToRecipients" : [ ],
"testCcRecipients" : [ ],
"testBccRecipients" : [ ],
"eventTypeCountPairs" : [ ]
} ]
Import Email Action Templates
Enables you to import email action templates to an account as JSON file. The import fails if you attempt to import a template with the same name as an existing template of the same type in the destination account.
Data for this call should be in the form of multipart/form-data. Use UTF-8 URL encoding of the URI before posting; for example, do not replace a space (" ") with "%20" in the URI.
Format
POST /controller/actiontemplate/email
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/actiontemplate/email -F file=@emailactiontemplate.json
{"success":true,"errors":[],"warnings":[]}
Export HTTP Request Action Templates from an Account
This API exports all the HTTP request action templates in the current account to a JSON file.
Format
GET /controller/actiontemplate/httprequest/
Example:
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/actiontemplate/httprequest
[ {
"actionPlanType" : "httprequest",
"name" : "MyCustomHTTPTemplate",
"oneRequestPerEvent" : false,
"eventClampLimit" : -1,
"defaultCustomProperties" : [ ],
"method" : "GET",
"scheme" : "HTTP",
"host" : "http",
"port" : 0,
"path" : "//demo.appdynamics.com//controller/rest/applications/${latestEvent.application.name}/nodes/${latestEvent.node.name}",
"query" : "",
"urlCharset" : "UTF_8",
"authType" : "BASIC",
"authUsername" : "user1",
"authPassword" : "secret",
"headers" : [ ],
"payloadTemplate" : {
"httpRequestActionMediaType" : "text/plain",
"charset" : "UTF_8",
"formDataPairs" : [ ],
"payload" : ""
},
"connectTimeoutInMillis" : 5000,
"socketTimeoutInMillis" : 15000,
"maxFollowRedirects" : 0,
"responseMatchCriteriaAnyTemplate" : [ ],
"responseMatchCriteriaNoneTemplate" : [ ],
"testLogLevel" : "DEBUG",
"testPropertiesPairs" : [ ],
"eventTypeCountPairs" : [ ]
} ]
Import HTTP Action Templates into an Account
After you have exported HTTP request action templates, you can import them to a different account by logging into the destination account and passing the JSON file created by the export operation as the payload to the POST request.
You can modify the exported file before you import it. You might want to do this to remove one or more template configurations or to change their names. The import will fail if you attempt to import a template with the same name as an existing template of the same type in the destination account.
Use UTF-8 URL encoding of the URI before posting; for example, do not replace a space (" ") with "%20" in the URI.
Format
GET /controller/actiontemplate/httprequest
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/actiontemplate/httprequest -F file=@httpactiontemplate.json
{"success":true,"errors":[],"warnings":[]}
Export Custom Dashboards and Templates
You can export and import custom dashboards and custom dashboard templates interactively from the Controller UI or using this API call.
See Import and Export Custom Dashboards and Templates Using the UI for information on importing and exporting custom dashboards and dashboard templates from the AppDynamics UI.
To export the dashboard, the user making the API call must have permissions to view the custom dashboard.
In the export call, you need to identify the dashboard to export by ID. You can discover the ID of a dashboard in the Controller UI. When you open the dashboard in the UI, the ID appears as the dashboard parameter at the end of the URL.
For example, in this URL snippet, the custom dashboard ID is 3: location=CDASHBOARD_DETAIL&mode=MODE_DASHBOARD&dashboard=3.
Format
GET /controller/CustomDashboardImportExportServlet?dashboardId=dashboard_id
Input Parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
dashboardId | Query | The numeric ID of the custom dashboard. | Yes |
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/CustomDashboardImportExportServlet?dashboardId=8
{
"schemaVersion" : null,
"dashboardFormatVersion" : "3.0",
"name" : "Analytics-BrowserData",
...
"warRoom" : false,
"template" : false
}
View a complete response example:
Import Custom Dashboards and Templates
You can import custom dashboard and templates based on a previously exported JSON definition, which has optionally been modified. Import the definition as an application/json content type.
Data for this call should be in the form of multipart/form-data. Use UTF-8 URL encoding of the URI before posting; for example, do not replace a space (" ") with "%20" in the URI.
To import a dashboard, the user making the API call must have create dashboard permissions in the Controller.
Prior to version 4.1, exported custom dashboards were in XML format. You can import custom dashboards previously exported as XML data into the current Controller; however, custom dashboards can only be exported as JSON data.
Format
POST /controller/CustomDashboardImportExportServlet
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/CustomDashboardImportExportServlet -F file=@customdashboards.json
{"success":true,"errors":[],"warnings":[],"createdDashboardName":"Uploaded-Analytics-BrowserData"}
Export Health Rules from an Application
Returns all health rules in XML format.
The user account you use to make the API call must have permissions to view the health rule.
Format
GET /controller/healthrules/application_id?name=health_rule_name
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| name | Query | The name of the health rule to export. If not specified, exports all health rules. | No |
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/healthrules/38?name=MyCustomHealthRule
<health-rules controller-version="004-002-000-000">
<health-rule>
<name>MyCustomHealthRule</name>
<type>BUSINESS_TRANSACTION</type>
<description/>
<enabled>true</enabled>
<is-default>false</is-default>
<always-enabled>true</always-enabled>
<duration-min>30</duration-min>
<wait-time-min>30</wait-time-min>
<affected-entities-match-criteria>
<affected-bt-match-criteria>
<type>ALL</type>
</affected-bt-match-criteria>
</affected-entities-match-criteria>
<warning-execution-criteria>
<entity-aggregation-scope>
<type>ANY</type>
<value>0</value>
</entity-aggregation-scope>
<policy-condition>
<type>leaf</type>
<display-name>CPU</display-name>
<condition-value-type>BASELINE_STANDARD_DEVIATION</condition-value-type>
<condition-value>2.0</condition-value>
<operator>GREATER_THAN</operator>
<condition-expression/>
<use-active-baseline>true</use-active-baseline>
<metric-expression>
<type>leaf</type>
<function-type>VALUE</function-type>
<value>0</value>
<is-literal-expression>false</is-literal-expression>
<display-name>null</display-name>
<metric-definition>
<type>LOGICAL_METRIC</type>
<logical-metric-name>Average CPU Used (ms)</logical-metric-name>
</metric-definition>
</metric-expression>
</policy-condition>
</warning-execution-criteria>
</health-rule>
</health-rules>
Import Health Rules into an Application
You can import health rules defined in an XML file into a business application.
Data for this call should be in the form of multipart/form-data. In the POST request, use UTF-8 URL encoding for the URI; for example, do not replace a space (" ") with "%20" in the URI.
By default, a health rule in the posted data with an identical name to one in the existing configuration does not overwrite the existing health rule. If you want to overwrite an existing health rule of the same name, use the overwrite parameter.
The syntax is the same for importing one health rule configuration or several. All the health rule configurations in the posted XML file are imported.
Format
POST /controller/healthrules/application_id?overwrite=true_or_false
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| overwrite | Query | Set to true to have health rules in the posted data overwrite existing health rules with the same name. The default is false. | No |
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/healthrules/38 -F file=@uploadhealthrule.xml Imported 1 health rules successfully.
If the health rule exists and you have not enabled the overwrite parameters, you will get the following response:
Not importing the health rule: healthrulename since it already exists.
Export Transaction Detection Rules for All Entry Point Types
Gets all transaction automatic detection rules in XML format. This call returns the detection rule configurations for all entry point types.
You can get transaction detection rules from the application-level configuration or from the configuration for a specific tier by name.
The URI used by clients for this call should be UTF-8 encoded
Format
GET /controller/transactiondetection/application_id/[tier_name/]rule_type
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| tier_name | URI | The name of the tier from which you are exporting the entry point configuration. | No |
| rule_type | URI | The type of rule to export, from these options:
| Yes |
Examples
Export all auto-detection rules sample request:
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/38/auto
Export custom rules defined on a tier-level configuration sample request:
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/ECommerce/Inventory-Services/custom
Export all exclude rules sample request:
curl --user uesr1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/38/exclude
Import Transaction Detection Rules for All Entry Point Types
Imports automatic detection rules in XML format. This call can apply the imported configuration either at the application-level or for a specific tier. The tier configuration must be customized for the call to succeed.
Data for this call should be in the form of multipart/form-data. The URI for this call should be UTF-8 encoded.
Format
POST /controller/transactiondetection/application_id/[tier_name/]rule_type
Input parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| tier_name | URI | The name of the tier from which you are exporting the entry point configuration. | No |
| rule_type | URI | The type of rule to export, from these options:
| Yes |
| overwrite | Query | Use the overwrite parameter to overwrite a configuration of the same name. Without this parameter, if the import encounters a configuration for a component of the same name, the request will fail. | No |
Examples
Import custom rules and apply them to a tier-level configuration for the named teir. As indicated, duplicate rules not overwritten:
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/ECommerce/Inventory-Services/custom/ -F file=@customrules.xml Not importing the custom match config: Cron4J since there is already a config with the same name. Not importing the custom match config: JavaTimer since there is already a config with the same name. Not importing the custom match config: JCronTab since there is already a config with the same name. Not importing the custom match config: MongoBT since there is already a config with the same name. Not importing the custom match config: Quartz since there is already a config with the same name.
Import custom rules and apply to the application configuration, overwriting existing rules with the same name:
curl -X POST --user user1@customer1:welcome http://demo.appdynamics.com/controller/transactiondetection/38/custom?overwrite=true -F file=@customtransactionrules.xml
Export a Transaction Detection Rule for an Entry Point Type
Exports the configuration for a specific type of entry point type at the application-level or tier-level configuration.
To identify the entry point type, use the identifiers shown in the following table.
Entry point types names are case insensitive.
| Java | .NET | PHP | Node.js |
|---|---|---|---|
| binaryRemoting (for Thrift) servlet strutsAction springBean ejb pojo jms webService | aspDotNet (for ASP.NET) | phpWeb | nodeJsWeb |
The URI for this call should be UTF-8 encoded.
Format
GET /controller/transactiondetection/application_id/tier_name/rule_type/entry_point_type/rule_name
To export the rules for scopes rather than for tiers, simply omit the tier name:
GET /controller/transactiondetection/application_id/rule_type/entry_point_type/rule_name
Input Parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| tier_name | URI | The name of the tier from which you are exporting the entry point configuration. | No |
| rule_type | URI | The type of rule to export, from these options:
| Yes |
| entry_point_type | URI | The entry point type, such as servlet, pojo, aspDotNet or nodeJsWeb. | Yes |
| rule_name | URI | If using a custom or exclude rule, specify the name of the rule to import | No |
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/38/auto/servlet
<auto-discovery-config controller-version="004-004-000-000">
<rule-list>
<rule agent-type="APPLICATION_SERVER" enabled="true"
priority="0" rule-description="Java Auto Discovery Rule"
rule-name="Java Auto Discovery Rule"
rule-type="TX_MATCH_RULE" version="1">
<tx-match-rule>{"type":"AUTOMATIC_DISCOVERY","txautodiscoveryrule":{"autodiscoveryconfigs":[{"txentrypointtype":"SERVLET","monitoringenabled":true,"discoveryenabled":true,"namingschemetype":"URI","httpautodiscovery":{"usefulluri":false,"parturisegments":{"type":"FIRST","numsegments":2,"selectedsegments":[]},"namingconfiguration":{},"namevaluepairs":[]}}]},"agenttype":"APPLICATION_SERVER"}</tx-match-rule>
</rule>
</rule-list>
<scope-rule-mapping-list>
<scope-rule-mapping scope-name="Default Scope">
<rule rule-description="Java Auto Discovery Rule" rule-name="Java Auto Discovery Rule"/>
</scope-rule-mapping>
</scope-rule-mapping-list>
</auto-discovery-config>
Import Transaction Detection Rule for an Entry Point Type
Imports the automatic detection rule for a specified type of entry point and applies it at the named application-level or tier-level configuration for the business application.
The URI for this call should be UTF-8 encoded.
Format
POST /controller/transactiondetection/application_id/[tier_name/]rule_type/entry_point_type[/rule_name]
Input Parameters
Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
application_id | URI | The application name or application ID. | Yes |
| tier_name | URI | The name of the tier from which you are exporting the entry point configuration. | No |
| rule_type | URI | The type of rule to export, from these options:
| Yes |
| entry_point_type | URI | The entry point type, such as servlet, pojo, aspDotNet or nodeJsWeb. See entry point type information in Export an Automatic-Detection Rule for an Entry Point Type for the list of values to use. | Yes |
| rule_name | URI | If using a custom or exclude rule, specify the name of the rule to import | No |
| overwrite | Query | Use the overwrite parameter to overwrite a configuration of the same name. Without this parameter, if the import encounters a configuration for a component of the same name, the request will fail. | No |
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/transactiondetection/38/auto/servlet -F file=@servlettransaction.xml
Export Policies
You can export policies to a JSON file. Before you export policies, export any actions or health rules with their respective APIs.
Format
GET /controller/policies/application_id
Input Parameters
| Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
| application_id | URI | The application name or application ID. | Yes |
Example
curl --user user1@customer1:secret http://demo.appdynamics.com/controller/policies/application_id
[ {
"applicationName" : "ECommerce-Books",
"name" : "My Policy",
"reactorType" : "IMMEDIATE",
"enabled" : true,
"batchActionsPerMinute" : true,
"durationInMin" : 1,
"eventFilterTemplate" : {
"applicationName" : "ECommerce-E2E",
"healthRuleNames" : null,
"eventTypes" : [ "POLICY_OPEN_WARNING", "POLICY_OPEN_CRITICAL", "POLICY_CONTINUES_WARNING", "POLICY_CONTINUES_CRITICAL" ],
"rsdTypes" : null,
"customEventFilters" : null,
"specificEntityNamesByType" : null
},
"entityFilterTemplates" : [ ],
"actionWrapperTemplates" : [ {
"actionTag" : "ops_viewer@acme.com",
"type" : null,
"value" : 0,
"notes" : "Policy: My Policy",
"entityIdentifierTemplates" : [ ]
} ]
} ]
Import Policies
You can import policies that you exported with the Export Policies API. Before you import policies, import any actions or health rules with their respective APIs.
Format
POST /controller/policies/application_id
Input Parameters
| Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
| application_id | URI | The application name or application ID. | Yes |
Example
curl -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/policies/38 -F file=@ExportPolicies.json
{"success":true,"errors":[],"warnings":[]}
Export Application Analytics Dynamic Service Configuration
The Analytics Dynamic Service is an AppDynamics app agent plugin that performs Analytics client functions for the agent. Enabling the Dynamic Service enables AppDynamics Analytics for an app agent type. You can export the Dynamic Service configuration to back up the configuration or for later import into another Controller.
Format
GET /controller/analyticsdynamicservice/application_id
Input Parameters
| Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
| application_id | URI | The application name or application ID. | Yes |
| filename | Query | The name of a file to which the configuration will be exported. | No |
Example
curl -i --user user1@customer1:secret http://demo.appdynamics.com/controller/analyticsdynamicservice/10
<analytics-dynamic-service-configurations controller-version="004-003-000-000">
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>APP_AGENT</agent-type>
<enabled>true</enabled>
</analytics-dynamic-service-configuration>
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>DOT_NET_APP_AGENT</agent-type>
<enabled>true</enabled>
</analytics-dynamic-service-configuration>
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>NODEJS_APP_AGENT</agent-type>
<enabled>true</enabled>
</analytics-dynamic-service-configuration>
</analytics-dynamic-service-configurations>
Import Application Analytics Dynamic Service Configuration
The Analytics Dynamics Service configuration determines whether AppDynamics Analytics is enabled for an app agent type. You use this API to import a previously exported configuration to another Controller.
Data for this call should be in the form of multipart/form-data.
Format
POST /controller/analyticsdynamicservice/application_id
Input Parameters
| Parameter Name | Parameter Type | Value | Mandatory |
|---|---|---|---|
| application_id | URI | The name or ID identifier of the application to which the Analytics Dynamic Service configuration should be applied. | Yes |
Example
curl -i -X POST --user user1@customer1:secret http://demo.appdynamics.com/controller/analyticsdynamicservice/10 -F file=@dynamicservice.xml
The following listing shows sample contents of the dynamicservice.xml file. Notice that the agent-type element indicates the type of app server agent to which the enabled state of the dynamics service applies. The APP_AGENT type represents the Java Agent, the DOT_NET_APP_AGENT the .NET Agent, and so on.
<analytics-dynamic-service-configurations controller-version="004-003-000-000">
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>APP_AGENT</agent-type>
<enabled>false</enabled>
</analytics-dynamic-service-configuration>
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>DOT_NET_APP_AGENT</agent-type>
<enabled>false</enabled>
</analytics-dynamic-service-configuration>
<analytics-dynamic-service-configuration>
<override>true</override>
<agent-type>NODEJS_APP_AGENT</agent-type>
<enabled>true</enabled>
</analytics-dynamic-service-configuration>
</analytics-dynamic-service-configurations>
Overview
Content Tools
Apps
