Splunk® Cloud Services

SPL2 Search Manual

Exporting module items using SPL2

You can share searches, custom functions, and custom data types with other users by exporting those items from an SPL2 module. To export an item you use an export statement.

When you export an item that was created in an SPL2 module, such as a search or function, you are taking a private item and making the item public. To use the exported item in another module, you must import the item into that module.

In addition to exporting items that are created inside an SPL2 module, you can also export items that have been imported into an module, such as a dataset.

Exporting search statements

When you export a search statement, the search is exported as a view.

A view is a reusable, named piece of SPL2. A view is a type of dataset that is like a saved search. When you export a search, you are not saving the search results as a dataset. You are saving the search that generates the dataset as a view. To learn more about views, see SPL2 Views.

Export statement syntax

The export statement syntax depends on whether you are exporting one or multiple items, and how you want to format the export statement

The export statement syntax is:

export <item_name> | { <item_name>, <item_name>, ...}

When specifying multiple items, you must enclose them in curly brackets { } and separate each item with a comma ( , ).

Export a search

In the module where the search resides, export the search by issuing an export statement.

Consider the following search:

$purchases = from main where status=200 AND action="purchase" 

The following export statement shows how to export this search as a view:

export $purchases

This export statement is shorthand for specifying an alias:

export $purchases as purchase

The dollar sign ( $ ) in front of the search name is not included in the view name.

In the following image, the purchases namespace contains two modules, Quarterly Purchases and annual_purchases. The Quarterly Purchases module contains a search statement called $purchases, and a function statement called isError. The $purchase search statement has been exported as a view called purchases. The isError function statement has also been exported.

This image shows a namespace that includes two modules. A search statement has been exported as a view called "purchases", as described by the text before the image.

Export multiple searches as views

To export multiple searches, which are exported as views, enclose the list of searches in curly brackets { }.

For example:

export {$qtr1, $qtr2, $qtr3, $qtr4}

Alternatively, you can issue multiple export statements, for example:

export $qtr1
export $qtr2
export $qtr3
export $qtr4

Export groups of items using a wildcard

You can use a single statement to export some types of items that have been imported into or created in a module. Using a wildcard to export items, does not export the views. The basic syntax is:

export *

The following table lists the items that can and cannot be exported using export *:

Included with export * Excluded with export *
These items that are defined in the module:
  • Local functions.
  • Local datasets, except local views.
  • Local data type declarations.
Locally defined views.


You must export the views using the syntax export {<view_name>, <view_name>, ...}.

Any imports, except for wildcard namespace aliases. Such as:
  • Imported datasets.
  • Imported views.
  • Imported functions.
  • Imported data type definitions.
Wildcard namespace alias imports. For example import * as <item>. These items must be exported separately.
Implicit imports. For example, items in the same namespace from the _default module don't require an import statement. See the example later in this topic.

Example of export using a wildcard

Consider the following portion of the biz_set_1 module.

  • An index and a function are imported into the module.
  • Individual export statements are used to export each item from the module.

biz_set_1 module

import main from ../../../../indexes 
import roundif  // This function rounds values to a set number of decimal points if the value is greater than 1.

export main // This index is exported.
export $top10threats  // This search is exported as a view dataset.
export $metrics  // This search is exported as a view dataset.
export isError  // This local function looks for error codes greater than or equal to 400.
export roundif   // An imported function that is being exported.

You can export some of these items using a wildcard, for example:

biz_set_1 module

export * // Exports the imported index "main", the local function "isError", and the imported function "roundif". 

To export the searches as views, you need a separate export statement, for example:

biz_set_1 module

export {$top10threats, $metrics}  // These searches are exported as views.

Example of implicit imports

Suppose you the _default module and another module called biz_set_1 in the same namespace.

_default module

import main from ../../../../indexes 
import isError // Function from the 'biz_set_1 module

function roundif ... // Local function

search $incident_frequency= ...  // Local view
search $frequency_by_region= ... // Local view

export main // Imported index 
export isError // Imported function
export roundif  // Local function
export $incident_frequency // Local view
export $frequency_by_region // Local view

biz_set_1 module

import threats from ../../../../indexes 

function isError ... // Local function. Uses the <code>roundif</code> function 
from the <code>_default</code> module.

search $top10threats= ... // Local view that uses the imported "threats" index.
search $metrics= ... // Local view that uses the implicitly imported "main" 
index.

export threats  // Imported index
export isError  // Local function
export $top10threats= ... // Local view
export $metrics= ... // Local view

The items exported from the _default module can be used by biz_set_1 module without requiring an import statement in the biz_set_1 module. This is referred to an implicit import.

For example, because the main index and the roundif function are exported from the _default module module, you can use these items in the biz_set_1 module without specifying an import statement. These items are implicitly imported. In addition, because the roundif function is used within the isError function, you do not need to export the roundif function from the biz_set_1 module. The same is true for the main index, which is used in the $metrics search.

You can use export * to export the indexes and functions from the biz_set_1 module. The local views require a specific export statement. For example:

biz_set_1 module

import threats from ../../../../indexes 

function isError ... // Local function that uses the <code>roundif</code> function 
from the <code>_default</code> module.

search $top10threats= ... // Local view that uses the imported "threats" index.
search $metrics= ... // Local view that uses the implicitly imported "main" 
index.

export * // Exports the imported index "threats" and the local 
function "isError". The "main" index and the "roundif" function do not need 
to be explicitly exported.
export {$top10threats, $metrics} // Exports these local views

For the implicit import example we would just need to defined a _default module within the same namespace as the example and export some items from that default module, then call out that while those can be referenced within the example module without being imported they are NOT included as exports in export * so any modules outside of the namespace that are trying to import the example module will not have access to those implicitly imported items

Export and rename a search

To rename a search when you export it, use an as clause.

When you export a search, you do not include the dollar symbol ( $ ) in the alias name.

For example:

export $transactions as QTR1_transactions

The search is exported as a view dataset.

Exporting functions

You can share custom functions with other users by exporting those functions.

Export a function

In the module where the function resides, you export the function by issuing an export statement.

For example, suppose you have the following function:

function isError($code : number) : boolean {
  return $code >= 400 
}

To export the isError function, you use this export statement:

export isError

Export and rename a function

To rename a custom function when you export it, use the as clause.

The following example shows how to export the isError function using the name HTTP_Errors:

export isError as HTTP_Errors


Exporting data types

You can export custom data types to share those data types with other users and groups.

Export a data type

In the module where the data type resides, export the data type by issuing an export statement.

For example, suppose you have the following data type:

type person = {
   firstname:string, 
   surname:string
}

To export the person data type, the export statement is:

export person


Export and rename a data type

To rename a custom data type when you export it, use the as clause.

The following example shows how to export the person data type using the name fullname:

export person as fullname

Export statement shortcuts

You can combine a function statement inline with an export statement.

When you combine these statements, the function statements are valid in the current module. The items that are exported become public items, which can be imported and used in other modules.

Shortcut for combining functions and export statements

Consider the following function that looks for HTTP error codes that are greater than or equal to 400:

function isError($code : number) : boolean {
  return $code >= 400 
}

To export this function, you can use the following the statement:

export isError

The following shortcut combines these statements:

export function isError($code : number) : boolean {
  return $code >= 400 
}

You can use the isError function in the current module, as well as export the function to share the function with other users and groups.

See also

Related information
Importing items using SPL2
Related reference
Custom eval functions
Custom command functions
Custom data types
Last modified on 14 January, 2025
Extend and branch SPL2 search statements   Importing module items and datasets using SPL2

This documentation applies to the following versions of Splunk® Cloud Services: current


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters