Skip to content

API for AWS CodeDeploy

ABAP Interface /AWS1/IF_DPL

The "TLA" is a Three Letter Abbreviation that appears in ABAP class names, data dictionary objects and other ABAP objects throughout the AWS SDK for SAP ABAP. The TLA for AWS CodeDeploy is DPL. This TLA helps squeeze ABAP objects into the 30-character length limit of the ABAP data dictionary.


To install the AWS SDK for SAP ABAP, import the Core transport, along with the transport for the CodeDeploy module and other API modules you are interested in. A few modules are included in the Core transport itself. For more information, see the Developer Guide guide.

About The Service

CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances running in your own facility, serverless Lambda functions, or applications in an Amazon ECS service.

You can deploy a nearly unlimited variety of application content, such as an updated Lambda function, updated applications in an Amazon ECS service, code, web and configuration files, executables, packages, scripts, multimedia files, and so on. CodeDeploy can deploy application content stored in Amazon S3 buckets, GitHub repositories, or Bitbucket repositories. You do not need to make changes to your existing code before you can use CodeDeploy.

CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications, without many of the risks associated with error-prone manual deployments.

CodeDeploy Components

Use the information in this guide to help you work with the following CodeDeploy components:

  • Application: A name that uniquely identifies the application you want to deploy. CodeDeploy uses this name, which functions as a container, to ensure the correct combination of revision, deployment configuration, and deployment group are referenced during a deployment.

  • Deployment group: A set of individual instances, CodeDeploy Lambda deployment configuration settings, or an Amazon ECS service and network details. A Lambda deployment group specifies how to route traffic to a new version of a Lambda function. An Amazon ECS deployment group specifies the service created in Amazon ECS to deploy, a load balancer, and a listener to reroute production traffic to an updated containerized application. An Amazon EC2/On-premises deployment group contains individually tagged instances, Amazon EC2 instances in Amazon EC2 Auto Scaling groups, or both. All deployment groups can specify optional trigger, alarm, and rollback settings.

  • Deployment configuration: A set of deployment rules and deployment success and failure conditions used by CodeDeploy during a deployment.

  • Deployment: The process and the components used when updating a Lambda function, a containerized application in an Amazon ECS service, or of installing content on one or more instances.

  • Application revisions: For an Lambda deployment, this is an AppSpec file that specifies the Lambda function to be updated and one or more functions to validate deployment lifecycle events. For an Amazon ECS deployment, this is an AppSpec file that specifies the Amazon ECS task definition, container, and port where production traffic is rerouted. For an EC2/On-premises deployment, this is an archive file that contains source content—source code, webpages, executable files, and deployment scripts—along with an AppSpec file. Revisions are stored in Amazon S3 buckets or GitHub repositories. For Amazon S3, a revision is uniquely identified by its Amazon S3 object key and its ETag, version, or both. For GitHub, a revision is uniquely identified by its commit ID.

This guide also contains information to help you get details about the instances in your deployments, to make on-premises instances available for CodeDeploy deployments, to get details about a Lambda function deployment, and to get details about Amazon ECS service deployments.

CodeDeploy Information Resources

Using the SDK

In your code, create a client using the SDK module for AWS CodeDeploy, which is created with factory method /AWS1/CL_DPL_FACTORY=>create(). In this example we will assume you have configured an SDK profile in transaction /AWS1/IMG called ZFINANCE.

DATA(go_session)   = /aws1/cl_rt_session_aws=>create( 'ZFINANCE' ).
DATA(go_dpl)       = /aws1/cl_dpl_factory=>create( go_session ).

Your variable go_dpl is an instance of /AWS1/IF_DPL, and all of the operations in the AWS CodeDeploy service are accessed by calling methods in /AWS1/IF_DPL.

API Operations

For an overview of ABAP method calls corresponding to API operations in AWS CodeDeploy, see the Operation List.

Factory Method

/AWS1/CL_DPL_FACTORY=>create( )

Creates an object of type /AWS1/IF_DPL.


Required arguments:


Optional arguments:






/AWS1/IF_DPL represents the ABAP client for the CodeDeploy service, representing each operation as a method call. For more information see the API Page page.

Configuring Programmatically

DATA(lo_config) = DATA(go_dpl)->get_config( ).

lo_config is a variable of type /AWS1/CL_DPL_CONFIG. See the documentation for /AWS1/CL_DPL_CONFIG for details on the settings that can be configured.


Waiters for Implementation can be accessed via get_waiter() method followed by the waiter method to be called.

Details about the waiter methods available for service Implementation can be found in interface /AWS1/IF_DPL_WAITER.


Paginators for AWS CodeDeploy can be created via get_paginator() which returns a paginator object of type /AWS1/IF_DPL_PAGINATOR. The operation method that is being paginated is called using the paginator object, which accepts any necessary parameters to provide to the underlying API operation. This returns an iterator object which can be used to iterate over paginated results using has_next() and get_next() methods.

Details about the paginator methods available for service AWS CodeDeploy can be found in interface /AWS1/IF_DPL_PAGINATOR.