Making AppMap Data

You can improve the quality and accuracy of Navie AI by making AppMap Data for your project. Learn more about AppMap Data and how to make AppMap data by running your test cases or interacting with your application.

How AppMap Data Works

Language “agent”

The AppMap process begins with the AppMap recording agent. This “agent” is a language-specific library - agents are available for Java, Python, Ruby and Node.js (Beta). You add the agent as a dependency of your project in the normal manner - via Maven, Gradle, Pip, Bundler, Yarn, etc. Then you configure your application to load the agent when the application runs.

Java Python Ruby Node.js
-javaagent JVM option Django environment test and/or development bundle npx appmap-node yourapp
Gradle plugin Flask environment
Maven plugin FastAPI environment

AppMap is designed primarily to record full details of your code, including parameters and return values, as well as I/O (especially SQL and HTTP client requests), it includes log statements, the execution stack, timing information, and exceptions. It captures all of this with minimal configuration. It’s designed primarily for non-production environments.

appmap.yml configuration

When you start your app with the AppMap agent enabled, it reads a configuration file called appmap.yml. This file serves several basic purposes. It tells the AppMap agent:

  • Which code to record
  • Where to write the AppMap Data.

And it also tells other AppMap tools:

  • The project name
  • The language name
  • Where the AppMap Data is located

Note: In most environments, a default appmap.yml will be auto-generated by the AppMap agent if none exists.

About AppMap Data

AppMap Data is ordinary JSON files. As you record AppMap Data with test case recording, requests recording, or process recording, these JSON files are generated and written to the filesystem. The default location for AppMap Data is tmp/appmap, relative to the process working directory. Be sure that you know that the working directory of the application server is! You’ll need to know this to find and open your AppMap Diagrams.

When you use remote recording, the HTTP “stop” command responds with the AppMap in the response payload. It’s up to the client to decide where to write the file. For example, you can start and stop a remote recording using cURL, and write the output of the “stop” command to a file of your choosing.

When you use code block recording, it’s up to you in your code snippet to write the AppMap to a file. Naturally, you can direct the data anywhere you please.

AppMap files conform to the AppMap specification, which is freely available on GitHub.

With Test Case Recording

AppMap provides specialized support for recording test cases. When you run your test cases in a supported framework (there are many - see the language agent reference for details), a separate AppMap Diagram is created for each test case. AppMap Diagrams created from tests cases have some distinct features:

  • Each AppMap file is named for the test case, and stored in a folder called $appmap_dir/$test_framework
  • The test framework name and version are stored in the AppMap.
  • The test case name, file name and line number are stored in the AppMap.
  • The test status (succeeded or failed) and any test failure message are stored in the AppMap.

Recording the test suite of an application is a good way to quickly obtain a lot of data about an application. And because test cases work the same way for each build, recording test cases is also a good way to compare the behavior of application code across versions.

AppMap integrates with popular test frameworks, so you can automatically record an AppMap from each test case that you run.

Some benefits of test case recording include:

  • Named for the test case The name of each AppMap corresponds to the name of the test.
  • Includes source location The AppMap metadata contains the path and line number of the test case. From the AppMap Diagram, you can navigate to the test case code.
  • Supports incremental testing AppMap’s dependency analysis capability can help you re-run out-of-date test cases as you modify the code - even in very large repositories.

For details on test case recording, see:

With API Request Recording

For web applications, AppMap can be configured to record an AppMap for each HTTP server request handled by the app. This is a great way to collect data interactively. Just start the application with the AppMap language agent enabled, and start interacting with the app - manually, or using QA scripts or an API testing tool like Postman. AppMap Data is generated continuously as the application handles requests.

You can configure your application to record an AppMap of each HTTP server request.

Some characteristics of request recording include:

  • Named for the route The name of each AppMap contains the HTTP request method and path, so you can see at a glance what request AppMap contains.
  • Sortable by timestamp In the AppMap extension, AppMap Data recorded from requests are sorted by timestamp, with newest AppMap Diagrams at the top. So you can see a chronology of the requests that your app is serving.

For details on requests recording, see:

With Remote Application Recording

Remote recording is similar to requests recording, in that:

  • It’s for web applications
  • It makes AppMap Data as the application handles requests

But unlike requests recording, you control the boundaries of the AppMap, each AppMap can contain more than one HTTP server request, and it will also contain non-HTTP activity such as background jobs. To start a remote recording, you send an HTTP command to the AppMap agent running inside your application’s web stack to start recording. From that point on, everything that happens inside the application is recorded, until you send the “stop” command.

Remote recording enables you to create an AppMap while interacting directly with your app through the UI or API.

Some benefits of remote recording include:

  • Named by you When you finish creating a remote recording, you give it a name that makes sense to you. For example, you can name it for the user flow, or the ID number of the issue that you are trying to reproduce.
  • Contains a sequence of requests A remote recording AppMap contains the entire sequence of HTTP server requests that occur as you use the application.
  • Contains both foreground and background work A remote recording AppMap contains all threads of execution, not just the web server. So you can see background jobs, message queue activity, and other threads of activity along with the main HTTP server request.
  • Ideal for sharing When you reproduce a bug, security vulnerability, or performance problem in a remote recording AppMap, you can share it with colleagues so they can see exactly what the problem is. An AppMap contains much more information than the source code itself.

For details on remote recording, see:

With Code Block Recording

Some language agents enable you to make an AppMap by adding a simple code snippet to your code. This gives you total control over what’s recorded. The only downside of this is that you need access to the source code - which is not required by other recording methods. Refer to the AppMap Reference Guide for language specific configuration of this recording option.

With Process Recording

Process recording is something of a last resort, when other recording methods aren’t available. When you run your application with process recording enabled, everything that happens in the code (as configured by the appmap.yml) is recorded, from process startup to shutdown. Refer to the AppMap Reference Guide for language specific configuration of this recording option.

Was this page helpful? thumb_up Yes thumb_down No
Thank you for your feedback!