Skip to main content

Create function (Code-level)

This guide explains how developers create a function by defining its runtime environment, implementing execution logic, managing source code, and deploying function versions.

The focus of this guide is function implementation and lifecycle at the code level, rather than UI operations or job execution.

1. Function Concept

A function represents a reusable execution unit that encapsulates quantum or hybrid computation logic.

Each function consists of:

  • A runtime template (framework and execution environment)
  • Source code implementing the function logic
  • One or more versions
  • Deployment artifacts that make the function available for invocation

2. Defining Function Metadata

When creating a function, the following metadata is required.

Function Name

The function name uniquely identifies the function within a project.

Rules:

  • Allowed characters: lowercase letters (a–z), numbers (0–9), and hyphens (-)
  • Spaces are not allowed
  • Minimum length: 2 characters
  • Names must be unique within the project

If the name does not meet these rules or already exists, function creation will fail.

Description (Optional)

An optional description can be provided to explain the function’s purpose and intended use.

3. Selecting a Runtime Template

A runtime template defines:

  • The execution environment
  • The supported quantum or classical framework
  • The initial project structure

Examples of supported templates include:

  • Qiskit
  • Braket
  • CUDA Quantum
  • PennyLane
  • Other supported environments

Each template provides:

  • A default handler.py implementation
  • A compatible runtime environment
  • Framework-specific helper libraries

Important: The runtime template is immutable. Once the function is created, the template cannot be changed.

4. Function Versions

Each function is initialized with a default version (for example, v1).

A version represents:

  • A specific snapshot of the function’s source code
  • A deployable unit that can be independently invoked

Multiple versions allow developers to:

  • Iterate safely on implementation
  • Test new logic without affecting stable versions
  • Roll back to previous implementations if needed

5. Implementing Function Logic

Core Entry Point: handler.py

The handler.py file contains the primary execution logic of the function.

The function must expose a processing(invocation_input) method.

def processing(invocation_input):
# implement computation logic here
return result

invocation_input

  • Represents the input payload provided at invocation time
  • Typically contains parameters required for computation or circuit construction

Typical responsibilities of handler.py include:

  • Building quantum circuits
  • Preparing execution logic
  • Validating inputs
  • Returning execution results

Dependency Management: requirements.txt

The requirements.txt file specifies all Python dependencies required by the function.

  • Libraries listed here are installed automatically during deployment
  • Missing dependencies may cause deployment or runtime failures

Example:

qiskit
numpy

6. Modifying and Extending Source Code

Developers may customize the function implementation in several ways:

  • Edit the default template code
  • Add additional Python modules (*.py)
  • Upload custom source files to replace or extend existing logic

The platform supports both:

  • Direct code editing via the built-in editor
  • Uploading local Python files

All source code changes are tracked through function versioning.

7. Saving Changes and Version Creation

Whenever source code is modified:

  • Saving the changes creates a new function version
  • Each version preserves a complete snapshot of the source code
  • Versions can be selected independently for deployment

This mechanism enables controlled iteration and experimentation.

8. Deploying a Function Version

Deployment packages a specific function version into an executable artifact.

During deployment:

  • Dependencies from requirements.txt are installed
  • The source code is validated
  • The function version becomes available for invocation

After successful deployment:

  • The function can be invoked via SDK or API
  • The function version can be used to create execution jobs

9. Key Constraints and Best Practices

  • Runtime templates cannot be changed after function creation
  • Each deployment corresponds to a specific function version
  • Declare all required dependencies before deployment
  • Use versioning to isolate experimental changes from stable releases

10. Next Steps

After deploying a function, developers typically proceed to:

  • Invoke the function programmatically using SDK or API
  • Create and manage execution jobs based on the deployed function
  • Monitor execution results and logs

Refer to the following guides for more details: