diff --git a/.azure/dev-pr-check.yaml b/.azure/dev-pr-check.yaml
index e4dc9484a8..96d4da1311 100644
--- a/.azure/dev-pr-check.yaml
+++ b/.azure/dev-pr-check.yaml
@@ -1,7 +1,7 @@
pr:
branches:
include:
- - dev
+ - PE
trigger: none
diff --git a/.azure/templates/build.yaml b/.azure/templates/build.yaml
index feea157d14..5ce0737045 100644
--- a/.azure/templates/build.yaml
+++ b/.azure/templates/build.yaml
@@ -42,23 +42,48 @@ steps:
cwd=`pwd`
- for dir in ${cwd}/*/; do
- if [ -d ${f} ]; then
- dir=${dir%*/}
- dirName=${dir##*/}
- if [ ${dirName} != "dist" ]; then
- mkdir -p $(Build.ArtifactStagingDirectory)/dist/${dirName}
- cd ${dir}
+ # Define known document directories and their site subdirectories
+ declare -A SITE_DIRS=(
+ ["developer-docs"]="developer"
+ ["pe-docs"]="platform-engineer"
+ )
- pwd
- mkdocs build -c
-
- cd ../..
- ls ${cwd}/${dirName}/site/
- mv -f ${cwd}/${dirName}/site/* $(Build.ArtifactStagingDirectory)/dist/${dirName}/
+ # Process only the required directories
+ for doc_dir in "${!SITE_DIRS[@]}"; do
+ echo "Processing ${doc_dir}..."
+ # Find the parent directory containing this doc directory
+ for parentDir in ${cwd}/*/; do
+ if [ -d "${parentDir}${doc_dir}" ]; then
+ parentDir=${parentDir%*/}
+ parentDirName=${parentDir##*/}
+
+ # Create destination directory
+ mkdir -p $(Build.ArtifactStagingDirectory)/dist/${doc_dir}
+
+ # Build the documentation
+ cd "${parentDir}/${doc_dir}"
+ pwd
+ mkdocs build -c
+
+ # Move the built files to the staging directory
+ site_subdir="${SITE_DIRS[${doc_dir}]}"
+ echo "Moving files from site/${site_subdir}/ to dist/${doc_dir}/"
+ ls "${cwd}/${parentDirName}/${doc_dir}/site/${site_subdir}/"
+ mv -f "${cwd}/${parentDirName}/${doc_dir}/site/${site_subdir}"/* $(Build.ArtifactStagingDirectory)/dist/${doc_dir}/
+
+ # Return to the original directory
+ cd "${cwd}"
+ break
fi
- fi
+ done
done
echo "=== After building ==="
- ls -l $(Build.ArtifactStagingDirectory)/dist/
+ # Check that the expected directories have content
+ for doc_dir in "${!SITE_DIRS[@]}"; do
+ ls -l $(Build.ArtifactStagingDirectory)/dist/${doc_dir}
+ if [ -z "$(ls -A $(Build.ArtifactStagingDirectory)/dist/${doc_dir})" ]; then
+ echo "Error: ${doc_dir} directory is empty."
+ exit 1
+ fi
+ done
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 225b5972dc..30f97f36a5 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,8 +1,8 @@
-name: ci
+name: ci
on:
push:
branches:
- - dev
+ - PE
permissions:
contents: write
jobs:
@@ -17,7 +17,7 @@ jobs:
- uses: actions/setup-python@v5
with:
python-version: 3.12
- - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
+ - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
- uses: actions/cache@v4
with:
key: mkdocs-material-${{ env.cache_id }}
@@ -44,6 +44,34 @@ jobs:
pip install mkdocs-glightbox==0.3.4
pip install mkdocs-include-markdown-plugin==1.0.0
pip install mkdocs-open-in-new-tab==1.0.3
- - run: mkdocs gh-deploy --config-file en/mkdocs.yml --force
+ - name: Build site developer
+ run: mkdocs build --config-file en/developer-docs/mkdocs.yml
+ - name: Build site platform-engineer
+ run: mkdocs build --config-file en/pe-docs/mkdocs.yml
+ - name: Create/fetch gh-pages-v2
+ run: |
+ if git ls-remote --heads origin gh-pages-v2 | grep -q gh-pages-v2; then
+ git fetch origin gh-pages-v2
+ git checkout gh-pages-v2
+ else
+ git switch --orphan gh-pages-v2
+ fi
+ - name: Create gh-pages-v2 branch developer subdirectory
+ run: |
+ rm -rf choreo/docs/developer # Clear existing directory if needed
+ mkdir -p choreo/docs/developer
+ cp -r en/developer-docs/site/developer/* choreo/docs/developer/
+ - name: Create gh-pages-v2 branch platform-engineer subdirectory
+ run: |
+ rm -rf choreo/docs/platform-engineer # Clear existing directory if needed
+ mkdir -p choreo/docs/platform-engineer
+ cp -r en/pe-docs/site/platform-engineer/* choreo/docs/platform-engineer/
+ - name: Push Changes to gh-pages-v2
+ run: |
+ git add choreo/docs/developer/
+ git commit -m "Update developer directory"
+ git add choreo/docs/platform-engineer/
+ git commit -m "Deploy to platform-engineer directory"
+ git push origin gh-pages-v2 --force
env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/README.md b/README.md
index fad1011516..7042d0d190 100644
--- a/README.md
+++ b/README.md
@@ -103,7 +103,7 @@ $ pip install --upgrade pip
To clone the Choreo documentation GitHub repository and run the site on your local server, follow these steps:
1. Fork `https://github.com/wso2/docs-choreo-dev`.
-2. Navigate to the locatiion where you want to clone the repo and clone the forked repository.
+2. Navigate to the location where you want to clone the repo and clone the forked repository.
```shell
$ git clone https://github.com/[git-username]/docs-choreo-dev.git
diff --git a/en/docs/administer/configure-a-custom-domain-for-your-organization.md b/en/developer-docs/docs/administer/configure-a-custom-domain-for-your-organization.md
similarity index 81%
rename from en/docs/administer/configure-a-custom-domain-for-your-organization.md
rename to en/developer-docs/docs/administer/configure-a-custom-domain-for-your-organization.md
index 60c63687b3..763e1bb335 100644
--- a/en/docs/administer/configure-a-custom-domain-for-your-organization.md
+++ b/en/developer-docs/docs/administer/configure-a-custom-domain-for-your-organization.md
@@ -6,7 +6,7 @@ This section provides an overview of Choreo’s custom domain configuration mode
## Choreo custom domain configuration model
-Choreo allows organization administrators to add custom domains for their organizations. When an administrator adds custom domains to an organization, component developers can submit requests to utilize the custom domains for their respective components. These requests require approval from the organization administrator. Upon approval, the custom domain and the relevant URL customization become available to the component.
+Choreo allows organization administrators to add custom domains for their organizations. When an administrator adds custom domains to an organization, developers can utilize the custom domains for their respective components.
## Configure a custom domain for an organization
@@ -123,7 +123,7 @@ You can see the added custom domain listed in the **Active Domains** tab under t

-The custom domain you added will be available to the entity types in the specified environment. You can request the custom domain when configuring a custom URL for a component.
+The custom domain you added will be available to the entity types in the specified environment. You can use the custom domain when configuring a custom URL for a component.
!!! info "Note"
If you add a custom domain for the **Developer Portal** type, the customization is applied immediately, and you can access the organization’s Developer Portal via the added domain.
@@ -132,14 +132,14 @@ If you want to view the entity types that use a particular custom domain, click
## Configure a custom URL for a component
-When an organization administrator adds custom domains for specific environments, developers can request any available custom domain to configure a custom URL for a component in a specific environment.
+When an organization administrator adds custom domains for specific environments, developers can use any available custom domain to configure a custom URL for a component in a specific environment.
-### Request a custom URL for a component
+### Add a custom URL to a component
-To request a custom URL for your component, follow the steps given below:
+To add a custom URL for your component, follow the steps given below:
!!! info "Note"
- Before you request a custom domain for a specific environment, ensure that the component is deployed to that environment.
+ Before you add a custom domain for a specific environment, ensure that the component is deployed to that environment.
1. Sign in to the [Choreo Console](https://console.choreo.dev/).
2. In the **Component Listing** pane, click on the component for which you want to customize the URL.
@@ -148,41 +148,24 @@ To request a custom URL for your component, follow the steps given below:

-5. To configure a custom URL for a component in a specific environment, click the **Edit URL Mapping** icon under the **Action** column corresponding to the respective environment. This opens the **URL Settings** dialog, where you can specify values to request for a custom URL.
+5. To configure a custom URL for a component in a specific environment, click the **Edit URL Mapping** icon under the **Action** column corresponding to the respective environment. This opens the **URL Settings** dialog, where you can specify values to add to a custom URL.

6. In the **URL Settings** dialog, select a domain to configure a custom URL.
!!! tip
- - The **Domain** drop-down lists the available domains for the component. You can request for any listed domain.
- - If you want to request a custom URL for an API, you must specify an appropriate context path in the **Path** field. The **Path** field displays the default context path for the API. You can edit the path depending on your preference.
+ - The **Domain** drop-down lists the available domains for the component. You can add any listed domain.
+ - If you want to add a custom URL for an API, you must specify an appropriate context path in the **Path** field. The **Path** field displays the default context path for the API. You can edit the path depending on your preference.
-7. Click **Configure**. This creates the custom URL mapping, which you can see under the **URL Settings** tab. The custom URL request will be in the **Pending** status until an organization administrator approves the request.
+7. Click **Deploy**. This creates the custom URL mapping, which you can see under the **URL Settings** tab. The custom URL will be in the **Approved** state.
- 
-
-### Approve a custom URL request
-
-When a developer requests a custom URL, the request will be listed in the organization-level settings page under the **URL Settings** tab.
-
-To approve a custom URL mapping, follow the steps given below:
+ 
!!! info "Note"
- To approve custom URL requests, you must have organization administrator privileges.
-
-1. Sign in to the [Choreo Console](https://console.choreo.dev/).
-2. In the Choreo Console header, click the **Organization** list.
-3. In the left navigation menu, click **Settings**. This opens the organization-level settings page.
-4. Click the **URL Settings** tab and then click the **Pending URL Requests** tab. You will see all the pending URL mapping requests sent by developers.
-
- 
-
+ By default, any user with the `Manage URL Mappings` permission can deploy custom URL mappings. For better governance, you can configure an approval process for URL mappings using [Choreo Workflows](./configure-approvals-for-choreo-workflows.md).
-5. Go to the custom URL you want to approve and click the corresponding **Approve URL Mapping** icon under the **Action** column.
-6. Review the details and click **Approve**.
-
- Once approved, the invoke URL of the component gets replaced with the configured custom URL.
+ Once deployed, both the custom URL and the default URL can be used to access the component.

diff --git a/en/docs/administer/configure-a-user-store-with-built-in-idp.md b/en/developer-docs/docs/administer/configure-a-user-store-with-built-in-idp.md
similarity index 100%
rename from en/docs/administer/configure-a-user-store-with-built-in-idp.md
rename to en/developer-docs/docs/administer/configure-a-user-store-with-built-in-idp.md
diff --git a/en/docs/administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp.md b/en/developer-docs/docs/administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp.md
similarity index 100%
rename from en/docs/administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp.md
rename to en/developer-docs/docs/administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp.md
diff --git a/en/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md b/en/developer-docs/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md
similarity index 95%
rename from en/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md
rename to en/developer-docs/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md
index 237e30f676..bf8a4cb77f 100644
--- a/en/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md
+++ b/en/developer-docs/docs/administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp.md
@@ -24,7 +24,7 @@ Follow the steps below to add Azure AD as an IdP in Choreo:
!!! info
- In azure, there are two versions of access tokens available. By default, the IDP applications you create use the v1 access token. Therefore, if you intend to use the v1 access token, when providing the `Well-Known URL`, omit the v2.0 path segment from the URL. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#token-formats)
For example, convert `https://login.microsoftonline.com/ Note A custom domain is essential for effective branding, discoverability, and credibility of a website. Choreo allows you to easily configure custom domains for your organization, enabling developers to utilize it to configure custom URLs for their components such as API proxies, services, web applications, and webhooks. This section provides an overview of Choreo’s custom domain configuration model and guides you through configuring a custom domain for your organization. It also walks you through utilizing a custom domain to configure a custom URL for a component. Choreo allows organization administrators to add custom domains for their organizations. When an administrator adds custom domains to an organization, component developers can submit requests to utilize the custom domains for their respective components. These requests require approval from the organization administrator. Upon approval, the custom domain and the relevant URL customization become available to the component. Create an organization in Choreo. To add a custom domain for your organization, follow the steps given below: Note To add a custom domain, you must have organization administrator privileges. In the Add a Custom Domain pane, do the following: Select the entity type to apply the domain name. Tip In this context: Take a look at the generated CNAME target value displayed and create a DNS record associating the domain name to the CNAME target value with your DNS provider. Once the CNAME type DNS record is created, click Verify. Note If the CNAME mapping is correct, the verification completes successfully. It can take some time for the configured CNAME mapping to be globally available. On successful verification of the custom domain, click Next. Select a TLS certificate provider depending on your preference. You can either import the TLS certificates you created for the custom domain or click Let's Encrypt to allow Choreo to generate and manage the certificates for you. If you want to import your own certificate, it should adhere to specific guidelines To proceed with this step in this guide, click Let's Encrypt. To save the custom domain, click Add. Now, you have successfully added a custom domain for your organization. You can see the added custom domain listed in the Active Domains tab under the URL Settings tab. The custom domain you added will be available to the entity types in the specified environment. You can request the custom domain when configuring a custom URL for a component. Note If you add a custom domain for the Developer Portal type, the customization is applied immediately, and you can access the organization’s Developer Portal via the added domain. If you want to view the entity types that use a particular custom domain, click the specific custom domain listed in the Active Domains tab under URL Settings. When an organization administrator adds custom domains for specific environments, developers can request any available custom domain to configure a custom URL for a component in a specific environment. To request a custom URL for your component, follow the steps given below: Note Before you request a custom domain for a specific environment, ensure that the component is deployed to that environment. Click the URL Settings tab. This displays the active deployments of the component across different environments and indicates whether a custom URL is configured. If an active custom domain is available to configure a custom URL for a component in a specific environment, the Edit URL Mapping icon in the corresponding Action column becomes enabled. To configure a custom URL for a component in a specific environment, click the Edit URL Mapping icon under the Action column corresponding to the respective environment. This opens the URL Settings dialog, where you can specify values to request for a custom URL. In the URL Settings dialog, select a domain to configure a custom URL. Tip Click Configure. This creates the custom URL mapping, which you can see under the URL Settings tab. The custom URL request will be in the Pending status until an organization administrator approves the request. When a developer requests a custom URL, the request will be listed in the organization-level settings page under the URL Settings tab. To approve a custom URL mapping, follow the steps given below: Note To approve custom URL requests, you must have organization administrator privileges. Click the URL Settings tab and then click the Pending URL Requests tab. You will see all the pending URL mapping requests sent by developers. Go to the custom URL you want to approve and click the corresponding Approve URL Mapping icon under the Action column. Once approved, the invoke URL of the component gets replaced with the configured custom URL. Now you have successfully utilized the configured custom domain to set up a custom URL for a component. Developers looking to experiment with a complete application development process that includes user authentication and authorization can utilize Choreo's built-in identity provider (IdP). Choreo's built-in identity provider allows you to seamlessly test your application's authentication by setting up test users and groups within Choreo. Note Although the built-in IdP facilitates user management support, it is limited to adding users with attributes and groups. Therefore, the built-in IdP user management capabilities are not recommended for use in production. Before you try out the steps in this guide, be sure you have administrator rights to your Choreo organization. This permission is essential to configure a user store with the built-in IdP. Follow the steps given below to configure a Choreo built-in IdP user store for an environment: Note The provided template file includes a sample user with associated attributes. To add new users, insert additional rows in the Asgardeo is an identity-as-a-service (IDaaS) solution designed to create seamless login experiences for your applications. Asgardeo seamlessly integrates with Choreo, providing powerful API access control through the use of API scopes. This enables restricting API access to designated user groups. By configuring Asgardeo as an external IdP in Choreo, you can leverage your Asgardeo user stores to manage API access control effectively. This guide walks you through the steps to set up Asgardeo as your external IdP. Before you proceed, be sure to complete the following: Create an Asgardeo application. You can follow the Asgardeo guide to register a standard-based application. Find the well-known URL:
- Go to the info tab of the Asgardeo application to view the endpoints and copy the Discovery endpoint. Find the Client ID:
- Go to the Protocol tab of the Asgardeo application and copy the Client ID. Follow the steps below to add Asgardeo as an external IdP in Choreo: Leave the Apply to all environments checkbox selected. This allows you to use the tokens generated via this IdP to invoke APIs across all environments. Note If you want to restrict the use of tokens generated via this IdP to invoke APIs in specific environments, clear the Apply to all environments checkbox and select the necessary environments from the Environments list. Click Next. This displays the server endpoints that are useful to implement and configure authentication for your application. Now you have configured Asgardeo as an external IdP in Choreo. In organizations leveraging Microsoft Azure Active Directory (Azure AD) for identity and access management (IAM), integrating it with Choreo offers powerful API access control. This control hinges on the use of API scopes. That is, it enables the restriction of access to a designated group of users. This document guide you step-by-step to configure Azure AD as your external IdP. Before you try out this guide, be sure you have the following: Follow the steps below to add Azure AD as an IdP in Choreo: To obtain the Info Leave the Apply to all environments checkbox selected. However, if you want to restrict the use of the external IdP to a certain environment, you can select them from the Environments list. With Choreo, you can configure enterprise login to allow users from an external identity provider (IdP) to sign in to Choreo seamlessly without changing their credentials. This guide walks you through the steps to configure enterprise login for your organization in Choreo. Before you proceed with the configuration, set up the following: To configure enterprise login for your Choreo organization, follow the steps given below: If you already have a support account with us, send us your organization name/handle and the email domains specific to your organization through our support portal. If you do not have a support account with us yet, send an email to Tip Ensure you include the following information in the request: Sample email Subject : [Stark Industries] Configure enterprise login Hi CS team, I need to configure enterprise login for my organization. Can you please do the necessary configurations to proceed? My organization details are as follows: Thank you. The Choreo support team will perform the necessary configurations and respond to you with a verification code. You must sign in to your domain host account and configure the DNS record for your email domain with the following values: Now, you are ready to bring your own identity to Choreo. When you create an organization in Choreo, an organization with the same name is provisioned for you in Asgardeo. To bring your own identity to Choreo, you must configure a federated enterprise IdP on Asgardeo in the organization that is provisioned for you. Follow the steps given below to configure the federated IdP: Now, users in your enterprise IdP can sign in to the Choreo Console using their enterprise IDs. To streamline the enterprise login process and grant appropriate permission, Choreo provides the flexibility to configure role-based access control for users who reside in an external IdP. To set up role-based access control for enterprise login within Choreo, follow the steps given below: Before you proceed with the configuration, make sure you complete the following: Configure your IdP as an external IdP in Asgardeo. Depending on your IdP, you can select OpenID Connect or SAML as the protocol between Asgardeo and your IdP. Note If you are using OpenID Connect, configure the requested scopes accordingly for Asgardeo to get the relevant group/role details from the external IdP. To configure the application, follow the steps given below: Configure the IdP for login depending on the protocol you selected: Click the User Attributes tab. To add the user attributes as OpenID Connect scopes, follow the steps given below: Note Before you map Choreo groups to enterprise IdP groups, ensure you meet the following criteria: Click the edit icon corresponding to the Choreo group you want to map to the enterprise IdP group. In the IdP Group Name field, specify the exact name you configured in the enterprise IdP and enter to add it. Tip If there is a change to the IdP group mapping, it takes effect from the next login session onwards. Click Save. By following these steps, you have successfully configured role-based access control for enterprise login in Choreo, allowing users from the external IdP to have the appropriate permission. With Choreo, you can set up a self-sign-up page for your Developer Portal. The self-sign-up page allows users to easily access your Developer Portal and subscribe to APIs. When you configure self-sign-up, users can create their accounts and access your Developer Portal without any manual intervention from you. This page walks you through the steps to configure self-sign-up for your Developer Portal. To configure self-sign-up, follow the steps given below: Send an email to choreo-help@wso2.com requesting to configure enterprise IdP for the Developer Portal of your organization. Tip Ensure you include the organization name or handle in the request. Sample email Subject : [Stark Industries] Configure enterprise IdP for Developer Portal Hi CS team, I need to configure enterprise IdP for my organization’s Developer Portal to enable self-sign-up. Can you please do the necessary configurations to proceed? My organization details are as follows: Thank you The Choreo support team will perform the necessary configurations and respond to your request. When you receive a response, sign in to Asgardeo using the same credentials that you used to sign in to Choreo. In the Asgardeo Console, click View all applications. You will see an application named WSO2_LOGIN_FOR_CHOREO_DEV_PORTAL. Click on the application to edit it and enter your organization’s Developer Portal URL as the Access URL of the application. For example, To add user attributes, follow these steps: Note If you have enabled enterprise login and you want to add the Groups attribute during self-sign-up configuration, avoid making it mandatory. This ensures proper access control and prevents unauthorized privileges. If you make the Groups attribute mandatory, it allows self-signed-up users to specify a group and assume roles associated with it. To add the email as a mandatory user attribute, select Email and click the arrow to expand the section. Then, select the Requested and Mandatory checkboxes. To add the first name and last name as optional attributes, select Profile and click the arrow to expand the section. Then, select the Requested checkbox for the First Name and the Last Name attributes. Click Update. To add the user attributes as OpenID Connect scopes, follow these steps: To configure basic authentication as the sign-in method, follow these steps: To configure self-registration, follow these steps: Click Update. Once you complete these steps, you will see a sign up link similar to the following in your Developer Portal: Users can click LOGIN/SIGN UP and then click Create an account to sign up to access your Developer Portal. To manage users who want to access your Developer Portal via self-sign-up, you have two possible approaches: To automatically approve each new user account registered on your Developer Portal, follow the steps given below: Once you enable auto-approval, users can sign in to your Developer Portal and view your APIs and applications immediately after creating an account. If you have not enabled auto-approval, you can manually approve or reject new user registrations. Once a user creates an account, Choreo sends an email to ask the user to confirm the account. To manually approve or reject user accounts, follow the steps given below: To approve a user account, click Approve. To reject an account, click Reject. If you reject an account, the user will receive an email mentioning that their account is rejected. Note A rejected user cannot sign up to your Developer Portal using the same account again. In the Choreo Console, you have the ability to manage access to projects and the actions that can be performed within them. Administrators have the capability to restrict project access to specific user groups. This feature is useful when you need certain user groups to have access to particular projects or for a set of projects. Choreo uses Roles, Groups, and a Mapping level to control access to the Choreo Console as follows: Group : Group is a collection of users. A user group requires a role or multiple roles to be assigned to it so that the users in those groups get the relevant permissions via the assigned roles. Learn more Mapping level : A mapping level defines the extent at which a role-group mapping can be done. Choreo has two defined resource levels. In Choreo, authorization operates by assigning a role to a group at a specified level. The level at which the role is assigned determines the extent of permissions granted to users. Important Avoid assigning multiple roles to a single user across different projects or levels (organization and project). Such assignments can grant users unintended permission to some projects, allowing them to perform tasks they shouldn't have access to. Therefore, it is recommended to assign only one role to a user across projects or levels to ensure proper access control. Info In Choreo, organization-level permissions take precedence over project-level permissions. To elaborate further, refer to the following diagram. The following diagram depicts a role-group assignment at a specific resource level. In the diagram, an admin user has assigned the Developer role to all members of the Engineering group within the Engineering Project. This grants users in the Engineering group the ability to perform all actions allowed by the Developer role within the Engineering Project. Now that you understand the basic concepts of access control within the Choreo Console, let’s try out a sample scenario to manage access within a project. Assume you are overseeing the Engineering Project within your organization and you need to grant development access to specific users solely within this project. Here's a step-by-step guide on how to achieve this: Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Info In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and takes you to the project home page. Follow the steps given below to create a group with the name Enter a group name and group description. You can enter the values given below: Click Create. Follow the steps given below to assign the Developer role to the Engineering Project Developer group that you created: Click Add. This assigns the Developer role to the group. You should see the mapping level as Project (Engineering Project) as follows, indicating the scope of the mapping: This means that you have granted developer access to users in the Engineering Project Developer group in the scope of the Engineering Project. Now that you have set up access control, you can proceed to add users to the new group. There are two approaches you can follow to add users to the group. Follow the steps given below to add a new user as a project developer: Follow the steps given below to add an existing user as a project developer: Tip Make sure to remove the user from any other groups to avoid granting organization-level access unintentionally. Note Now you have successfully set up access control within your project. API subscription plans are essential to control and manage access to APIs. These plans define the rules and limitations on how clients can interact with APIs, ensuring efficient resource utilization and robust security. With the option to set rate limits and burst control, subscription plans allow API providers to manage traffic, prevent misuse, and offer tiered service levels. Organizations can implement subscription plans to provide varying levels of API access, accommodating different user needs and business models, while ensuring optimal performance and security. In Choreo, users with the administrator role can create, update, and delete subscription plans at the organization level. Tip Deleting a subscription plan is only possible if there are no active subscriptions associated with it. To create an organization-level subscription plan, follow the steps given below: In the Create Subscription Plan pane, enter the appropriate values for each field: Note Click Create. This creates the subscription plan and lists it under Subscription Plans. After creating subscription plans, users with the API publisher role can assign subscription plans to APIs. API consumers can then choose the appropriate subscription plan during the subscription process depending on their requirements. The Developer Portal allows API consumers to find and consume APIs with ease. You can change the look and feel of your Developer Portal by changing the theme to match your brand. Doing so will help you give a better developer experience to your users. To customize the Developer Portal theme, follow the steps given below: Note Sign in to the Choreo Console at https://console.choreo.dev/ using a Google/ GitHub/ Microsoft account. In the left pane, click Settings. In the header, click the Organization list. This will open the organization level settings page. In the API Management tab, click Devportal Theme. Once you access the theme, you can customize the Home page, color theme, font, header and footer, logos, etc., by expanding the relevant sections. Make a change to the theme. For example, let's change the title on the Home page and the color theme. To update the title on the Home page, expand the Home Page section, and in the Title field, change the default text (for example, to To update the color theme, expand the Color Palette section, and change the colors as required (for example, change the background color to Click Preview to view a preview of the Developer Portal with the changes you made. Based on the changes given in the examples, the preview appears as follows. Click Save to save your changes as a draft theme. To apply the changes to the Developer Portal, toggle the Go Live switch. To confirm that you want to go live with the changes, click Enable in the message that appears. Sign in to the Choreo Developer Portal at https://devportal.choreo.dev. The Home page will appear as it did in the preview. To reset the Developer Portal theme to the default theme, follow the steps given below: Sign in to the Choreo Console at https://console.choreo.dev/ using a Google, GitHub, or Microsoft account. In the left pane, click Settings. In the header, click the Organization list. This will open the organization level settings page. In the Organization tab, click Devportal Theme, and then click Reset to Default. An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization. An organization in Choreo is a logical grouping of users and user resources. A first-time user must create an organization and be a user of it when signing in to Choreo. Users and resources in an organization cannot access resources in another organization unless an admin of the other organization invites them and adds them as a user of that organization. An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization. For details on how Choreo manages user permission, see Manage user permission. API policies are units of business logic that you can apply to modify the flow of API invocations. You can apply a policy to alter the Choreo supports a set of inbuilt mediation policies that can handle common API transformation and mediation tasks. These policies run within a single mediation service, making it straightforward to implement and manage complex mediation logic. The following inbuilt policies are available in Choreo: These inbuilt mediation policies provide flexibility to manage API requests and responses, allowing for custom transformations and logic without requiring custom code. You can easily attach one or more policies to an API proxy component implementation via the Choreo Console. If necessary, you can also rearrange or swap the policies you attach. In Choreo, when you attach a mediation policy to a proxy, the deployment is a two-step process. Deployment initiation: If the component to which you want to attach the mediation policy is new, the system creates and commits a new repository with the mediation service code based on the attached policy. This new service is called the mediation application. Deploying the API: Once the deployment initiation is complete, you can specify configuration values if any, and proceed to deploy. Choreo builds the generated mediation application and pushes the Docker image to the Docker registry. Finally, Choreo deploys the mediation application with the API Proxy. When a mediation policy is attached to a specific flow, the API invocation undergoes the following behavioral modification: In the request path, the requests that pass through the gateway reach the relevant component, and Choreo executes any attached policies to the resource's request path before sending it to the backend. In the response path, the mediation component receives response messages from the backend, and Choreo executes any mediation policies attached to the If an error occurs during the execution of policies or due to an internal error, Choreo executes the To attach a policy to the If the attached policy requires parameter configuration, on the policy pane enter the appropriate values and configure the parameters. To make a parameter a configurable variable, input the value in the To attach the policy, click Add. After attaching an API Policy, it is necessary to deploy the API for the policy to become active within its corresponding flow.
-To deploy the API follow the steps below: In the left navigation menu, click Deploy and then click Configure & Deploy. Choreo performs the mediation application generation step and opens the Configure & Deploy pane. In the Configure & Deploy pane, if you have any configurable variables that require values, specify appropriate values for them. Click Save & Deploy. Choreo selectively generates and builds the mediation application code during component deployment depending on specific changes. These changes include: If none of the above changes occur during deployment, Choreo skips the code generation and build process of the mediation application. Info Choreo allows you to implement an API policy as a Ballerina project and attach it to an API proxy component. Info Supported Ballerina version: 2201.5.5 To implement a policy, follow the steps given below: Alternatively, you can set the access token via the Choreo provides a template to initialize a mediation policy project with all the required configurations. The mediation policy project will be created as a Ballerina project. To create a Ballerina project for the mediation policy using Format: Example: Depending on your requirement, you can modify the Note To successfully publish to Ballerina Central, make sure you update the In this step, you will implement the policy. Let's assume you want to implement a policy to validate an incoming header in the request and the response. To implement the policy, open the The following sections walk you through sample implementations for the Request and Response stubs: The following is a sample implementation for the request flow: The following is a sample implementation for the response flow: In this guide, you are not going to make any changes to the Note The @mediation:RequestFlow, @mediation:ResponseFlow, and @mediation:FaultFlow annotations are bound with the keywords in the Choreo supports publishing a policy as a private custom policy. Publishing a policy as a private custom policy makes the policy inaccessible outside of the organization. To publish a policy as a private custom policy, change the visibility to Set the visibility to private by adding the configuration Package and publish your policy to Ballerina Central. When implementing a policy, it is essential to follow best practices to ensure efficiency and maintainability. Here are some recommended best practices to follow: Once you implement a policy, you must publish it to Ballerina Central. When you attach a policy and deploy an API, Choreo pulls the necessary packages from Ballerina Central and bundles them into the mediation application under the hood. Therefore to use policies in your APIs, you must publish them as public packages. To publish the policy, follow the steps given below: To publish the package to Ballerina Central, issue the following command: Once you publish the package, it will appear as follows in the policy list: You can write unit tests to test policy functions in a manner similar to how you write unit tests for a regular Ballerina function. The following is a sample unit test for the The policy function modifies the same request/response/context instance that you pass to it. You can check the request/response/context instance after calling the policy function to verify changes. Here are some of the common terms used when working with policies in Choreo: The mediation context is used to pass parameters between policies. It is created per request and you can access it in any of the flows. For example, if a correlation ID needs to be set to the request, you can set it in the context of the request flow and access it in the response or fault flow. The mediation context can include the following functions: The The Format: Example: When it comes to policy versioning in Choreo or mediation dependencies, it is important to consider the major version changes in the Ballerina language. For example, transitioning from update 1 to update 2 requires a major version increment, which can introduce significant incompatibilities. Therefore, to ensure compatibility, the recommended approach is to version the policy package in a manner that the major version gets upgraded when the Choreo/mediation dependency version is upgraded to a major version. API rate limiting is a technique that allows you to control the rate of requests made to an API. Rate limiting helps
-prevent system overload and enhances API performance. When you limit the number of requests that can be made in a
-specific time frame, you can ensure that your API is available and responsive to all users while protecting it from
-malicious attacks. This page walks you through the steps to enable rate limiting for your APIs via Choreo and also provides information on
-the rate-limiting options supported by Choreo. To enable rate limiting for an API, follow the steps given below: Note You can apply rate-limiting settings separately for each environment. Go to the required environment card and click the view icon corresponding to the endpoint for which you want to apply rate limiting. Info If you are applying rate limiting for an API Proxy component, go to the required environment card, click the setting icon corresponding to API Configuration, and proceed to step 6. In the Endpoint Details pane that opens, click the settings icon. API-level rate limiting applies the allocated request count for the specified time unit to all operations in the API. Operation-level rate limiting allows you to configure different rate-limiting values for each operation. You can use this option to define specific rate-limiting values for critical API operations that require an extra layer of protection. The following table lists the response headers available when you enable rate limiting for your APIs. You can implement necessary rate-limiting scenarios depending on the response header values. By default, the APIs published in Choreo are visible to anyone who visits the Choreo Developer Portal. By default, Choreo sets the visibility of the API to Visibility settings control users from viewing and modifying APIs. API visibility can be one of the following options: Public : The API is visible to all in the developer portal. Private : The API is visible to the users who only sign in to the Developer Portal. Restricted: The API is visible to only the user that has the roles that you specify. This option helps developers to enforce fine-grained access control to the API. Under General Details, select the required visibility setting from the Visibility list. Enable fine-grained role-based access control to the API Click Save. When an API consumer signs in to the Choreo Developer Portal to browse APIs, it is not sufficient to just have an API thumbnail along with the name and version of the API. An API consumer would expect to see more details about the API, such as the following: To provide such information that improves the overall visibility of the API, an API developer can add such documentation to an API before publishing it to the Developer Portal. To add documentation for an API, follow the steps given below. Sign in to the Choreo Console. In the Component Listing pane, click on the component for which you want to add documents. In the left navigation menu, click Manage and then click Documents. Specify a title for the document and provide the content in markdown syntax. Click Add to save the document. Depending on the information you need to add to the API, you can add one or more documents. You can also edit existing documents and delete documents if necessary. API lifecycle management is an important aspect of API management. The API lifecycle consists of various states that an API passes through, from creation to retirement. In Choreo, there are six distinct lifecycle states: created, pre-released, published, blocked, deprecated, and retired. By leveraging the various lifecycle states, API managers can optimize the development process and ensure that subscribers have access to the latest and most reliable APIs. The following lifecycle states are applicable to APIs in Choreo: To change the lifecycle state of an API via the Choreo Console, follow the instructions given below: Tip You must have publishing privileges to manage the lifecycle states of a component. API subscription plans allow API publishers to control and manage access to APIs. These plans define the rules and limitations on how clients can interact with APIs, ensuring efficient resource utilization and robust security. Choreo allows users with the administrator role to create, update, and delete subscription plans at the organization level. For instructions on creating subscription plans, see Create API Subscription Plans. Once created, Choreo allows API publishers to assign subscription plans to APIs, providing different levels of access based on user needs. To assign subscription plans to an API, follow the steps given below: Enable the Subscription Plan Status toggle corresponding to the subscription plans you want to assign to the API. Click Save. When an API has subscription plans assigned to it, API consumers can select the plan that best fits their requirements during the subscription process. For details, see Subscribe to an API with a Subscription Plan If an API has subscription plans assigned to it, API consumer can select the subscription plan that best fits their requirement at the time of subscribing to the API. To subscribe to an API with a subscription plan, follow the steps given below: Click Add Subscription. To verify that the subscription plan works as expected, follow the steps given below: Choreo allows you to make one or more endpoints accessible through its service and integration components. These endpoints are published as individual APIs in Choreo, accessible via the Choreo Developer Portal. By default, Choreo assigns an API name by combining the component name and the endpoint name, resulting in the following format: Choreo provides you with the flexibility to personalize the display name of the API, enhancing its user-friendliness and readability. Once you modify the API display name within the Choreo Console, Choreo applies the change immediately. From there onwards, Choreo displays the published API by this name in the Choreo Developer Portal. Follow the steps below to rename the API display name: Now, you can view the updated API display name in the Choreo Developer Portal. Mutual transport layer security (mutual TLS) is a protocol that ensures privacy, integrity, and authentication of the data transmitted between two endpoints. In mutual TLS, the client and the server authenticate each other using digital certificates, establishing trust and verifying identities. Upon successful authentication, mutual TLS encrypts the data exchanged between the client and the server, preventing unauthorized access. In Choreo, you can use mutual TLS to establish secure connections between components within a project. Note If mutual TLS is not required, you can configure TLS instead. TLS provides a secure communication channel between a client and server but does not require the client to present a certificate to the server. This results in the absence of mutual authentication between the client and the server. While TLS ensures the confidentiality of data transmitted between the client and server, preventing unauthorized tampering, mutual TLS enhances TLS by introducing client-side authentication and facilitating mutual verification of identities between the client and server. To configure TLS, you can follow the same steps as for mutual TLS as mentioned below, without having to generate a client certificate. The client only needs the root certificate to verify the server's identity. Root certificate: Trusted by both the client and the server, this certificate is used to verify the authenticity of other certificates presented during the mutual TLS handshake process and to issue certificates for clients and servers. For a specific project, you can generate a single root certificate using a tool like OpenSSL. Client certificate: Contains the client’s identity for authentication. The common name (CN) in the certificate identifies the client. The generated client certificate must be signed by the root certificate. Server certificate: Clients use the server certificate to verify the trustworthiness of the server and establish a secure and authenticated connection. Similar to the client certificates, the server certificate must also be signed by the root certificate. When generating the server certificate, you must specify the server's hostname for the subject alternative name (SAN). You can obtain the hostname for the specific version of a service component from any project endpoint on the Overview page. For example, if your project endpoint is The approach to read mutual TLS certificates from a component can vary depending on its implementation. Typically, a component can read the certificate data from the file system or via an environment variable. For detailed instructions on adding environment variables and file mounts to your application, see Manage Configurations and Secrets. Info When you specify a private key, ensure you save it as a secret. For a sample that demonstrates how you can deploy services that communicate using mutual TLS, see service-to-service-mtls. There are scenarios where a backend service needs to apply specific logic or make decisions depending on the user consuming an API. In such scenarios, you must pass end-user attributes to the backend during an API call. Choreo provides a method to send user information to a backend service through a JSON Web Token (JWT) in an HTTP header of an API request. The backend JWT contains claims transferred between the parties, such as the user and the backend. A claim can be metadata of the request or data about the user. A set of claims is called a dialect, for example, For each API request, a digitally signed JWT is carried to the backend service in the following format to ensure that the authenticity of the claims list is verified: When a request goes through Choreo, the backend JWT is appended as the Claims are fragments of information included in the JWT. The following is a sample claim set added to the end-user token for an access token generated via the authorization code: Tip This access token is generated via Asgardeo using the authorization code grant type. Here, the Asgardeo application is configured to include the email claim in the token. The following table describes the information contained in the sample JWT claims set given above: Note The claims that get added to the end-user token can vary depending on the grant type used when generating the access token. For example, if you use the client-credentials grant type to generate the access token, the generated backend JWT would contain the following information: To verify the authenticity of claims in a JWT, the claims must be validated using the public key corresponding to the private key used to sign the JWT. JSON web key set (JWKS) is a set of keys to validate a JWT. It contains a collection of JSON web keys, which are public keys used to verify the signature of a JWT. Typically, when a third party (such as an identity provider)issues a JWT and the recipient needs to verify its signature, they can use a JWKS.
-JWKS allows the issuer to rotate keys dynamically rather than hard-coding the public key in the application. The recipient can obtain the public key by accessing the JWKS endpoint. Choreo provides an endpoint to specify the public keys for backend JWT validation. Here are the endpoint URLs for the US East and EU regions: Note For private data planes (PDPs), use the following JWKS endpoint URL template: Be sure to replace The endpoint provides one or more signing keys to validate the JWT.
-The JSON web keys have a kid identifier that can be matched with the same property on the JWT to decide which key to use when validating. The following is a sample JWKS response: The following table describes the information contained in the JWKS response: To enable passing end-user attributes to the backend through API calls via Choreo, follow the steps given below: Go to the Set Up card and click Endpoint Configurations. This opens the Endpoint Configurations pane. Note If the component is an API Proxy, go to the Build Area card and click Security Settings. This opens the Security Settings pane. Select the Pass Security Context To Backend checkbox. Optionally, specify appropriate audience values in the End User Token Audiences field. Specifying values restricts the JWT to the respective audiences, enabling the backend service to validate and confirm the intended recipients, including itself. Note The backend JWT does not include the audience field (aud) by default. Click Apply. API security refers to the measures and practices used to protect Application Programming Interfaces (APIs) from potential threats and vulnerabilities. APIs are essential for enabling communication and data exchange between different software applications and services, making them a critical component in modern software development. However, their openness and accessibility can also make them targets for various security risks. Authentication and authorization are key aspects of API security. Authentication is ensuring that only authorized users or applications can access the API. This can involve using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization is controlling what authenticated users or applications are allowed to do within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions. Organizations using Asgardeo for identity and access management (IAM) can seamlessly integrate it with Choreo as an external Identity Provider (IdP). This guide will walk you through setting up Choreo to authenticate API invocations through Asgardeo which is configured as an external IdP. This guide walks you through the following steps: To follow this guide, you need to satisfy the following prerequisites: You can provide fine-grained access control to your API resources with scopes. Follow the steps below to assign a scope to the resources in the API: Follow the Asgardeo API Authorization guide to create an application and an API in Asgardeo and to enable API authorization. Note Follow the steps below to consume the Choreo API and use an external IdP for authentication: Click +Add. Note In the left navigation menu, click Subscriptions. Obtain an access token by invoking the token endpoint as follows: Note Once you receive the access token, you can test invoking the resource using the OpenAPI console in Choreo by specifying the scope. API security refers to the measures and practices used to protect Application Programming Interfaces (APIs) from potential threats and vulnerabilities. Authentication and authorization are key aspects of API security. Authentication is ensuring that only authorized users or applications can access the API. This can involve using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization is controlling what authenticated users or applications are allowed to do within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions. Organizations using Microsoft Azure AD for identity and access management (IAM) can seamlessly integrate it with Choreo as an external Identity Provider (IdP). This guide will walk you through setting up Choreo to authenticate API invocations through Azure AD which is configured as an external IdP. This guide walks you through the following steps: To follow this guide, you need to satisfy the following prerequisites: You can provide fine-grained access control to your API resources with scopes. Follow the steps below to assign a scope to the resources in the API: To enable external IdP authentication for APIs, create an API on Azure AD that represents the API on Choreo. Follow the steps below: For more information, refer to the Azure documentation: You can restrict users to the API as follows: For more information, refer to the Azure documentation: Assign the app to users and groups to restrict access To expose the API to application developers, create an application in Azure AD. This application provides you with a client-id and client-secret that your application needs to use to invoke the API. Follow the steps below to create the application: Configure the platform settings. Enter your client application's redirect URI in the process. Note OAuth2 Authorization Grant flow applies to Web Applications. Once you create the application, select the API and the scopes you want the application to consume. Follow the steps below: For more information, refer to the Azure documentation: Add permissions to access your web API To invoke the application, provide client secrets to the consuming application. Follow the steps below to generate the credentials: For more information, refer to the Azure documentation: Add a Client Secret Follow the steps below to consume the Choreo API and use an external IdP for authentication: Click +Add. Note In the left navigation menu, click Subscriptions. You can now invoke the Choreo API using the authorization code grant. Choreo will authenticate the user with Azure AD and provide access to the resource. Invoke the authorization endpoint as follows: Once you receive the access token, you can test invoking the resource using the OpenAPI console in Choreo by specifying the scope. To establish secure communication between the Choreo Gateway and your backend, you can configure mutual TLS. Mutual TLS authentication involves both the client and server validating each other’s certificates before establishing a connection. The following diagram depicts this scenario: To establish secure connectivity between the Choreo Gateway and your backend using mutual TLS, you must add the certificate of the backend (server certificate) to Choreo and add the certificate of Choreo (client certificate) as a trusted certificate in the backend. To configure the backend certificate, follow the steps given below: There are two approaches you can take to configure mutual TLS. Follow the step-by-step instructions below depending on how you want to establish mutual TLS with the backend service: When you follow these steps, Choreo generates a key pair with a self-signed certificate. You can attach this key pair to any API proxy created within the same project. In the Add Client Certificate Pair dialog, select Generate new key pair and specify a value as the common name for the certificate pair. This value will be used to identify the certificate. Optionally, click Show advanced options to expand the section and specify appropriate values for each of the fields. Click the more options icon corresponding to the certificate and then click View and Download. This opens the certificate for you to view and download. To download the certificate in PEM format, click Download. You can add this certificate as a trusted certificate in the API backend server. Now you can associate the certificate with the API and deploy the API. Here, you can use your own public certificate and private certificate as client certificates. In the Add Client Certificate Pair dialog, select Use my own key pair. Upload the private key and public certificate in PEM format or copy and paste the content of the private key and public certificate. Click the more options icon corresponding to the certificate and then click View and Download. This opens the certificate for you to view and download. To download the certificate in PEM format, click Download. You can add this certificate as a trusted certificate in the API backend server. Now you can associate the certificate with the API and deploy the API. To associate a certificate with the API, follow the steps given below: Select the certificate you want to associate with the API. Click Save. To deploy the API, follow the steps given below: Once the deployment is complete, you can test the API. If the API backend changes depending on the environment, the respective certificate must be updated for each environment. Here, let's take a look at the steps to update the certificate for the production environment: The managed authentication capability of Choreo simplifies adding authentication and authorization to a single-page web application. As a developer, you can easily set up Choreo's managed authentication to seamlessly integrate authentication into your web application. You just need to enable Choreo’s managed authentication, configure the built-in identity provider, and connect to Choreo without having to deal with the complexities of underlying OIDC/OAuth2.0 protocols. Choreo's managed authentication follows the backend for frontend (BFF) architecture, which is a secure pattern recommended for browser-based applications that utilize OIDC/OAuth2.0 for authentication and authorization. This architecture ensures that OAuth tokens remain secure from browser-side code, making them immune to potential attacks like cross-site scripting (XSS). Note Choreo's managed authentication is currently available only for web applications created with React, Angular, or Vue.js buildpacks. Warning Managed authentication uses the 'SAMESITE' cookie attribute to prevent CSRF attacks. Therefore, it is recommended to use managed authentication with modern browsers that support the 'SAMESITE' attribute. To secure your web application, you must implement authentication and authorization for it. To easily set up authentication for your web application with Choreo's managed authentication, follow the steps given below. Before you move on to the next section, see Develop Web Applications Locally with Choreo’s Managed Authentication to ensure a seamless authentication experience when developing your web application on your local machine. You can also refer to the sample React app with managed authentication. To allow Choreo to manage the sign-in functionality for your web application, you must implement a sign-in button that redirects users to the This code snippet works as follows: When a user clicks sign in on your web application, Choreo will redirect the user to the configured identity provider and handle the authentication process, conforming to the OICD/OAuth2.0 protocols. On successful sign-in, Choreo will set the relevant session cookies and redirect the user to the post-sign-in path (default is Note Refer to configure the identity provider section for details on configuring an identity provider for the web application. If you want to pass additional query parameters to the identity provider, include them in the For example, Choreo's managed authentication allows you to access user information claims that the identity provider returns post-sign-in, either via a cookie or by invoking a GET resource. Upon successful sign-in, Choreo's managed authentication establishes a Note The recommended approach is to retrieve user information from the cookie and subsequently clear the cookie. The following is a sample code snippet that you can include in your post-sign-in path to retrieve user information from the cookie and subsequently clear the cookie: Choreo's managed authentication provides the GET endpoint The following is an example of a request to this endpoint: If a user has signed in, the server sends a To allow Choreo to manage the sign-out functionality of your web application, you can implement a sign-out button to redirect users to the Note When a user clicks the sign-out button, Choreo will clear the session cookies and redirect the users to the OIDC logout endpoint of the configured identity provider (if available). To invoke Choreo APIs within the same organization as your web application, you can use the relative path Note To invoke a Choreo API from a web application, you need to create a Connection from the web application to the Choreo API. For example, if the API URL is Info To copy the exact service URL of a Connection, you can follow the steps given below:
- 1. In the Choreo Console, go to the appropriate web application component.
- 2. In the left navigation menu, click Connections under Dependencies.
- 3. Click on the required Connection and copy the service URL. If you enable Choreo's managed authentication, you don't have to manually add any logic to attach an access token to the API call because Choreo APIs accept the cookies set by Choreo's managed authentication. You can directly invoke the API as follows: If Choreo's managed authentication is disabled, you must ensure that your web application attaches a valid access token to the API call. When a user session exceeds the configured session expiry time, it automatically expires. A To programmatically handle session expiry and automatically re-login upon receiving a You can set up Choreo's managed authentication to redirect to a customized error page within your web application by defining the error path in the configuration. In the event of an error during a redirection-based process, such as sign in or sign out, Choreo will automatically redirect the user to the designated custom error page. Note If you have not configured an error path, Choreo's managed authentication will use its default error page whenever an error occurs. Choreo's managed authentication will include the following query parameters in the URL when redirecting to the custom error page: Now have successfully implemented Choreo's managed authentication for your web application. The next step is to enable managed authentication for the component, and subsequently deploy it. To ensure that your web application functions seamlessly with managed authentication, it is essential to enable managed authentication for your web application component within Choreo. You can enable managed authentication for your web application component at the time you deploy the component. Tip Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks. Specify appropriate values for the following fields: Note If you need to change these configurations after you deploy the component, you can click Authentication Settings on the Set Up card, make the necessary changes, and deploy the component once again. You can configure your web application to work with the Choreo built-in identity provider, Asgardeo, or any external identity provider which supports OIDC/OAuth2.0 . Note The identity provider configured in this step should contain the users for the web application. Click the respective tab for details depending on which identity provider you need to configure: Follow the steps given below to configure the built-in identity provider by generating authentication keys: Note Choreo built-in identity provider is configured by default. Therefore, this step is optional. Click Generate Secret. Note If the Regenerate Secret button is shown instead of the Generate Secret button, it indicates that OAuth keys are already generated for the component for the selected environment. Tip Refer to Configure a User Store with the Built-In Identity Provider for details on adding test users in Choreo built-in identity provider. Tip If you need to invoke APIs secured with role-based access control, you can test this within Choreo by creating roles for the application and mapping those roles to relevant permissions (scope) and user groups. For more information, see create roles and assign permissions and assign roles to user groups sections in Test Secure API Access with Choreo Built-In Security Token Service. Step 3.1: Create and configure an OIDC/OAuth2.0 application in Asgardeo Click the Protocol tab and follow these steps: Click Update. Tip If you need to invoke APIs secured with role-based access control, you must create roles in the application and map those roles to relevant permissions (scope). Then those roles should be assigned to user groups. For more information, see the Asgardeo API authorization guide. Copy the Client ID and Client Secret of the application. You will need to use these values in the next step to link the OIDC/OAuth2.0 application to your Choreo component. Step 3.2: Link the OIDC/OAuth2.0 application to the Choreo web application component Step 3.1: Create and configure an OIDC/OAuth2.0 application in the external identity provider Configure the OIDC/OAuth2.0 application as follows: Specify the access token type as JWT. Tip If you want to invoke APIs secured with role-based access control, you must ensure that users are assigned a role mapping that grants the necessary permission for API invocation. The approach of mapping application roles to users can vary depending on the identity provider. Step 3.2: Link the OIDC/OAuth2.0 application to the Choreo component API security can protect APIs from potential threats and vulnerabilities, with authentication and authorization playing key roles. Authentication ensures that only authorized users or applications can access the API. This involves using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization governs the actions permitted for authenticated users or applications within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions. Choreo simplifies security testing for developers, allowing them to easily test APIs with permissions in non-critical environments. With its integrated security token service, Choreo provides authorization features that generate scopes based on the correlation between scopes, roles, and user groups. Developers can create roles, assign permissions, and set up user-group mappings using Choreo's built-in identity provider (IdP). This guide walks you through the following steps to test the invocation of secured APIs with permissions using Choreo's built-in authorization capability: Before you try out this guide, ensure you have set up the following: You can provide fine-grained access control to your API resources with permissions. Follow the steps below to assign permissions to the resources in the API: To apply the latest permissions to the deployed component, you must redeploy it. Follow the steps below to redeploy: To publish your API to the Choreo Developer Portal, follow the steps given below: The permissions assigned to your API need to be associated with roles. Follow the steps below to create roles and assign permissions to the roles. Select the permissions you want to assign to the role, and then click Create. Tip The permissions(scopes) defined for APIs exposed via components in the project and the permissions(scopes) required by connections created for components in the project are listed here. You must assign roles to the user groups defined in your Choreo built-in IdP to ensure that authenticated users can obtain access tokens with the required permissions. Click the Application Security tab and then click Role Management. Tip The roles defined within different projects in the organization are listed here. Click Map Groups corresponding to a role that you want to assign to a group. To test an API invocation, you must first create a connection to your API. To do this, you must have a web application created. You can use the web application you created while setting up the prerequisites. To create a connection to the web application, follow the steps given below: Now you can proceed to deploy the web application. When deploying, if your web application is a single-page application (SPA), you have the option to allow Choreo to handle authentication on behalf of the application. This approach eliminates the need to incorporate OAuth protocol-specific logic into your application. If managed authentication is enabled for your web application, Choreo automatically handles obtaining the necessary permission for API invocation. This occurs during the request for access tokens, allowing you to seamlessly invoke the subscribed APIs through your web application without additional intervention. Note If you change the permissions of an existing connection or create a new connection with permissions, you must redeploy your web application to ensure proper API invocation with managed authentication. If your application manages authentication independently, follow the steps below to generate the necessary OAuth credentials to obtain access tokens: The Choreo Command Line Interface (CLI) is a command-line tool that helps you easily work with Choreo using commands. By utilizing commands, it significantly improves the development experience for Choreo users. This versatile tool simplifies different stages of the development process, making interactions more efficient and user-friendly. Choreo serves as a comprehensive internal platform-as-a-service. The Choreo CLI serves as a pivotal tool aimed at enhancing its capabilities. With the Choreo CLI, you can leverage the following benefits: Streamline Deployment Processes: Choreo CLI simplifies the entire process from creating a component in Choreo, building it, to deploying, testing, and monitoring independent of the language and framework used to implement the component. Versatile workflow across frameworks: Regardless of your chosen framework, Choreo CLI offers a uniform end-to-end process. Choreo seamlessly integrates with different web application types (SPA, SSR, SSG, or simple static files), services (REST, GraphQL, gRPC), scheduled jobs, manual triggers, API proxies, and more. This versatility enables you to orchestrate a wide range of cloud-native components seamlessly. Create and Manage Resources: Simplify project and component management. You can easily initiate and organize projects in Choreo through simple commands. Create Builds and Deployments: Simplifies the process of creating builds and deploying components. You can build and promote components to environments easily with simple commands, ensuring a seamless transition from development to deployment. Note The Choreo CLI currently supports the following component types: Monitor with Logs : The integrated log functionality in the Choreo CLI allows you to effectively monitor your components. You can access valuable insights into your components behavior and performance directly from the command line. For troubleshooting tips and answers to frequently asked questions, see the Choreo CLI FAQ. This guide walks you through the following sample use case: This guide utilized a simple to-do app built with Next.js and two basic environments: Development and Production. Follow the steps below to install the CLI: Install the Choreo CLI by running the command specific to your operating system: For Linux and Mac OS
- For Windows (via PowerShell)
- Verify the installation by running the following command: Run the following command to login to Choreo: Follow the instructions on the console to open the link in the browser and login to Choreo. A project in Choreo is a logical group of related components that typically represent a single cloud-native application. A project consists of one or more components. Create a multi-repository project named ‘web-app-project’ by running the following command: In Choreo, a component within your project represents a singular unit of work in a cloud-native application. It can be a microservice, API, web application, or job/task. Each component is associated with a directory path in a Git repository containing the source code for the program. Note The Choreo CLI currently supports the following component types: Fork the repository https://github.com/wso2/choreo-sample-todo-list-app. This contains a sample web application that you can use for this guide. To initiate the creation of a Web Application component within your project, use the following command:
-This triggers a wizard prompting you to provide details for your Git repository and other configurations for your component. Select the option Enter the following values for the prompts. Note The prompts may vary based on the type of component and the chosen build pack. To view comprehensive information about the component, including basic details and service endpoint URLs once the services are deployed, you can use the following command: You must build the components before deploying them to a specific environment. Execute the following command to trigger the build: To check the status of a specific build, run the following command, replacing Note Typically, a build takes approximately 2 to 5 minutes to complete. Once the build is complete, you can view the build logs for verification or debugging purposes. In the unlikely case, the build encounters any issues, the logs will help you troubleshoot. Once the build status indicates After deploying the component, you can retrieve the URL of the deployed web application and open the publicly available web page to verify its behavior. Use the following command to retrieve the URL: To observe runtime application logs of the web application in the Development environment, execute the following command: Once you verify your application in the Development environment, you can proceed to deploy it to the Production environment with the following command: To ensure a successful deployment to the Production environment, retrieve the URL of the deployed web application using the following command: Congratulations! You successfully deployed your web application in Choreo using the Choreo CLI. Discover other functionalities of Choreo by running the following command. The Choreo Marketplace promotes and facilitates reusing and sharing services. It allows you to share all the services deployed in Choreo.
-You can easily browse and search available services within the Marketplace and refer to the service definitions, documentation, instructions on how you can use it, etc. The Marketplace includes all services deployed in your organization. This may be a large number of services. Therefore, effective discoverability is desirable. You can use the search or apply various filter criteria to explore the services available. The top search bar provides universal searching to find the services. It allows you to search for a text in the following search attributes: The Choreo Marketplace provides a filtering capability through the left-hand side filter panel. It allows you to filter with the following filter attributes: Type: This filter enables you to categorize services based on their type, with two available options: "Internal" and "Third-party". "Internal" refers to services deployed within Choreo, while "Third-party" refers to services running externally to Choreo, independently added to the Marketplace. Network Visibility: This filter enables you to categorize services based on their network visibility level, with three choices: "Public," "Organization," and "Project". "Public" filters services exposed publicly, "Organization" represents services exposed across the entire organization, and "Project" represents services exposed at the project level. You can click on the service card to open the detailed view of the service. The detailed service page features the service name, summary, version, labels, and service icon as the header. Choreo organizes the service content into four tabs. The four tabs contain information as follows: Overview: Choreo displays the service overview provided by the service developer. If the service developer has not provided any content at service creation, this section will be disabled. The service developer can provide the overview content via the Manage → Marketplace section of the component. API definition: Includes the service's API definition, extracted from the user repository using the How to use: Includes instructions on how to use the selected service. This includes instructions on creating a connection. Related documents: Includes any additional content the user has provided as documents through the Manage -> Marketplace section of the component. You can add services to the Marketplace as Choreo services as follows: In Choreo, a service exposed through the platform is termed a Choreo service, with each service being identifiable by an endpoint within a Choreo service component. The Marketplace showcases a service for each endpoint within a service component. Upon deployment to the initial environment, services get automatically added to the Marketplace. Choreo effortlessly collects essential details such as component name, endpoint name, description, and service definitions during this deployment, utilizing them to generate the corresponding service entries in the Marketplace. The service name follows the convention of In the Choreo Marketplace, service versions are displayed in their major version format. Each service in the Choreo Marketplace represents the latest version of the service within its major version, following semantic versioning principles. For example, if a Choreo service has versions When you deploy a new minor version of a service already deployed in Choreo, the corresponding service in the marketplace automatically updates to reflect the latest version within the same major version. When you use a service from the Choreo marketplace as a dependency, the dependent service's traffic automatically routes to the latest version of the corresponding service within the same major version. This ensures that your dependencies remain up-to-date without requiring manual updates within a major version. For example, if you create a connection to connect your Choreo component named You can edit services in the Choreo Marketplace. During redeployment to any environment, Choreo automatically updates service definitions, visibility, and descriptions. Choreo provides a streamlined continuous integration and continuous deployment(CI/CD) experience to deploy applications and services efficiently across multiple environments. Choreo creates environments for each project, where all components within the project share the environments. An environment is an isolated deployment area with restricted network and resource access. Services deployed in one environment cannot communicate with services deployed in another. The Choreo cloud data plane provides two default environments (i.e., development and production). However, if you are in a private data plane organization, you can customize and create multiple environments based on your requirements. Choreo adopts a build once, deploy many strategy to manage components across multiple environments. An application is built only once (i.e., per commit if automatic build on commit is enabled or based on the selected commit during a manual build). Then it is promoted to subsequent environments. This allows testing changes in lower, non-production environments like development before promoting the build to production. Choreo injects configurations and secrets that you maintain at the environment level into components at runtime. This ensures a strict separation of environment-specific configurations from source code. Although configurations can vary across environments, the code and the built container remain unchanged. Configurations and secrets include: All configurations and secrets are encrypted at rest and in transit and stored in a secure vault. In a private data plane organization, you can store configurations and secrets in your infrastructure. Choreo auto-generates build pipelines that may slightly differ depending on the component type you create. Generally, all build pipelines work as follows: Choreo can replicate builds from an identical code version (Git commit). This means that multiple builds initiated from the same Git commit will generate Docker images with the same behavior. Note In the event of multiple builds from the same code version, Choreo preserves only the most recent version of the Docker image created from the particular code version. On the Build page, click Build Latest. If necessary you have the option to select a particular commit and build an image. If you want to automatically trigger a build with each commit, you can enable Auto Build on Commit. You can view build logs for specific builds on the Build page. To view details of a specific build, click View Details corresponding to the build. Once you build an image in Choreo, you can deploy it via the Deploy page. To deploy an image, you can follow one of the approaches given below: Manually deploy: In the Deploy page, go to the Set Up card and click Deploy. Automatically deploy on build: In the Deploy page, go to Set Up card and enable Auto Deploy on Build. This automatically initiates deployment upon the completion of an automatic build. Info To enable Auto Deploy on Build, you must enable Auto Build on Commit. This is because automatic deployment is not necessary or useful in scenarios where automatic build is not enabled. Note In the deploy phase, Choreo uses a setup area to merge the Docker image with its environment-independent configurations. Choreo then deploys this composite to the environment. This is known as the initial deployment. Once Choreo deploys a component with configurations, the configurations become immutable. Any subsequent change results in a new deployment. Choreo builds a container once per GitHub commit and then promotes it to subsequent higher environments. You can go to the Deploy page of a component and promote it manually across environments. Choreo allows you to define both environment-independent configurations and environment-specific configurations. These configurations apply to all environments. To change environment-independent configurations, go to the Deploy page of the component, make the necessary configuration changes via the Set Up card, and then trigger a new deployment to the initial environment. From there, you can proceed to promote the component to higher environments. These configurations apply to a particular environment. To change environment-specific configurations, go to the Deploy page of the component, make the necessary configuration changes via the specific environment card, and trigger a new deployment. To learn more about managing these configurations, see Configuration Management. The information on the Execute page is only applicable to scheduled and manual task components. To track and monitor executions associated with a deployed scheduled task or manual task, go to the left navigation menu and click Execute. You can view current and historic execution details along with a quick snapshot of recent activity via the total count of executions within the last 30 days. For each execution, you can view vital details such as the unique execution ID, the time it was triggered, and relevant revision information. Furthermore, you can dive deeper into the details by clicking on a specific execution to access its associated logs. This information enhances transparency, troubleshooting capabilities, and overall execution management, allowing you to easily monitor and analyze workflows. Choreo performs rolling updates to ensure zero downtime between deployments and promotions. A new build undergoes a health check before traffic is switched to it from the current build. If you configure the necessary health checks for a component, it can prevent deploying and promoting unhealthy versions of a component. A component within a project represents a single unit of work in a cloud native application. A component is usually a single microservice, API, or job/task. Each component in Choreo is attached to a given directory path in a Git repository which either contains program source code or a Dockerfile with build instructions. A component is Choreo’s unit of deployment. Each component maps to a single pod in the Kubernetes cluster (data plane) at deployment time. Therefore, you can deploy, manage, and scale each component in Choreo independently. Choreo supports different component types for various use cases. These include component types such as services, API proxies, integrations, web applications, and so on. Each component type hosts unique features based on its characteristics. For example, a scheduled integration component can accept a cron expression as a configuration to schedule an integration job/task. Services can exist in two main forms: standalone and integrated. Connecting services is an integral part in creating integrated solutions. Choreo allows you to connect services using Connections. Using Connections, you can integrate the service you intend to deploy on Choreo with other services on Choreo or external resources. Upon creating a connection to a service on Choreo, Choreo provides you a Connection ID along with a set of connection parameters. Thereafter, you have the capability to configure your service to establish a connection using this Connection ID and map connection parameters to environment variable names in your Choreo component. You can read these environment variable names in your service implementation to retrieve the values, to create a programmatic connection to the service you want to consume. At runtime, Choreo dynamically injects values into the environment variables based on the configured mapping. This approach ensures that the connection parameter values and the service connection creation remain loosely coupled, providing developers with flexibility and ease of maintenance. You can add Connections in different visibility levels: Project and Component. The visibility levels are described below: Project Connections are Connections you create to connect to services within a particular project. The Connections can be used by any component within the project. For example, if you want to share a third-party service like Twilio across the project for all the components within that project to reuse, you can create a project connection. Components can refer to Project Connections using the connection ID.
-Project connections created to consume Choreo services under the OAuth security scheme will share the same OAuth application across the project. Any component reusing such a connection will use the same client ID and client secret. Component Connections are Connections you define at the component level and used by only that component. For example, create a component connection if you want to connect a legacy service to a given component. Components can refer to the Component Connection using the connection ID.
-If your component consumes more than one Choreo service, the Component connections created to consume those Choreo services under the OAuth security scheme can share the same OAuth application by sharing the same client ID and secret between all such connections. Learn how you can share and reuse services using connections in Choreo. Choreo's architecture comprises two key components: the control plane and the data plane. The control plane handles essential tasks such as administering organizations, users, and projects. In addition, it also governs the entire journey of application development, from the initial stages of creation, progressing to deployment, including measures to enforce governance and the provision for observability. The Choreo control plane is a SaaS that manages all cloud data planes and private data planes. It caters to diverse user personas, including CIOs, architects, and developers, as well as DevOps, site reliability engineers, and platform engineers. The data plane is the environment where user applications are deployed based on configurations set in the control plane. These applications can range from services and web applications to APIs, integrations, and scheduled tasks. The applications can be written in various programming languages, allowing for a polyglot approach. Importantly, all traffic related to the runtime of user applications is restricted to the Choreo data plane, ensuring strict containment of user data within its boundaries. Choreo's architecture features two distinct data plane types: cloud data planes and private data planes. A cloud data plane utilizes a multi-tenanted infrastructure model for deploying user applications, creating a shared yet secure environment for application runtime. In contrast, a private data plane(PDP) provides dedicated infrastructure for a single organization to run its user applications. This ensures an added layer of privacy and control for organizations with specific requirements. Choreo private data planes can be deployed with almost all major cloud providers, such as Azure, AWS, and GCP, and are also compatible with on-premises infrastructure. The essential requirements for a private data plane include upstream-compatible Kubernetes clusters, a container registry, a key vault (secret store), and a logging service or log storage. Setting up the Choreo PDP system involves using a Helm installation on the Kubernetes infrastructure.
-The following software components are installed during the helm execution: All of these software components receive automatic updates, including security patches and bug fixes through the flux controller connected to the Choreo Update Management System. The private data plane requires communication with the Choreo control plane to manage various activities. All these communications are outbound from the private data plane, ensuring that there is no need to open any specific The following table outlines the inbound and outbound connections from a private data plane: All communication between the control plane and the private data plane is secured using TLS. The following diagram depicts the architecture overview of Choreo's in-data-plane log and observability in Azure PDP: The private data plane observability architecture is centered around a strong commitment to data privacy and compliance. This is achieved through a strategic decision to retain logs and observability data within the data planes itself. Key aspects of this architecture include: The Choreo private data plane ensures extensive, production-grade security, ranging from infrastructure and architecture to zero-trust network security. All incoming traffic is protected by a firewall and must undergo authentication and authorization via the API Gateway. It also provides end-to-end network traffic encryption using Cilium transparent encryption, ensuring efficient data path encryption. For details on the private data plane security levels supported in Choreo pricing plans, see Private Data Plane Security Levels. Choreo supports the following management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios: To explore each management model in detail so that you can make informed decisions depending on the supported cloud-based operations and security, see Private Data Plane Management Models. Deployment Tracks in Choreo are structured pathways for simplified software component deployment. They act like advanced CI/CD pipelines, ensuring your components reach their destinations seamlessly, whether from source code or prebuilt images. They establish an organized and structured approach that minimizes the chances of errors and challenges that are typically associated with deployment workflows. Deployment Tracks offer practical solutions to enhance the API consumer experience by addressing two critical challenges: Streamlined deployment: Deployment Tracks serve as well-designed routes for your software components, enhancing the organization and reliability of the deployment process, similar to a well-structured express route. Efficient API versioning: Especially beneficial for managed APIs, Deployment Tracks provide a straightforward method for creating API versions that seamlessly interact with previous iterations. This simplified version management benefits both API creators and consumers alike. For streamlined deployments, Choreo dissects two integral approaches that leverage Deployment Tracks: the comprehensive CI/CD integration and the focused CD-Only strategy. A deployment track is linked to a particular branch within a GitHub repository. This connection is useful for handling deployments to various environments. On Choreo's Deploy page, you can easily visualize the deployments to specific environments associated with your selected deployment track. Moreover, the deployment track has a functionality that initiates automatic deployments for the linked branch. When activated, merging a pull request (PR) triggers a deployment to the development environment. If you're inclined to use your own Continuous Integration (CI) systems and want to harness the deployment track as a Continuous Deployment (CD) pipeline, you can seamlessly link deployment tracks to a container registry repository. This configuration empowers users to effortlessly deploy images sourced directly from the linked container registry repository. This section applies to only service components. When working with service components in Choreo, it is important to have an effective API versioning mechanism. Choreo follows a versioning mechanism based on Semantic Versioning (SemVer) but only includes the major version and minor version with the prefix For example, You can follow the approach given below when you version APIs in Choreo: What is Semantic Versioning? Semantic Versioning (SemVer) is a specification that defines how to assign and increment version numbers for software products, including APIs. For more information, see Semantic Versioning specification. One of the primary concerns when dealing with SaaS APIs is to minimize disruption for API consumers while continuously developing and deploying updates. In compliance with SemVer, changes that don't introduce breaking or additive modifications to the API are categorized as patch updates. Hover, from the perspective of API consumers, these changes should ideally not disrupt their API clients. Typically, API consumers are most concerned with major API version alterations, but there might be instances where minor version changes are communicated to them. Therefore, in the context of deployment tracks, API developers only need to specify the major and minor versions being delivered from a particular deployment track. This information is treated as the API version attribute of a deployment track. If the publisher requires versioning for internal tracking purposes, this can be accomplished in Git through the use of Git tags, on GitHub with GitHub releases, and so forth. An Endpoint is a network-exposed function that resides within a component. In Choreo, service and integration components expose one or more endpoints. Each endpoint in a component can have a service contract (OpenAPI, GraphQL SDL) associated with it. This contract is used to expose the endpoint to consumers. In the absence of a contract, Choreo uses /* exposed on all HTTP verbs as the default contract to expose the service or the integration. Each endpoint exposed in a component is considered a single API. Therefore, Choreo allows you to do API management per endpoint for a given component. For example, you can perform lifecycle management and configure security settings per endpoint in a given component. See Configure Endpoints to learn how to configure endpoints when developing components in Choreo. Choreo offers developers one or more environments to run their applications within a given data plane. By default, the Choreo cloud data plane provides two environments (i.e., development and production). Each project in Choreo is associated with one or more environments available in the organization. For example, project A may choose to utilize dev, staging, and production environments, while project B may only use development and production environments. You can promote components within a project across available environments. When you promote a component, its configuration values can be overridden with environment-specific values. The following diagram illustrates how a component is promoted across environments. An organization in Choreo is a logical grouping of users and user resources. A first-time user must create an organization and be a member of it when signing in to Choreo. Users and resources in an organization cannot access resources in another organization unless an admin of the other organization invites them and adds them as a member of that organization. A user cannot create more than one organization. If you are a member of more than one organization, you can switch from one organization to another when necessary. To do this, select the required organization from the Organization list in the Choreo Console header. An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization. Choreo manages user permissions with groups and roles. A group in Choreo is a collection of users, each with one or more roles assigned to them. Users within a group inherit the permissions associated with the roles assigned to that group. For instance, if a user is added to the Choreo comes with predefined groups already configured with specific roles, as follows: When creating a new group to invite members, be sure to assign a role to the group to ensure users have the required permissions. Choreo roles are defined as follows: The Organization ID serves as a unique identifier for each organization. To get the organization ID, follow the steps below: The organization handle is a unique string that directly corresponds to your organization's name. To get the organization handle, follow the steps below: A project in Choreo is a logical group of related components that typically represent a single cloud native application. A project consists of one or more components. All components within a project can ideally be (but is not restricted to) in a single GitHub repository under different paths. This is also known as the monorepo architecture. At deployment time, all components within a given project are deployed into a single namespace of the Kubernetes cluster. Components within a project can be exposed to the public internet, internally to the rest of the organization, or privately within the project only. A project in Choreo is represented as a cell with regard to the Cell-based architecture. The following diagram illustrates a project and how the components within a project are laid out at runtime: The following diagram depicts the high-level resources and their relationships in Choreo. Data planes are connected to the organization and are available for all the projects in the organization. When you create an environment in a project, the data plane connected to the organization is linked with an automatically generated Kubernetes namespace. Choreo allows multiple Kubernetes clusters to be associated with an environment. This allows you to build highly resilient and resource-efficient solutions that utilize multiple clusters. Choreo synchronizes your applications and workloads between associated clusters in an environment. This allows you to perform multi-cluster deployment with a single click. The following diagram depicts how multiple clusters associate with different environments: Note It is not necessary to use a different cluster per environment. You can create multiple environments on the same cluster. The above diagram is only an example of a specific solution. Your application architecture may require an entirely different configuration than what is depicted in the diagram. Components belong to a project in Choreo and environments are provisioned per project as well. When a component is deployed, it is deployed as a container to the specified environment. Once deployed, you can promote the container image across the environments available in the project. Choreo is a platform that allows you to create, deploy, and consume services seamlessly. The Choreo Developer Portal simplifies discovering and using APIs for API consumers. Typically, an application developer who may be internal or external to your organization would want to consume the APIs published in the Developer Portal to develop their applications. In this guide, you will learn how to discover, generate credentials, and test the consumption of a service published in the Choreo Developer Portal. You will also learn how to invoke the service via a web application. This guide walks you through the following steps: Before you try out this guide, if you do not have a published service that you would want to consume via the Developer Portal, follow Develop a Service documentation to publish and deploy a sample REST API. In the Choreo Developer Portal, developers can use the search option to find APIs by name. The APIs and services that are created and published through the Choreo Console become visible in the Developer Portal depending on the API's visibility as follows: Public: The API is visible to all in the developer portal. Private: The API is visible to the users who only sign in to the Developer Portal. Restricted: The API is visible to only the user that has the roles that you specify. This option helps developers to enforce fine-grained access control to the API. To learn more about API visibility, see Control API Visibility. The Choreo Developer Portal lists APIs based on their major version. The overview page of an API displays the subscribed versions of the API along with the respective subscription details such as the subscribed application and the application creation date. Tip If you want to use an API, the recommended approach is to use the latest version of it. You can copy the major version pattern provided as the value of Endpoints(s) on the API overview page and use it in your client application. This ensures that your application always invokes the latest API version. An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application. This section walks you through the steps to create an application in Choreo. Let's get started! To create an application in the Choreo Developer Portal, follow the steps given below: This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API. Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API. Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application. The following section walks you through the steps to generate an API access token in Choreo. You can generate keys and tokens to invoke production and non-production endpoints separately. Note The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints. Click to expand Advanced Configurations and review the options. Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials. You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint. To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token. Warning Make sure you do not use the test token in your production environment. You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API’s major version. The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage. To subscribe to an API via an application, follow the steps given below: Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs. Tip When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version. Once you subscribe to an API, you can invoke the API using the application keys. You can invoke the API/service using the credentials you created above. Since Choreo services are secured, you need to invoke the services securely with the help of your IdP. To invoke the API/service you created securely, you need to follow the steps below: In this guide, you will be using the following products and examples: Info You can use your own web application implementation in place of the sample web application. For this exercise, let's use the choreo-samples/reading-list-app/reading-list-front-end as the web application. To host the front-end application in Choreo, you must create a web application component. To create a web application component, follow the steps given below. Enter a unique name and a description for the web application. You can enter the name and description given below: Click Next. In the Connect Repository pane, enter the following information: Click Create. This initializes the service with the implementation from your GitHub repository and takes you to the Overview page of the component. Let's consume the service through the web app. Choreo services are by default secured. To consume a service in Choreo you need an access token. Let's configure the web application to connect to an IdP (For this guide, let's use Asgardeo) to generate an access token for a user. To invoke the service/API in Choreo you require a token. To obtain a token you need to create an OAuth application in the IdP. If you use any other IdP other than Asgardeo, create an OAuth application and set the following: Choreo uses Asgardeo as the default identity provider for Choreo applications. When you create an application in the Choreo Developer Portal, it automatically creates a corresponding application in Asgardeo. You can go to the Asgardeo application to specify the configurations required for end users to sign in to the front-end application. Follow the steps below to configure the Asgardeo OAuth application: Click the Protocol tab and apply the following changes: In this step, you are adding the configurations needed for the web app to successfully invoke the Reading List Service REST API. These configurations need to be updated for each environment you deploy the web app. Here you will be updating the configurations for the development environment. Note The web application is reading the environment-specific configurations from the To configure the front-end application, follow the steps given below: Select the mount configuration options as follows and click Next: Specify values as follows for the mount configuration: Copy the config details as a JSON file as shown below into the text area. Fill the placeholders with the values you copied from the previous steps as mentioned in the table below: Click Create. Now you can proceed to deploy the web application. To deploy the web application component, follow the steps below: That's it! You can use a user created in your IdP and invoke the service through your web application. You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API’s major version. The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage. To subscribe to an API via an application, follow the steps given below: Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs. Tip When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version. Once you subscribe to an API, you can invoke the API using the application keys. An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application. This section walks you through the steps to create an application in Choreo. Let's get started! To create an application in the Choreo Developer Portal, follow the steps given below: This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API. Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API. Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application. The following section walks you through the steps to generate an API access token in Choreo. You can generate keys and tokens to invoke production and non-production endpoints separately. Note The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints. Click to expand Advanced Configurations and review the options. Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials. You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint. To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token. Warning Make sure you do not use the test token in your production environment. Using access tokens for request authorization strengthens security measures, particularly in preventing certain types of denial-of-service (DoS) attacks aimed at published APIs. API consumers generate access tokens to access the API, incorporating them into their HTTP header requests as simple string values. When you register an application on the Developer Portal, you can generate a consumer key and a consumer secret for it. The consumer key and the consumer secret represent the credentials of the application. Similar to a user's username, the consumer key becomes the unique identifier of the application so that you can use it to authenticate the request to the API. Choreo issues an access token for the application against the mentioned consumer key. This section walks you through the steps to generate an access token for your application in Choreo. Let's get started! Before you try out this guide, be sure you have the following: You can follow the steps below to generate an access token for your application via cURL: Use the following template and compile the cURL command with the values you copied in the above step. You can follow the steps below to generate an access token for testing purposes: An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application. This section walks you through the steps to create an application in Choreo. Let's get started! To create an application in the Choreo Developer Portal, follow the steps given below: This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API. Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API. Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application. The following section walks you through the steps to generate an API access token in Choreo. You can generate keys and tokens to invoke production and non-production endpoints separately. Note The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints. Click to expand Advanced Configurations and review the options. Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials. You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint. To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token. Warning Make sure you do not use the test token in your production environment. Choreo authentication is based on OAuth 2.0. In OAuth 2.0, grant types are methods that allow client applications to obtain an access token depending on the type of the resource owner, the type of the application, and the trust relationship between the authorization server and the resource owner. The Authorization code flow provides a secure way for a client application to obtain an access token without exposing the user's credentials to the client application. The user only authenticates with the authorization server, which then issues an authorization code that can be exchanged for an access token. This helps to protect user credentials and prevents credentials from being compromised by malicious client applications. A refresh token is a token that you can use to get a new access token when your current access token is expired or when you need a new access token. You can use the refresh token grant type for this purpose. Issuing a refresh token is optional for the authorization server. If the authorization server issues a refresh token, it includes it in the response with the access token. You can use this refresh token and send it to the authorization server to obtain a new access token. Choreo's default authorization server, Asgardeo, issues refresh tokens for all grant types other than the client credentials grant type, as recommended by the OAuth 2.0 specification. Note The client credentials flow provides a secure way for client applications to obtain an access token without user authentication. This is useful in scenarios where the client application needs to access its own resources, such as data storage or APIs, but does not require access to user data. However, it is important to ensure that the client credentials are kept secure because any party who has these credentials can obtain access tokens and access the client's resources. The implicit grant flow is an OAuth 2.0 grant type that enables a client application to obtain an access token directly from the authorization server without an intermediate authorization code exchange. This flow is commonly used in browser-based applications where the client application runs in a web browser. However, it is important to note that the access token is exposed in the browser's URL fragment, which can make it vulnerable to certain types of attacks, such as cross-site scripting (XSS). As a result, this flow is typically not recommended for applications that require high security. The password grant flow is an OAuth 2.0 grant type that enables a client application to obtain an access token by presenting the user's username and password directly to the authorization server. This flow is generally considered less secure than other grant types, as it requires the client application to handle and transmit the user's credentials. The password grant is primarily used in scenarios where the client application is highly trusted, and the user experience is prioritized over security concerns. It is generally not recommended for use in public-facing applications or scenarios where sensitive data is accessed. Revoking JWT access tokens can be challenging due to their self-validating nature. Once a token is issued, it contains all the necessary information within itself to validate its authenticity, without requiring additional server-side lookups or interactions. It is recommended to use an expiry time that is not more than 900 seconds. In traditional session-based authentication, the server can easily revoke a session by invalidating its associated session ID. However, in the case of JWTs, there is no central authority that maintains a list of valid or invalid tokens. As a result, revoking a JWT token requires the use of denylist or allowlist techniques, which can add additional complexity to the authentication flow and may not always be foolproof. To mitigate these challenges, it is recommended to use short-lived JWT access tokens and regularly refresh them. This reduces the risk of unauthorized access if a token is stolen or leaked, as the token will expire after a short period of time. Additionally, implementing other security measures such as strong encryption and secure token storage can further enhance the security of JWT-based authentication. The Choreo Developer Portal keeps the lifespan of a token to 15 minutes (900 seconds) by default. Application Developers can increase the time if necessary, but as mentioned above, it is recommended to keep it to the minimal possible value. You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API’s major version. The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage. To subscribe to an API via an application, follow the steps given below: Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs. Tip When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version. Once you subscribe to an API, you can invoke the API using the application keys. Choreo's application-sharing feature allows you to share your applications with members within your organization. This facilitates collaborative efforts when there is a need for multiple members to work on the same application. Follow the steps given below to share an application with members of your organization: In the Share Application dialog, enter one or more email addresses depending on the members with whom you want to share the applications. Note You must type an email address and press enter for it to get added. Click Confirm. This will share the application in read-only mode with the specified members. To see the members with whom the application is shared, go to the Application Overview page and take a look at the email addresses in the Shared with field. Choreo allows you to deploy and manage prebuilt container images from external container registries as Choreo components. This enables you to deploy and effectively manage your container images within the Choreo environment. Info This feature is currently only available on private data planes (PDPs) for the following component types: Before you try out this guide, ensure you have the following: A container registry: Ensure you have a container registry containing the images you want to deploy. Choreo is compatible with various container registries, including but not limited to GCR (Google Container Registry), ACR (Azure Container Registry), GitHub Container Registry, and Docker Hub. An image in the registry: You need an image ready for deployment. (Optional) An external build/CI pipeline: This is to initiate automatic deployments during the build process outside of Choreo. When using a container registry to deploy a component, Choreo cannot create an image from the source code (Git) or initiate a new deployment when a new image is ready. However, you can use your existing build process to trigger a deployment on Choreo by sending an HTTP POST request to a webhook with the new image details. This feature is currently only available on private data planes (PDPs). You can find this option under Deploy an image from a container registry in the Select Source step during component creation for service components, web applications, scheduled tasks, and manual tasks. To get started, establish a connection between your container registry and Choreo. Info When you use your Choreo credentials, Choreo does not pull your images into its control plane. Instead, it functions as an orchestrator, facilitating your data plane's ability to retrieve images from an external container registry. Choreo passes on these credentials to the data plane for authentication and access. To register your container registry, follow these steps: Choreo provides the following authentication options: You can use this option to establish a connection with a container registry that permits unrestricted public or anonymous access (for example, Public Docker Hub). In this case, only the registry host information is necessary. For example, the following are the Docker Hub registry hosts for reference: * If necessary, you can use other mirrors instead of the above. To use basic authentication to authenticate to the container registry, you must provide the username and password. You can provide a Docker config in JSON format to authenticate to the container registry. This option only allows you to register one container registry. That is, it only allows a single registry under You must provide the credentials directly within the configuration. Choreo cannot utilize references to executable authentication plugins. Sample Docker config format: This option is specifically for private data planes, where your cloud provider manages authentication at the Kubernetes level. Choreo requires knowledge of the registry host because the data plane already possesses implicit (preconfigured) access to the registry. Follow the guidelines below based on your container registry: Azure Container Registry Recommended authentication options: Vendor-specific authentication on Azure private data planes Contact Choreo support to enable infrastructure-level private access to your registry from your Azure private data plane on AKS. If you are on a self-managed PDP on Azure, follow this guide. Google Artifact Registry Recommended authentication options: Service account-based basic authentication Use the service account key in JSON format ( You can use Vendor-specific authentication on GCP private data planes Contact Choreo support to enable infrastructure-level private access to your registry from your GCP private data plane on GKE. If you are on a self-managed PDP on GCP, see https://cloud.google.com/artifact-registry/docs/access-control#grant-project. Elastic Container Registry ECR does not allow the creation of static access passwords for basic authentication. The passwords (that is, access tokens) provided by AWS are only valid for 10 hours and must be manually regenerated. However, when an ECR is attached to an EKS cluster at an infrastructure level, this limitation does not apply because the authentication is handled by AWS internally. For details, see https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html. Choreo recommends using ECR when you are exclusively on an AWS private data plane using the vendor-specific authentication option. Contact Choreo support to enable a private connection between your ECR and the underlying EKS clusters on your data plane. If you are on a self-managed PDP, you can follow this guide. Recommended authentication options: Basic authentication Use your Docker Hub username/password or an access token. You can generate an access token from your Docker Hub account settings and use it in place of the password. For details, see https://docs.docker.com/docker-hub/access-tokens/. Docker config Sign in to the Docker CLI and copy the contents of the docker config JSON. Note that external credential stores and multiple repositories within the same config object are not supported. For more information, see https://docs.docker.com/engine/reference/commandline/login/. GitHub Container Registry Recommended authentication option: Basic authentication using a PAT token Create a personal access token (PAT) and use it in place of the password. You cannot use your own GitHub password. You must provide a PAT token. Enter a display name, a unique name, and a description for the component. Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click either the Docker Hub tab or the Container Registry tab depending on your vendor. Enter the full image URL. The image URL format in general is as follows:
- Tip When a public image from Docker Hub lacks a specified repository name, it typically defaults to To deploy the component and bring your image to Choreo, follow the steps given below: Click Update. Info In this example, you deploy a Ballerina service as a REST endpoint. Therefore, Choreo generated the REST endpoint automatically. If you deploy a non-Ballerina service, you must manually add the REST endpoint and set the network visibility to Public. Select your update image option. Refer to the update options listed below. You have the capability of updating the image when you are deploying the component in Choreo in one of the following three ways: Click Deploy. This deploys the service to the development environment. Info This section only applies to service components. After creating a service component in Choreo, you have the option to define the endpoints for your service when manually deploying a new image. Choreo does not have automatic detection and deployment for newly added images or tags in the linked container registry. To overcome this limitation, Choreo allows you to integrate your own CI pipelines and initiate deployments manually. This approach enables you to use your existing CI setup or build a pipeline for image creation and pushing. You can then trigger automatic deployments using a webhook. Follow the steps below to configure your CI/build pipeline: Generate a token for your CI pipeline from the Manage Tokens section. Note To trigger an automatic deployment to your development environment, you can initiate an HTTP POST request to the Choreo webhook endpoint with the updated image details. Alternatively, you can use the provided Webhook snippets. This action will seamlessly deploy the image to the development environment. Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way. Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint. The method of defining endpoints depends on the buildpack. For buildpacks other than When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the See Understanding the endpoints.yaml file to learn about the When you create a service component with the Note Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an See Understanding the endpoints.yaml file to learn about the The File location: Note For components built with Ballerina buildpack For components built with WSO2 MI buildpack File content: The Beta release The Inbound configurations: This configuration section is for you to define inbound connections, Similar to Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace. Note The In the In the The Note Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value. File location: Note File content: Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design. Note This feature is not available for gRPC, UDP, and TCP endpoints. If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including: Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features. The default URL of a component corresponds to the default endpoint of the component and is structured as follows: This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows: If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint. To change the default endpoint of a component, follow the steps given below: Note Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way. Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint. The method of defining endpoints depends on the buildpack. For buildpacks other than When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the See Understanding the endpoints.yaml file to learn about the When you create a service component with the Note Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an See Understanding the endpoints.yaml file to learn about the The File location: Note For components built with Ballerina buildpack For components built with WSO2 MI buildpack File content: The Beta release The Inbound configurations: This configuration section is for you to define inbound connections, Similar to Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace. Note The In the In the The Note Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value. File location: Note File content: Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design. Note This feature is not available for gRPC, UDP, and TCP endpoints. If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including: Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features. The default URL of a component corresponds to the default endpoint of the component and is structured as follows: This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows: If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint. To change the default endpoint of a component, follow the steps given below: Note Using Choreo, you can easily deploy applications written in different language frameworks (such as Java, Go, NodeJS, Python, etc.) on shared or private data planes using containers. Choreo supports deploying containerized applications for the following component types: To connect your GitHub repository to Choreo, you should authorize the Choreo Apps GitHub application to access your account or organization. When you attempt to connect your GitHub repository via the Component creation page, the Choreo Apps authorization prompt will appear. Connect GitHub Repository Authorize GitHub Application Grant Repository Access The Choreo Apps requires the following permission: Note You can revoke access if you do not want Choreo to have access to your GitHub account. Choreo needs write access only to send pull requests to a user repository. Choreo does not directly push any changes to a repository. Alternatively, you can connect a public repository without requiring authorization from the Choreo Apps GitHub application. You can paste a public repository URL in the Provide Repository URL field at the time of component creation. Tip Authorizing the repository with the Choreo Apps GitHub application becomes essential if you want to enable Auto Deploy for the component. If you own the repository, you can subsequently authorize it with the Choreo Apps GitHub application to enable Auto Deploy. After granting access to the required repositories, you can choose a repository and an associated branch to connect to the Choreo component.
-For the containerized application deployments, you should select the Dockerfile as the Buildpack and provide Dockerfile Path and Docker Context Path for the Docker build. The following table describes the individual fields in the Create Component pane. Note Fields marked with * are not visible for all component types. To successfully build your container with Choreo, it is essential to explicitly define a User ID ( To ensure that the defined USER instruction is valid, it must conform to the following conditions: Choreo will automatically apply deployment configurations and settings based on the component type you select during creation.
-For example, if you select the Service component type, Choreo will deploy it as a Kubernetes deployment with appropriate scaling configurations. You can run unit tests in the build pipeline by adding the relevant command to the Dockerfile. For example: You must provide any required configurations for running the application in the Configs & Secrets section of the component's DevOps page. Alternatively, you can also review the configurations when you manually deploy via the Deploy page. After clicking the Create button, you can select the confidentiality of the configuration and specify how to mount it to the container. The following image shows adding a ConfigMap with File Mount mount type to be read by the application. Note The JSON file includes ${DB_PASS} as an environment variable defined in a Secret. The application reads the JSON file and substitutes the placeholders with the corresponding environment variables. Choreo lets you configure deployment settings such as scaling, resource limits, and health checks based on your selected component type. For more information about these configurations, see Choreo's DevOps capabilities. You can configure the Endpoints to expose your service using the Service Component in Choreo. See Service Component Overview for more information. After adding the application configuration, you can build and deploy it by clicking the Deploy Manually button. Choreo will start the build process with the selected commit in the Build Area. Note The Auto Deploy on Commit feature, which automatically builds and deploys the application upon pushing a code change to the repository, is enabled by default. To turn off this feature, navigate to the Build Area of the Deploy page. Choreo scans your Dockerfile for security vulnerabilities during the build phase, and if there are no issues found, it proceeds with the build process. After building the image, it scans it again for vulnerabilities before deployment to the environment. You can view the build logs from the right-side panel, as shown in the image below. Once the build process is complete, Choreo will deploy the application automatically to the Development environment. To promote the build to higher environments, you can click the Promote button. The number of environment cards visible on the page may vary depending on your environment configurations. By default, Choreo utilizes the Aqua Trivy (OSS) image vulnerability scanner to detect security vulnerabilities in all Dockerfile-based build pipelines. The scanner will fail the pipeline if any CRITICAL CVEs (Common Vulnerabilities and Exposures) are detected. CVEs of other severity levels are recorded but does not fail the pipeline. If you cannot fix a critical CVE immediately, you can opt to ignore it. To ignore a critical CVE, add a You can add comments in the file by using Using Choreo, you can easily deploy applications written in different language frameworks (such as Java, Go, NodeJS, Python, Ruby, PHP, etc.) on shared or private data planes. Choreo supports deploying applications with buildpacks for the following component types: Buildpacks are a fundamental building block in modern application development. They convert your source code into a secure, efficient, production-ready container image without a Dockerfile. With Choreo, developers can take advantage of this powerful tool to effortlessly deploy their applications without the hassle of manual configuration. Choreo uses Google Buildpacks as default buildpacks for Java, Go, NodeJS, Python, PHP, and Ruby. Choreo uses its own buildpacks for Ballerina and WSO2 MI. To develop a service component that exposes a Service in Go, you can follow the Develop a Service guide. Follow the guidelines below based on your language: Supported Versions - 3.10.x, 3.11.x Refer below examples for different component types. Follow the A Info In Python projects, it is mandatory to have a Here's an example e.g., For more examples, see Choreo samples. Supported Versions - 2201.3.5, 2201.4.1, 2201.5.0, 2201.5.1, 201.6.0, 2201.7.0 Refer below examples for different component types. Follow the For more examples, see Choreo samples. Supported Versions - 1.x Refer below examples for different component types. Follow the For more examples, see Choreo samples. Supported Versions - 6.x, 7.x, 8.x Refer below examples for different component types. Follow the For more examples, see Choreo samples. Supported Versions
- - 8, 11, 17, 18 (OpenJDK Runtime Environment Temurin) Refer below examples for different component types. Follow the Info When working on Java projects: A Here's an example e.g., For more examples, see Choreo samples. Supported Versions - 12.x.x, 14.x.x, 16.x.x, 18.x.x, 20.x.x Refer below examples for different component types. Follow the A Here's an example e.g., For more examples, see Choreo samples. Supported Versions - 8.1.x, 8.2.x Refer below examples for different component types. Follow the A Here's an example e.g., For more examples, see Choreo samples. Supported Versions - 3.1.x, 3.2.x Refer below examples for different component types. Follow the A Here's an example e.g., For more examples, see Choreo samples. Supported Versions - 4.1.0.x, 4.2.0.x Refer below examples for different component types. Follow the For more examples, see Choreo samples. Supported Java Versions
- - 8, 11, 17, 18 (OpenJDK Runtime Environment Temurin) Info You can use this buildpack only with web applications. For other component types, use the Java buildpack. Additionally, if the generated artifact is a A Here's an example e.g., You can configure the environment variables necessary to build the component using the Build Configurations Editor on the component Build page. Info The capability to configure build-time environment variables is not available for components created using Ballerina or WSO2 MI buildpacks. During the build process, the build-time environment variables and their values are passed to the buildpack. Therefore, you can configure both buildpack-specific environment variables and those required for the component build. For example, if you want to override the Maven command of the Java buildpack, you can use For more examples, see Google Cloud's buildpacks documentation. Choreo allows developers to design high-quality webhooks. To explore this capability, let's consider a scenario where a team of software engineers in an organization should be notified via email whenever someone creates a GitHub issue with the In this tutorial, you will address the requirement by doing the following: Before you try out the steps in this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: Fork the Choreo samples repository, which contains the sample integration for this guide. To create a project, add a Webhook component to it, design the webhook, test it, and then commit it to make it available in the Choreo Console, follow these sub-steps: First, let's create a Webhook component as follows: To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Select the Access Mode depending on your requirement. Enter the following information: Click Create. Choreo creates the Webhook component with the sample implementation and opens the component Overview page. Let's deploy the webhook to the development environment to make it invokable: In the Configurations pane, enter the following information: In the webhookSecret field, enter any value. Note You must save this value for later use. In the toEmail field, enter the email address to send notification emails. You can monitor the deployment progress in the Console pane that opens on the right of the page. Once Choreo completes the deployment, the Development card indicates the Deployment Status as Active. Notes In the deployment card, you can click the icon corresponding to configurables to open the Configurations pane and edit configurations: To allow the webhook to read the labels of issues in a specific GitHub repository, you must connect the webhook to the GitHub repository. To do this, follow these steps: In the Choreo Console left navigation menu, click Overview. On the Overview page, copy the invoke URL. You can click the copy icon within the URL field. Go to your GitHub account and open the repository for which you want to generate notification emails. In the top menu, click the Settings tab. In the left navigation menu, click Webhooks. Click Add webhook and enter the following information: Tip Buildpack specifies the type of build to run depending on the implementation of the component. It converts the integration code into a Docker image that can run on Choreo cloud. If an integration is developed using WSO2 Integration Studio, select Micro Integrator as the buildpack. If an integration is developed using the Ballerina language, select Ballerina as the buildpack. Project Path specifies the location of the project to build the component. Under Which events would you like to trigger this webhook?, select Let me select individual events. Select the Issues checkbox in the list of events displayed. By doing so, you select GitHub issues as events that need to trigger this webhook. In the same list of events, clear the Pushes checkbox to ensure that GitHub does not trigger your webhook when the team pushes changes to the selected GitHub repository. Click Add webhook to save the configuration. Now you have integrated Choreo with GitHub via the webhook you created and deployed. You can proceed to test the webhook. To test your webhook, create a GitHub issue with the You will receive a mail similar to the following to the email address you provided in Step 2. To promote the webhook to the Production environment, follow these steps: On the Deploy page, go to the Development card and click Promote. In the Configuration Types pane, leave the default selection (i.e., Use default configuration values) unchanged. If you have configured any default values for the configurable variables, selecting Use default configuration values allows you to proceed with those values. If you have not configured any default values for configurable variables, follow the steps given below to specify values. Click Next. In the webhookSecret field, enter any value. Note You must save this value for later use. In the toEmail field, enter the email address to send notification emails. Once the component is promoted to production, the Production card displays the deployment status as Active. Now you have successfully created, deployed, and tested a Webhook component and promoted it to production. An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, which allows you to apply essential API management features such as security policies and rate limiting. In this guide, you will: Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this guide, you will specify a URL to an OpenAPI definition of a sample API. Follow the steps given below: Specify the values given in the following table as API proxy details: Info In the Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click Create. This creates the API proxy component and takes you to the Overview page. Now you can proceed to define resources for the API proxy. To add a new resource that can retrieve a department by the department ID, follow the steps given below: Click to expand the added resource and specify appropriate values for the Operation ID and Description fields. You can specify the values given in the following table: To remove the five default resources that start with To deploy the API proxy to the development environment, follow the steps given below: In the left navigation menu, click Deploy. In the Build Area card, click Configure & Deploy. This opens the Configure & Deploy pane, where you can select the API access mode depending on how you want the API to be accessible. Here, you can select External. Click Deploy. The Development card indicates the Deployment Status as Active when the API proxy is successfully deployed. Now you are ready to test the API proxy. Choreo allows you to test your API proxy using either the integrated OpenAPI Console or cURL. In this guide, you will use the OpenAPI Console to test the API proxy. Follow the steps given below: Tip Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API. In the left navigation menu, click Test and then click OpenAPI Console. Select Development from the environment drop-down list. Expand the Enter This indicates that your API proxy is working as expected. Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. Depending on your requirement, you can apply security, throttling, and other settings to the API before you publish it. In this guide, you will apply rate limiting to the API and publish it. To apply a rate limiting level to the API, follow the steps given below: To publish the API proxy to the Choreo Developer Portal, follow the steps given below: To generate credentials for the published API and to invoke it via the Choreo Developer Portal, follow the steps below: To open the published API in the Choreo Developer Portal via the Lifecycle page, click Go to Devportal. This takes you to the To generate credentials to test the API, follow the steps given below: Click Generate Credentials. Choreo generates new tokens and populates the Consumer Key and Consumer Secret fields. Tip If you want to test the API via an API test tool or through code, click Generate Access Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client. You do not need to generate an access token if you are testing the API via the Try Out capability in the Choreo Developer Portal. To invoke a resource via the Try Out capability in the Choreo Developer Portal, follow the steps given below: Enter Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo API Manager. To learn more about the API management capabilities supported by Choreo API Manager, see API Management. The Choreo VS Code extension provides comprehensive component management capabilities to streamline local development within Choreo. To ensure a smooth development experience with the Choreo extension, make sure you have the following: Visual Studio Code installed with the Choreo extension version 2.0.0 or later. A locally cloned GitHub repository to create new components or link to existing Choreo components. Git version 2.0.0 or later. To use the capabilities of the Choreo extension in the VS Code editor, you need an active Choreo account. If you already have an account, follow these steps to set up the extension: Sign in to Choreo using one of the following methods: This redirects you to an external URI to complete the authentication process. On successful sign-in, the Choreo activity pane displays your account details along with any components detected within the VS Code workspace. Create a new component using one of the following methods: If the Choreo extension cannot determine the project context of the opened workspace, it prompts you to select the organization and the project to which the new component belongs. Specify component details such as the name, type, buildpack, etc. On successful creation, the component details view opens, and the Choreo activity pane displays the new component. Tip Once the component is created, a The component details view allows you to manage your component by performing various actions such as the following: Context files contain metadata related to the project, allowing the extension to establish an association between local directories and Choreo projects. These files, such as the The Choreo extension scans the root of the opened Git repository to find the A You can decide whether to commit the If the To access a range of functionalities provided by the Choreo extension, open the VS Code command palette and type To troubleshoot Choreo extension issues, follow these steps: To open the OUTPUT pane, go to the VS Code editor main menu, click View, and then click Output. Select Choreo from the drop-down menu on the right-hand side to view the Choreo output for troubleshooting. For assistance with the Choreo VS Code extension, create GitHub issues. Choreo enables you to develop components by connecting your GitHub, Bitbucket, or GitLab repository. You have the flexibility to either connect an existing repository or start with an empty repository and commit the source code later. By integrating your repositories with Choreo, you can automate tasks and optimize workflows across multiple systems, all within the Choreo platform. Choreo currently supports GitHub, Bitbucket, and GitLab as Git providers. Tip Choreo supports both Bitbucket Server and Bitbucket Cloud. The currently supported Bitbucket Server version is 8.9.2. In Choreo, you can connect a Git repository that contains Ballerina source code or a Docker project. To connect a Git repository to Choreo as a Docker project, your Git repository must include the following: Once you connect your Git repository to Choreo, you can build, deploy, and manage your application easily. Authorizing Choreo as a GitHub application grants Choreo the following permissions to perform the respective actions on your behalf within the repository: Choreo provides Git submodule support when you connect your GitHub repository to Choreo. This allows you to manage and include external repositories effectively within Choreo build pipelines. Key benefits of this capability include: For example, when you work with the Micro Integrator (MI) runtime in Choreo, you can use Git submodules to reuse MI templates and sequences across components without duplication. Tip If you encounter an error stating that you cannot clone a submodule due to insufficient permissions, follow the instructions below to grant the necessary permissions: For a personal account: For an organization account: Under Repository Access, grant access to the necessary repositories. Note Choreo currently does not support accessing private repositories in other organizations. Authorizing using a personal access token (PAT) from Bitbucket grants Choreo the following permissions to perform the respective actions on your behalf within the repository. Authorizing using a personal access token (PAT) obtained from your GitLab self-managed server grants Choreo the following permissions to perform the respective actions on your behalf within the repository. This guide walks you through the steps to develop, deploy, test, and observe a manual task using Choreo. In this guide, you will: Before you try out the steps in this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: Fork the Choreo samples repository, which contains the sample integration for this guide. Repository file structure To work with the sample repository, it is important to familiarize yourself with the repository file structure. The sample code for this guide is in the Go to OpenWeatherMap and sign up to obtain an API key. For details on how to obtain an API key, see the OpenWeatherMap documentation. Enter a unique name and a description for the component. You can use the name and description given below: Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Tip Buildpack specifies the type of build to run depending on the implementation of the component. It converts the integration code into a Docker image that can run on Choreo cloud. If an integration is developed using WSO2 Integration Studio, select Micro Integrator as the buildpack. If an integration is developed using the Ballerina language, select Ballerina as the buildpack. Project Directory specifies the location of the project to build the component. Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component. To build the manual task, follow the steps given below: Select the latest commit and click Build. This triggers the build process and displays the build progress in the Build Logs pane. Info The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with the build status. Here, you will see the build status as Success. To deploy the manual task, follow the steps given below: In the Configurations pane, specify values as follows for the configurable variables: Tip The configurable variables populated here are defined in the sample Ballerina project used in this guide. To learn how to declare configurable variables in Ballerina, see the Ballerina documentation on declaring configurable variables. If configurable variables are detected in a connected Ballerina project, Choreo prompts for the respective values during component deployment. Note If you use Ballerina as the buildpack and you want to set a configurable variable as a secret, click the lock icon corresponding to the configurable variable. This marks it as a secret and conceals the input value. For example, if you consider the configurable variables in this guide and set the apiKey as a secret, its input value will be concealed as follows: If you want to update the input value at a later time, you can click Update Secret Content and specify a new value. Click Deploy. To execute the manual task, follow the steps given below: Click Run Now. This triggers the task. Inject dynamic values into your application as command-line arguments If you want to inject dynamic values into your application as command-line arguments when you run a manual task, follow the steps given below: The capability to run a manual task with arguments is supported for the following buildpacks: To explore a Dockerfile-based manual task with arguments, try out the Hello World Task sample. For instructions, see the Info When you work on Docker projects, the Run with Arguments capability is not supported if the Dockerfile contains To explore a Go-based manual task with arguments, try out the Hello World Go Task sample. For instructions, see the To explore a Java-based manual task with arguments, try out the Hello World Java Task sample. For instructions, see the Info When you work on Java projects: To explore a NodeJS-based manual task with arguments, try out the Hello World NodeJS Task sample. For instructions, see the Info When you work on NodeJS projects: To explore a WSO2 MI-based manual task with arguments, try out the Weather to Logs Task sample. For instructions, see the Info When you work on WSO2 MI projects and you want to deploy a WSO2 MI integration as a manual task in Choroeo, you must use the WSO2 MI automation mode. For details, see Running the Micro Integrator in Automation Mode. To explore a Ballerina manual task with arguments, try out the Weather to Email Task sample. For instructions, see the README.md file in the sample repository. Info If you want to pass arguments to Ballerina main functions, you can use the Run with Arguments capability. For details on the arguments you can pass, see the Ballerina documentation. You can also override configurable values in the same manner. For more information, see Provide values to configurable variables. Once the task is triggered, an email with the subject If the manual task ran successfully, you should receive an email similar to the following to the email address you specified: The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy. To visualize and monitor the performance of the manual task you deployed, click Observability in the left navigation menu. You can observe the following: To learn more about the observability details you can view via Choreo observability, see Observability Overview. To track and monitor executions associated with the deployed scheduled task, go to the left navigation menu and click Execute. Tip The Execute view is applicable to both scheduled and manual tasks. You can view the following information: The total number of executions within the past 30 days. The currently active executions and those that are already complete. Here, you can view information such as the execution ID, the revision of the execution, and the time it was triggered. Detailed execution logs for a specific execution. You can click on an execution to view detailed logs related to it. Info It may take a few minutes for the logs to appear. You may need to manually refresh to view the latest logs. Choreo is a versatile integration platform that allows you to create various types of integrations depending on your requirement. If you have a requirement to automatically run a specific integration at regular intervals, you can use Choreo to develop a scheduled task. This type of integration can automate the synchronization of data between different systems at specified intervals, reducing errors and improving productivity by eliminating the need for manual intervention. This guide walks you through the steps to develop, deploy, test, and observe a scheduled task using Choreo. In this guide, you will: Before you try out the steps in this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: Fork the Choreo samples repository, which contains the sample integration for this guide. Repository file structure To work with the sample repository, it is important to familiarize yourself with the repository file structure. The sample code for this guide is in the Go to OpenWeatherMap and sign up to obtain an API key. For details on how to obtain an API key, see the OpenWeatherMap documentation. Enter a unique name and a description for the component. You can use the name and description given below: Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Tip Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component. Now you can proceed to build and deploy the scheduled task. To build the scheduled task, follow the steps given below: Select the latest commit and click Build. This triggers the build process and displays the build progress in the Build Logs pane. Info The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with the build status. Here, you will see the build status as Success. To deploy the scheduled task, follow the steps given below: In the Configurations pane, specify values as follows for the configurable variables: Tip The configurable variables populated here are defined in the sample Ballerina project used in this guide. To learn how to declare configurable variables in Ballerina, see the Ballerina documentation on declaring configurable variables. If configurable variables are detected in a connected Ballerina project, Choreo prompts for the respective values during component deployment. Note If you use Ballerina as the buildpack and you want to set a configurable variable as a secret, click the lock icon corresponding to the configurable variable. This marks it as a secret and conceals the input value. For example, if you consider the configurable variables in this guide and set the apiKey as a secret, its input value will be concealed as follows: If you want to update the input value at a later time, you can click Update Secret Content and specify a new value. Click Next. In this step, you must define a schedule to run the task. In this guide, you set the schedule to receive the weather information daily at 8.00 AM UTC. Enter values as follows to configure the schedule: Tip When you develop a scheduled task, you can define a schedule depending on your requirement. If you want to test and verify the immediately, you can schedule the deployment to run in just a few minutes after you create it. However, to avoid unnecessary expenses, make sure you reschedule or stop the deployment once you test and verify. Click Deploy. This deploys the scheduled task to the development environment and indicates the Scheduled Status as Active in the Development card. You can test the scheduled task when it runs at the configured time. When the scheduled task runs at the configured time, an email with the subject If the scheduled task ran successfully, you should receive an email similar to the following to the email address you specified: The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy. To visualize and monitor the performance of the scheduled task you deployed, click Observability in the left navigation menu. You can observe the following: To learn more about the observability details you can view via Choreo observability, see Observability Overview. To track and monitor executions associated with the deployed scheduled task, go to the left navigation menu and click Execute. Tip The Execute view is applicable to both scheduled and manual tasks. You can view the following information: The total number of executions within the past 30 days. The currently active executions and those that are already complete. Here, you can view information such as the execution ID, the revision of the execution, and the time it was triggered. Detailed execution logs for a specific execution. You can click on an execution to view detailed logs related to it. Info It may take a few minutes for the logs to appear. You may need to manually refresh to view the latest logs. An Event Handler executes predefined actions in response to specific events. Choreo simplifies the process of creating and deploying such integrations. This guide walks you through the steps to create and deploy an Event Handler using WSO2 MI and Choreo. In this guide, you will build a simple event handler that monitors RabbitMQ for new messages and displays them once they become available. Before you try out the steps in this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: Use an existing RabbitMQ instance or start a new RabbitMQ instance on a server that can be accessed via the internet. Obtain the Fork the Choreo samples repository, which contains the sample integration for this guide. Enter a unique name and a description for the component. You can use the name and description given below: Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Tip Click Create. To deploy the integration, follow the steps given below: In the Configurations pane, click + Add corresponding to Environment Variables and add the following environment variables: Tip Use the values from your RabbitMQ instance as per the Prerequisites section, for the environment variables. Click Deploy. This deploys the event handler to the development environment and indicates the Deployment Status as Active in the Development card. To test the integration, follow the steps given below: Now you have gained hands-on experience in creating, configuring, and deploying an event handler. The seamless integration of APIs, microservices, applications, and data across different languages and formats requires the ability to expose integrations as APIs. Choreo simplifies building, deploying, and managing integration components, making it easy for you to quickly expose integrations as APIs. Note This guide walks you through the steps to expose an integration you created in WSO2 Integration Studio as an API in Choreo. In this guide, you will: Before you try out the steps in this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: Fork the Choreo samples repository, which contains the sample integration for this guide. Enter a unique name and a description for the component. You can enter the name and description given below: Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Click Create. Choreo initializes the component with the sample integration. To deploy the integration component to the development environment, follow the steps given below: Click Deploy. This deploys the integration component to the development environment.
-The Development card indicates the Deployment Status as Active when the integration is successfully deployed. Tip Choreo uses endpoints to expose Service component to the network. You can read more about configuring endpoints in Configure Endoints. Tip Automatic deployment is enabled for the component by default. Therefore, you are required to perform only the first deployment manually. Now you can test the integration. To test the integration using the OpenAPI Console. Follow the steps given below: Go to the Response body section and observe the response returned by the integration. If the integration works as expected, you should see a response similar to the following: The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy. To visualize and monitor the performance of the integration component you deployed, click Observability in the left navigation menu. You can observe the following: To learn more about the observability details you can view via Choreo observability, see Observability Overview. To publish the integration component, follow the steps given below: To open the published API in the Developer Portal via the Lifecycle Management pane, click Go to Devportal. In the Choreo Developer Portal, you can view the published API, manage subscriptions for it, and generate access tokens for testing purposes. Now, you have gained hands-on experience in exposing an integration designed using WSO2 Integration Studio as a REST API in Choreo. Choreo allows you to develop and deploy applications using your preferred programming language. This guide demonstrates how to deploy a service component that exposes a REST API using the Ballerina language. No prior knowledge of the Ballerina language is required to follow this guide. A REST API is a web service adhering to Representational State Transfer (REST) principles, using HTTP methods to access and manage resources. This guide walks you through building a Ballerina service component, deploying it on Choreo, and using it with an HTTP client application. In this guide, you will: Build a simple greeting service using a sample service implementation. The sample implementation will have a single resource named Request: Response: Deploy the service in Choreo. The service will run on port 9090. Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample greetings service implementation in It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service: Note The specified file paths are relative to Let's get started! To create a Ballerina service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Ballerina as the buildpack. You have successfully created a service that exposes a REST API written in the Ballerina language. Next, let's build and deploy the service. Now that you have connected the source repository and configured the endpoint details, it's time to build and deploy the service. Note If you are rebuilding the Ballerina service component after changing the Ballerina version, ensure that before building the code, the version of the Ballerina distribution mentioned in the To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. To build and deploy the service, follow the steps below: Once you have successfully deployed your service, you can test, manage, and observe it like any other component type in Choreo. For detailed instructions, see the following sections: If you want to view Kubernetes-level insights to perform a more detailed diagnosis of this Ballerina REST API, see Choreo's DevOps capabilities. Choreo is a platform that allows you to create and deploy applications in any language. In this guide, you will: If you want to create a service component that exposes a Ballerina service, see Develop a Ballerina Service . Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample greetings service implementation with the Dockerfile. It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service: Note The specified file paths are relative to Let's get started! In Choreo, you can expose your services via endpoints. You are going to run the greeter service on port 9090. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints. To configure the endpoint details of a containerized component, Choreo looks for an In the greeter sample, the To create a containerized service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Info To successfully build your container with Choreo, it is essential to explicitly define a user ID (UID) under the USER instruction in your Dockerfile. For reference, see sample Dockerfile.
-To ensure that the defined USER instruction is valid, it must conform to the following conditions: The Dockerfile used in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries. Click Create. This creates the component and takes you to the Overview page of the component. You have successfully created a service from a Dockerfile. Next, you can build and deploy the service. Now that we have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then we can deploy that image test the greeter service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. You can access the following scans under Build. Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail. Info If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. Once you have successfully deployed the service, you can test, manage, and observe it like any other component type in Choreo. To perform a more detailed diagnosis of this Dockerfile-based REST API by viewing Kubernetes-level insights, see Choreo's DevOps capabilities. Choreo allows you to create and deploy applications in your preferred programming language. In this guide, you will: Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample greetings service implementation in It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service: Note The specified file paths are relative to Let's get started! In Choreo, you can expose your services via endpoints. You are going to run the greeter service on port 9090. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints. To configure the endpoint details of a containerized component, Choreo looks for an In the greeter sample, the To create a containerized service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Go as the buildpack. Enter the following information: Click Create. This creates the component and lists it under Component Listing on the project home page. You have successfully created the service. The next step is to build and deploy it. Now that you have connected the source repository and configured the endpoint details, it's time to build and deploy the greeter service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. Once you have successfully deployed the service, you can test, manage, and observe it like any other component type in Choreo. Choreo offers the flexibility to develop and deploy applications in a language of your preference. This guide shows you how to deploy a service component that exposes a GraphQL API using the Ballerina language in Choreo. No prior knowledge of the Ballerina language is required to follow this guide. GraphQL API is a query language and runtime that provides a single endpoint for retrieving flexible and efficient data in a strongly-typed and self-documenting way. By following this guide, you will build a service component in Ballerina and deploy it on Choreo for any GraphQL client application to utilize it. This guide shows how to build a simple reading list service and deploy it in Choreo using Ballerina. The GraphQL endpoint you create in this guide has two operations: Query and Mutation. The Query type operations read the data in the data source, and the Mutation operations update the data in the data source. The reading list service has two queries and three mutations as follows: Retrieve the reading list This resource accepts an optional filter, Sample request:
- Sample response
- Retrieve a book item from the reading list This resource accepts a filter, Sample request
- Sample response
- Add a book item to the reading list This remote function accepts a book record as the input and consists of the title and the author. When you add a new book to the reading list, the method updates the reading status of the newly added book to Sample request Sample response Update the reading status of a book This remote function requires Sample request Sample response Delete a book item from the reading list This remote function requires the Sample request Sample response
- Our next step is to set up the resources that you will require to follow the guide, including the sample reading list application and the Choreo GitHub app. If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample GraphQL service implementation for this guide. Let's get started! It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the reading list service. Note The following file paths are relative to the path To create a Ballerina service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Ballerina as the buildpack. Enter the following information: Click Create. This creates the component and takes you to the Overview page of the component. You have successfully created a service component that exposes a GraphQL API written in the Ballerina language. Next, let's build and deploy the service. Now that we have connected the source repository, it's time to build and deploy the reading list service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. To build and deploy the service, follow the steps below: Once you have successfully deployed your service, you can test, manage, and observe it like any other component type in Choreo. For detailed instructions, see the following sections: Choreo allows you to create and deploy applications in your preferred programming language. One powerful option is gRPC, a high-performance and language-agnostic remote procedure call (RPC) framework. It utilizes Protocol Buffers to define services and generate client/server code. In this guide, you will learn to use Choreo to create a service component that exposes a gRPC server implemented in Go, enabling efficient and scalable communication with any gRPC client application. No prior knowledge of the Go language is necessary to follow this guide. By following this guide, you will: Link the containerized gRPC service to the Choreo component using the Dockerfile.
- The greeter service has a single RPC method named Deploy the gRPC server component in Choreo. Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample service implementation for this guide. Let's get started! It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service. Note The following file paths are relative to the path In Choreo, you can expose your services via endpoints. Let's run the gRPC server service component on port 8080. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints. Choreo looks for an In the gRPC server sample, the To create a containerized service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Info To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile.
-To ensure that the defined USER instruction is valid, it must conform to the following conditions: The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries. Click Create. This creates the component and takes you to the Overview page of the component. You have successfully created a service from a Dockerfile. Next, you can build and deploy the service. Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the greeter service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. You can access the following scans under Build. Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail. Info If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. Once you have successfully deployed your service, navigate to the component overview page and copy the gRPC service URL. You need to provide that URL when setting up the client application later in this guide. You have successfully deployed the gRPC server. Currently, the gRPC service is only accessible by the components deployed within the same project. Let's invoke the gRPC service that you created above, using a gRPC client. To create a manual task component, follow these steps: Enter a display name, a unique name, and a description for the component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Click Create. This creates the component and takes you to the Overview page of the component. To build the component, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. The client application, in this case, the gRPC client, requires the server URL of the gRPC server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application: Specify the following name and value to configure the environment variable for the client application: Click Add and then click Next. To execute the gRPC client, follow these steps: For details on what you can monitor via the execute page, see Monitor executions. Choreo offers the flexibility to design and deploy applications in the programming language of your choice. One viable choice for specific network communication needs is TCP (Transmission Control Protocol). TCP provides a reliable, stream-oriented communication mechanism that ensures data integrity and orderliness during transmission. It's the go-to option for scenarios where guaranteed data delivery and error recovery are paramount. In this guide, you will learn to use Choreo to create a service component that exposes a TCP server implemented in Go, enabling efficient and scalable communication with any TCP client application. No prior knowledge of the Go language is necessary to follow this guide. By following this guide, you will: Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample service implementation for this guide. Let's get started! It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the sample service. Note The following file paths are relative to the path In Choreo, you can expose your services via endpoints. Let's run the TCP server service component on port 5050. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints. Choreo looks for an In our TCP server sample, the To create a containerized service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Info To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile.
-To ensure that the defined USER instruction is valid, it must conform to the following conditions: The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries. Click Create. This creates the component and takes you to the Overview page of the component. You have successfully created a service from a Dockerfile. Next, you can build and deploy the service. Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. You can access the following scans under Build. Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail. Info If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. Once you have successfully deployed your service, navigate to the component overview page and copy the TCP service address. You need to provide that address when setting up the client application later in this guide. You have successfully deployed the TCP server. Currently, the TCP service is only accessible by the components deployed within the same project. Now let's use a TCP client to invoke the TCP service that you created above. To do this, you can create a manual trigger component as the TCP client. This is the recommended approach because, in this example, it's more efficient to have a client that connects to the server, sends a request, and then stops. Here, a continuously executing task isn't required. Furthermore, if you use a manual trigger component, you won't need to expose an endpoint in the client for invocation, unlike with an API. To create a manual task component, follow these steps: Enter a display name, a unique name, and a description for the component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Click Create. This creates the component and takes you to the Overview page of the component. To build the component, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. The client application, in this case, the TCP client, requires the server URL of the TCP server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application: Specify the following name and value to configure the environment variable for the client application: Click Add and then click Next. To execute the TCP client, follow these steps: For details on what you can monitor via the execute page, see Monitor executions. Choreo offers the flexibility to design and deploy applications in the programming language of your choice. One compelling choice for certain network communication needs is UDP (User Datagram Protocol). UDP is a high-speed, connectionless protocol ideal for scenarios where lightweight, real-time data transmission is essential. In this guide, you will learn to use Choreo to create a Service component that exposes a UDP server implemented in Go, enabling efficient and scalable communication with any UDP client application. No prior knowledge of the Go language is necessary to follow this guide. By following this guide, you will: Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the Project Home page of the default project created for you. Fork the Choreo samples repository, which contains the sample service implementation for this guide. Let's get started! It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the sample service. Note The following file paths are relative to the path In Choreo, you can expose your services via endpoints. Let's run the UDP server service component on port 5050. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints. Choreo looks for an In our gRPC server sample, the To create a containerized service component, follow these steps: Enter a display name, a unique name, and a description for the service component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Info To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile.
-To ensure that the defined USER instruction is valid, it must conform to the following conditions: The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries. Click Create. This creates the component and takes you to the Overview page of the component. You have successfully created a service from a Dockerfile. Next, you can build and deploy the service. Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the service. To build the service, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. You can access the following scans under Build. Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail. Info If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment. To deploy the service, follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active. Once you have successfully deployed your service, navigate to the component overview page and copy the UDP service address. You must provide that address when setting up the client application later in this guide. You have successfully deployed the UDP server. Currently, the UDP service is only accessible by the components deployed within the same project. Now let's use a UDP client to invoke the UDP service that you created above. To do this, you can create a manual trigger component as the UDP client. This is the recommended approach because, in this example, it's more efficient to have a client that connects to the server, sends a request, and then stops. Here, a continuously executing task isn't required. Furthermore, if you use a manual trigger component, you won't need to expose an endpoint in the client for invocation, unlike with an API. To create a manual task component, follow these steps: Enter a display name, a unique name, and a description for the component. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Click the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Under Connect Your Repository, enter the following information: Select Docker as the buildpack. Enter the following information: Click Create. This creates the component and takes you to the Overview page of the component. To build the component, follow these steps: On the Build page, click Build Latest. Note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. The client application, in this case, the UDP client, requires the server URL of the UDP server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application: Specify the following name and value to configure the environment variable for the client application: Click Add and then click Next. To execute the UDP client, follow these steps: For details on what you can monitor via the execute page, see Monitor executions. Explore how to create, deploy, manage, and observe service components in Choreo. A service component in Choreo lets you deploy and expose REST, GraphQL, gRPC, UDP, or TCP services. It is a fundamental building block for creating cloud-native applications in Choreo. They provide a simple and effective way to expose functionality as a service to other components within Choreo or to the outside world. Service components encapsulate business logic and provide standardized interfaces, called endpoints, for communicating with other components or systems. You can deploy and scale services independently, which makes them highly flexible and adaptable to changing workloads. With the help of the service component, developers can quickly create APIs and microservices, making it easier to implement and manage complex software systems. Service components can also be integrated with other Choreo components, that acts as message processors, connectors, and data sources, etc to create powerful end-to-end solutions. Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way. Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint. The method of defining endpoints depends on the buildpack. For buildpacks other than When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the See Understanding the endpoints.yaml file to learn about the When you create a service component with the Note Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an See Understanding the endpoints.yaml file to learn about the The File location: Note For components built with Ballerina buildpack For components built with WSO2 MI buildpack File content: The Beta release The Inbound configurations: This configuration section is for you to define inbound connections, Similar to Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace. Note The In the In the The Note Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value. File location: Note File content: Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design. Note This feature is not available for gRPC, UDP, and TCP endpoints. If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including: Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features. The default URL of a component corresponds to the default endpoint of the component and is structured as follows: This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows: If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint. To change the default endpoint of a component, follow the steps given below: Note A web application is an application program hosted on a server and serves ingress traffic through a browser. In Choreo, you can deploy a web application by creating a Web Application component and connecting it to a Git repository that contains the implementation of the web application. Web applications can fall into one of the following categories: You can create a web application in Choreo as follows: Build and deploy a SPA from the source code. Once you create the Web Application component, Choreo automatically generates a build pipeline for your single-page application and deploys it. Bring your Dockerfile. This approach is recommended if you are deploying a web server and not just a single-page application (or a single-page application with a complex build process). Host static websites. Now let's take a look at how you can build and deploy a SPA from source code: Follow the steps below to create a sample Web Application component and deploy it in Choreo: To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Select React as the Buildpack. Enter the following information: Tip Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks. To learn how to set up authentication for your web application with Choreo's managed authentication, see Secure Web Applications with Managed Authentication. Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component. You have successfully created a Web Application component from the source code. Now let's build and deploy the web application. To build the web application, follow the steps given below: Select the latest commit and click Build. This triggers the build process and displays the progress in the Build Logs pane. You can access the following scans in the Build Logs pane: Info If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment. Note The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with its status. Here, you will see the build status as Success. Keep the default settings and click Deploy. Note To verify that you have successfully hosted the web application, click the Web App URL in the Development card. This takes you to the web application. Info This feature is only available on the Choreo cloud data plane. When you promote your component to the Production environment, you have the option to create a personalized short URL for your web application. The URL follows the To create a short URL for your web application, follow the steps given below: Specify a Short URL prefix of your choice and click Save. Note Short URL names/prefixes are subject to availability, provided on a first-come-first-serve basis. For web applications with a backend server, Choreo allows you to mount runtime configurations and secrets as environment variables and/or file mounts for a specific environment. Alternatively, you can also inject them into the client application during server-side rendering or when serving static content. However, in the case of SPAs that run completely on the browser, Choreo does not support baking-in environment variables or other configurations. This is because Choreo follows a multi-environment deployment model, where configuration should be kept separate from the build and injected at runtime. For example, in most React SPA frameworks, the To manage runtime configurations, Choreo recommends the following approach (although this is a React example, the approach is generally applicable to other SPA frameworks as well). Note Follow the steps given below to manage runtime configurations for the React application you created above: Create and commit a new file named In your React component, you can access the configuration variables by referencing the When you deploy your component to Choreo, create a config file mount in the specified path for each environment (where your The following limitations are specific to the Choreo cloud data plane: I’m seeing a blank page or a 502 error after I deploy my web application If you encounter a blank page or a 502 error after deploying your web application, it typically indicates that the wrong directory is being served. To resolve this issue, follow these steps: By verifying and correcting the output directory alignment, you should be able to address the issue of encountering a blank page or experiencing a 502 error on deploying your web application. Choreo’s managed authentication capability exposes a set of backend for frontend (BFF) endpoints, facilitating authentication and authorization for web applications. These endpoints are readily available for single-page web applications deployed on Choreo. As a web application developer, there may be instances where it becomes necessary to run the application on your personal workstation. In such situations, the expectation is for authentication and authorization during local development to work in the same manner as it would when the application is deployed to Choreo, eliminating the need to modify the source code. Choreo's local development capability ensures a seamless local application development experience where the authentication and authorization process aligns with Choreo’s deployment environment. This facilitates a smoother transition from development to deployment, improving workflow efficiency. Local development uses a proxy that sits in front of the locally running web application. This proxy intercepts all incoming requests. The requests to Promote and deploy the application to the environment where you want to enable local development. Note Now you have done the necessary configurations to set up local development. The next section walks you through the steps to access your web application so that you can develop it locally. You can either use the Choreo built-in identity provider or external identity provider to access your web application locally. To access the application and proceed to develop it, go to the URL given under Step 2 in the Local Development pane. Note The local development proxy runs on HTTPS using a self-signed certificate. Your browser may warn that the certificate is not valid. Accept the risk and proceed. To access the application and proceed to develop it, go to the URL given under Step 3 in the Local Development pane. Note The local development proxy runs on HTTPS using a self-signed certificate. Your browser may warn that the certificate is not valid. Accept the risk and proceed. Choreo allows you to create and manage dedicated deployment tracks for components, facilitating independent version control and deployment. This capability also allows you to unlink deployment tracks from associated branches or relink them to different branches so that you can align with your preferred Git workflows, such as the feature branch workflow or GitFlow workflow. Info Deployment track creation and management does not apply to API Proxy and BYOI components. Prerequisites: Follow the steps below to create a deployment track for a component: If you want to detach a branch reference from a deployment track, you must unlink the branch. Info When you unlink the branch of a deployment track, the active deployments are unaffected. However, while you can redeploy the existing deployment, you cannot perform a new deployment. Follow the steps below to unlink a deployment track of a component: To associate a branch reference to an unlinked deployment track, you must link a branch. Info To build and deploy the contents of the linked branch, you must perform a manual build and deploy. Prerequisites: Follow the steps below to link a branch to an unlinked deployment track: To switch the branch reference of a linked deployment track, you must relink to an appropriate branch. Info If you unlink the existing branch of a deployment track and link a different branch, you must perform a manual build and deploy to build and deploy the contents of the recently linked branch. Prerequisites: Follow the steps below to switch the branch reference of a linked deployment track: Now that you understand how to create and manage deployment tracks for components, let’s explore a sample scenario to see how a developer can use deployment tracks to manage version releases in Choreo. Let’s consider the following version release scenario: Following are the actions you need to take from a deployment track perspective to manage the version release: Tip If you no longer need a deployment track, you can delete it. Note If the component exposes an endpoint or proxy and you want to delete the last version in the major version range, the recommended approach is to retire that version first. This allows consumers to transition to the next major version and prevents a sudden break in their experience.
-For example, if you have deployment tracks for v1.0 and v2.0, notify consumers to switch to v2.0 before deleting v1.0. Then, retire the APIs in v1.0 and proceed to delete the associated deployment track. Prerequisites: Follow the steps below to delete a deployment track: Choreo allows you to use a preferred WSO2 Micro Integrator (MI) runtime version in your integration project. Currently, Choreo supports MI product versions 4.1.0 and 4.2.0. You have the flexibility to deploy WSO2 updates within these specified versions. When you create an integration project, you can specify a required runtime version to gain control over the environment in which your integration runs. This version management capability empowers you to tailor your projects depending on your runtime requirements, enhancing the customization and adaptability of your integration workflows. WSO2 Micro Integrator (MI) utilizes a versioning system consisting of three-digit numbers, such as In Choreo, the MI runtime version is structured as a four-digit number, for example, If you are using WSO2 Integration Studio to build and deploy integration artifacts in WSO2 Micro Integrator, you can create multiple runtime environments and execute projects on any selected environment. WSO2 Integration Studio also allows you to configure multiple Micro Integrator runtime environments, offering flexibility and customization in the execution of integration processes. You can specify the Runtime version when you create an integration project in WSO2 Integration Studio. In the project creation wizard, specify the runtime version in the Runtime version field, as shown below.
- An integration project is structured as a Maven project with multiple sub-modules. The root You can establish multiple runtime environments by utilizing updated MI instances. With a valid WSO2 subscription, you can also access and download updates to set up an updated MI server locally. This update process allows you to select a preferred update level as the runtime version. Consequently, you can run your integration on a runtime with the latest updates, ensuring optimal performance and access to new features. If you are using WSO2 Integration Studio, follow these steps to set up a remote server instance with a Micro Integrator runtime environment to execute your integration project: Note If you have not downloaded and installed WSO2 Integration Studio, you can follow the installation instructions in the WSO2 API Manager documentation. Enter the WSO2 Micro Integrator Management API URL in the Server URL field and click Test Connection. Note The Management API of WSO2 Micro Integrator is an internal REST API introduced to substitute MI admin services. The default HTTPS port of the Management API of WSO2 Micro Integrator is Click Finish. Your integration project is now running in a remote server instance with the Micro Integrator runtime environment you require.
-If you need to make changes to the integration project, expand the remote server instance, right-click on the deployed exporter project, and select Redeploy to apply the changes. You can use the following convention to indicate the required MI runtime version in your integration project: Choreo utilizes Alpine images for configuring and deploying the Micro Integrator runtime. This includes automated configuration of the JRE/JDK, customized to the compatibility of the chosen runtime version, simplifying the setup procedure. Changing the runtime version in an integration project may become necessary during product version upgrades or when you want to apply updates. To change the runtime version of a MI Integration, follow the below steps. To change the runtime version in the integration project, follow the steps below:
-1. Open the project in Integration Studio.
-2. Right-click on the project and select Change Runtime MI Version.
- To test the changes locally, you must download and set up the runtime environment locally. Then, you must configure the Integration Studio runtime environment by directing it to the locally installed MI runtime. Once the setup is complete, you can deploy your integrations on the MI runtime environment and proceed to the testing phase. After completing the tests to ensure everything works as expected, you can follow below steps to deploy the project in Choreo: You will see the runtime version in the logs as shown below:
- Next, you must conduct additional testing in the development environment on Choreo before you promote the integration to production environments. The following error codes can help you troubleshoot errors that occur during the integration component build: Connections in Choreo allow you to integrate Choreo components, or to integrate Choreo components to external services or resources. Connections provide a simple and uniform way to integrate with services and resources. To consume a service deployed on Choreo within your service, you must create a connection to the service you want to consume. To create a connection, follow the steps given below: In the Choreo Console, go to the top navigation menu and set the visibility level as project or component as follows: From the left navigation menu, click Dependencies and then Connections. This page will list the currently available connections. For step-by-step instructions on how to use a connection in your service, see Use a Connection in Your Service. For step-by-step instructions on how to use a connection in your web application, see Use a Connection in Your Web Application. Choreo allows you to share and reuse your services, accelerating development and enhancing efficiency in building integrated applications through connections. For step-by-step on instruction on creating a connection, see Create a Connection. To learn more about Choreo Connections, see the documentation on Connections. You can consume a Choreo-deployed service within another service. Consuming connections from within Choreo services is seamless and straightforward. Follow the steps below to consume a Choreo service: To integrate another service into your application, follow the steps below: Copy and paste the snippet from the in-line developer guide into the The following is a sample snippet: Replace Upon deploying the component, Choreo automatically creates a subscription if applicable and populates the specified environment variables with actual values. The following table provides details on the configuration keys associated with the connection: Once you add the connection configuration snippet, you can proceed to read those configurations within your application. The steps to follow depend on the programming language you are using. The following is a sample code snippet in NodeJS: To consume a Choreo service with the visibility level set to organization or public and secured by the OAuth 2.0 security scheme, you must obtain an OAuth 2.0 token from the token endpoint. Subsequently, you can use the token to invoke the service. For languages with OAuth 2.0-aware HTTP clients, you must pass the OAuth 2.0-related configurations such as client id, client secret and so on, obtained when creating the connection to your HTTP client configuration. The HTTP client autonomously manages token retrieval and refreshing. For languages without OAuth 2.0-aware HTTP clients, you must manually initiate a call to the token endpoint. This includes fetching the token and managing token expiration and refresh directly within your application code. The following is a sample curl command to obtain a token: You can invoke the service as follows: For languages with OAuth 2.0-aware HTTP clients, you can invoke the service in a straightforward manner. The HTTP client seamlessly manages OAuth 2.0 authentication without requiring additional intervention. As the service URL you can use the URL that you resolved in step 2. For sample requests and responses, see the API definition provided via the Choreo marketplace for the service. For languages without OAuth 2.0-aware HTTP clients, you can use the token obtained in step 3 to make calls to the dependent service. Subsequently, add the obtained token to the HTTP authorization header with the bearer prefix.
-As the service URL you can use the URL that you resolved in step 2. For sample requests and responses, see the API definition of the service provided via the Choreo marketplace. The following is a sample code snippet in NodeJS: Note If you want to consume a Choreo service at the project visibility level, you don't need to obtain a token. You can directly invoke the service using the resolved URL. Choreo simplifies the process of integrating services into your web application. The approach to connect to a service can vary based on your web application. To connect to a selected service, follow the step-by-step instructions given below depending on the authentication mechanism used in your web application. Choreo-managed authentication allows you to seamlessly handle authentication for your web application. You can configure your web application to work with the built-in identity provider of Choreo or any external identity provider that supports OIDC/OAuth2.0 Note Choreo's managed authentication is currently available only for web applications created with React, Angular, or Vue.js buildpacks. Follow the steps below to use an existing connection within your web application: To integrate a service into your application, you must first add the connection configuration as follows: For single page applications (SPAs), you must add the connection configuration as a file mount. You can mount a file via the Configurations pane on the Deploy page. You must mount a file (for example, The following is a sample configuration: To ensure accessibility of the Note If you use an external IdP, you must add the IdP's configuration to the same file. For more information on working with IdPs, see Configure Asgardeo as an External Identity Provider. Once you add the connection configuration, you can proceed to read the configuration from your application. The steps to read depend on the programming language you use. The following is a sample code snippet in NodeJS: If you use Choreo-managed authentication, Choreo handles the security handshaking for the application during deployment. The connected service will be accessible under the same domain as your application. Therefore, you can call the configured path directly using your preferred HTTP client. The following is a sample code snippet in NodeJS: Note If you are using an external IdP provider instead of Choreo-managed authentication, you must obtain an access token from your IdP and add it to the HTTP authorization header with the bearer prefix. If you are not using Choreo-managed authentication or your web application lacks authentication, follow the steps below to connect to a service from your web application: For single-page applications (SPAs), you must add the connection configuration as a file mount. You can mount a file via the Configurations pane on the Deploy page. You must mount a file (for example, The following is a sample configuration: For other types of web applications, you must add the respective configuration into your application. Once you have added the connection configuration, you can proceed to read the configuration from your application. The steps to read depend on the programming language you use. The following is a sample code snippet in NodeJS: For languages with OAuth 2.0-aware HTTP clients, you must pass the OAuth 2.0-related configurations such as client id, client secret and so on, obtained when creating the connection to your HTTP client configuration. The HTTP client autonomously manages token retrieval and refreshing. For languages without OAuth 2.0-aware HTTP clients, you must manually initiate a call to the token endpoint. This includes fetching the token and managing token expiration and refresh directly within your application code. The following is a sample curl command to obtain a token: You can invoke the service as follows: For languages with OAuth 2.0-aware HTTP clients, you can invoke the service in a straightforward manner. The HTTP client seamlessly manages OAuth 2.0 authentication without requiring additional intervention. As the service URL you can use the URL that you resolved in step 2 above. For sample requests and responses, see the API definition provided via the Choreo marketplace for the service. For languages without OAuth 2.0-aware HTTP clients, you can use the token obtained in step 3 above to make calls to the dependent service. Subsequently, add the obtained token to the HTTP authorization header with the bearer prefix. As the service URL you can use the URL that you resolved in step 2 above. For sample requests and responses, see the API definition of the service provided via the Choreo marketplace. The following is a sample code snippet in NodeJS: WSO2 Micro Integrator (WSO2 MI) is a lightweight, high-performance integration runtime. It allows you to run integrations developed using WSO2 Integration Studio within Choreo. The topics on this page walk you through the key aspects you need to understand to use the WSO2 MI runtime effectively in Choreo. Choreo supports the following WSO2 MI integrations that cater to different use cases and requirements. Each integration type serves a specific purpose. Therefore, it is essential to understand their differences to easily choose the most appropriate integration for your use case. WSO2 Integration Studio is a powerful, Eclipse-based graphical development environment that enables you to build and deploy integration artifacts in WSO2 Micro Integrator. This comprehensive IDE offers a robust set of tools for designing and testing integration flows and crafting integration artifacts. By utilizing the visual, drag-and-drop capabilities of WSO2 Integration Studio, developers can significantly reduce the time and effort needed to construct and deploy integration flows. In addition to streamlining the development process, Integration Studio offers features such as debugging, testing, and version control to ensure the quality and reliability of integration flows. By creating an Integration project and Composite Exporter project in WSO2 Integration Studio, developers can export their integration projects as a single deployment artifact, known as a composite application. This composite application encompasses all the components and configurations necessary for deploying the integration project to WSO2 Micro Integrator. The Composite Exporter project simplifies the deployment process by allowing developers to package their integration projects as a single, self-contained artifact that can be easily deployed and managed. This approach enhances the consistency and reliability of integration projects while streamlining the overall deployment process. To start developing integrations with WSO2 Integration Studio, see WSO2 API Manager Documentation - Developing Integration Solutions. An Integration Project in WSO2 Integration Studio is a multi-module Maven project that can contain multiple modules with WSO2 Synapse configurations and a composite application module to export all the configurations as a single deployable artifact. An integration project directory structure includes the following key components: Optionally, you can include the following components in your integration project: Understanding the Integration Project directory structure is crucial for organizing your project and ensuring that all necessary components are included in the final deployable artifact. OpenAPI Support plays a crucial role in enhancing the functionality of integrations exposed as APIs. By providing an OpenAPI definition for your exposed integration, you can streamline testing and management processes, ensuring a more efficient and user-friendly experience. Choreo will automatically generate an OpenAPI definition for you based on your integration project, if you don't provide one, saving you time and effort. To incorporate OpenAPI support, store the OpenAPI definition file within the repository hosting your Integration Studio project. When creating the project, simply point to the file's location in the repository. If needed, you can change the location of the OpenAPI definition file later via the deploy page. By leveraging OpenAPI Support, you can optimize the way you test and manage your integrations, resulting in a more efficient development process and a smoother user experience. The use of third-party libraries in your Micro Integrator project can offer several advantages, such as enhanced functionality, improved integration capabilities, optimized performance, and reduced development time. Here are some of the benefits of adding third-party JARs to the Micro Integrator: To incorporate third-party libraries into your Micro Integrator project, create a new directory called In addition to The feature enables Choreo MI users to import certificates into the MI Before importing the certificate, it is necessary to obtain the certificate file, which can be in PEM or DER format. You
-can get the certificate from the server or service provider or export it from a web browser. Certificates should be
-added to the Specify the following values as mount configurations: Click Upload File and attach the certificate. MI Secure Vault is a feature that allows users to securely store sensitive data, such as passwords and tokens, and
-provide access to that data to MI Integrations. This feature provides an added layer of security to your integrations by
-reducing the risk of accidental exposure of sensitive data. To use MI Secure Vault to work with sensitive data, follow these steps: Specify the following values as configurations: Select Mark as a Secret. You can refer to the Accessing secrets
-section of MI Secure Vault documentation for more information on these features. By using MI
-Secure Vault to store and access sensitive data in your integrations, you can ensure that your integrations
-remain secure and protect sensitive data from unauthorized access. Scanning third-party libraries for security vulnerabilities is essential for identifying potential weaknesses in an application that could be exploited by attackers. Taking a proactive approach to security helps organizations detect and mitigate risks before they can be exploited, preventing data breaches, system compromises, and other security incidents. Choreo incorporates a security vulnerability scanning process during deployment. It uses Trivy to scan and detect critical vulnerabilities in third-party libraries added to the integration component. If the scan uncovers any critical vulnerabilities, the deployment process is halted. The deployment pane displays the Trivy scan status and any security failures in the Library (Trivy) vulnerable scan step, which can be accessed by clicking on it. Once the vulnerability has been addressed, you can redeploy the component. Customizing WSO2 Micro Integrator Preconfigured Settings is essential for ensuring that the integration solution works optimally within the specific context of your organization. While WSO2 MI comes with preconfigured settings designed for general use, these settings may not be suitable for every organization's unique requirements. Customizing these settings can help optimize performance and ensure compatibility with your organization's systems and applications. To customize the preconfigured settings of WSO2 MI instances running on Choreo, define a Note If you change critical configuration parameters such as port offset and hostname, it can break internal communication.
-Therefore, the recommended approach is to update only the necessary configuration parameters. Given below is a sample Using environment variables is a recommended practice when developing integration artifacts with WSO2 Integration Studio, as it improves configuration management, security, portability, and manageability. By leveraging environment variables, organizations can streamline the management and maintenance of their integrations, ensuring that updates can be implemented quickly and efficiently. The component's Deploy page provides a user-friendly interface to manage environment variables across different environments. For information on managing environment variables for complex use cases, see Configurations and secrets. Environment variables offer several benefits: For a comprehensive list of parameters that can be configured as environment variables, see WSO2 API Manager Documentation - Injecting Parameters - Supported parameters. Configuring logging is crucial when developing and maintaining a software system, as it can significantly improve efficiency during the development, testing, and maintenance phases of the software development process. Logging captures events and messages that occur during an application's execution, providing valuable insights for troubleshooting and debugging issues. With Micro Integrator instances, you can configure and customize logging according to your requirements. Logging configurations can be added to each MI instance's environment, allowing you to fine-tune logging depending on the specific environment or deployment scenario. To configure logging in MI instances, follow the steps given below: Tip You can use environment variables with specific naming conventions. Set the variable value to the required logging level for the corresponding package or class. For example, to enable wire logs, change the logging level of the To configure logging, set the environment variable as follows: Specify the following values as mount configurations: Click Create. WSO2 Micro Integrator (MI) Connectors are prebuilt connectors designed to simplify integration between WSO2 MI and various other systems. They enable seamless connections to databases, message brokers, REST APIs, and more, allowing you to perform actions such as sending messages, executing queries, or retrieving data. These connectors are easy to use, making it straightforward to incorporate them into your WSO2 MI integration flows. Micro Integrator connectors are versatile and can be utilized in various integration scenarios, including data integration, service-oriented architecture (SOA) integration, and event-driven architecture (EDA) integration. WSO2 Integration Studio is a comprehensive development environment that facilitates the creation of integration flows using WSO2 Micro Integrator Connectors. With Integration Studio, you can design and implement integration flows that connect diverse systems and execute various actions, such as sending messages, executing queries, or retrieving data. You can build integration flows using either prebuilt connectors provided by WSO2 MI or custom connectors developed using the Connector Development Toolkit. Integration Studio offers a graphical user interface that simplifies the process of building and testing integration flows while also providing a set of tools for managing and deploying these flows in a WSO2 MI runtime environment. For more information, see the following topics in the WSO2 API Manager documentation. WSO2 MI buildpack is where you can deploy integrations developed with WSO2 Micro Integrator as an API. In this preset, you have three different ways to define endpoints. Choreo gives priory to the definition of endpoints in the below-mentioned order. Using endpoints.yaml file
-This is the most flexible method to define endpoints. You can configure the endpoint details with the See Understanding the endpoints.yaml file to learn about the Auto generating endpoints
-If Provide default endpoints
-If For a hands-on experience with MI-based integrations in Choreo, we recommend exploring our samples in Choreo Console. You can filter out the samples based on the buildpack Fork the Repository: Start by forking the repository to your account. Explore & run: Navigate through the different integration scenarios. Each example has a README.md with setup and execution instructions. Choreo allows you to automatically scale your component replicas up or down in number based on resource consumption to ensure high availability. Note Autoscaling capabilities are only available in paid plans for private data plane organizations.
-In the free tier, components run in a single-replica, low-availability mode. The following parameters allow you to scale component replicas: Tip If you update a scaling parameter, it may not immediately reflect in the Choreo Console because the change can take some time to propagate. Run a fixed number of replicas If you want to run exactly Scale to zero Choreo provides the scale-to-zero capability for HTTP applications you deploy in the data plane. This lets you run your components in a serverless mode. Scale to zero is very useful in lower environments, where you can significantly reduce infrastructure costs by scaling down idle workloads. In production environments, you can also use scale-to-zero capability if your application's behavior aligns with this feature behavior. In the paid tier, if you want to run your application with more guaranteed high availability, it is recommended to choose HPA (Horizontal Pod Autoscaler) scaling method and configure a minimum replica count of 2 or higher. Info For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default. When Scale to Zero is enabled, your apps will automatically scale down to zero unless they receive HTTP traffic. When the application receives an HTTP request, your workload quickly scales up from zero to handle the request. When a new request is received by the deployment, the deployment will scale up to one replica and serve the request. When the deployment remains idle for a set period (approximately 5 minutes), it will automatically scale back to zero until a new request is received. When Scale to Zero is enabled, you can set the maximum number of replicas for deployments with this capability. Choreo dynamically scales deployments up to meet high HTTP traffic demand, up to the specified number of replicas. If the pending requests surpass the defined threshold under Number of pending requests to spawn a new pod, Choreo automatically adds a new replica to handle the increased load. For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default. When deploying or promoting the component, the deployment will automatically scale-to-zero.
-Upon the next request to the deployed service, a replica will be created to serve the request. Note To enable scale-to-zero for service components created before February 23, 2024, follow the steps given below: In the left navigation menu, click DevOps and then click Scaling. If you are a free user, you will see a view similar to the one below. You can click the scale-to-zero card to enable scale-to-zero for your component. If you are a paid user or you are running your applications in your own private data plane, you will see a view similar to the one below. You can click the scale-to-zero card to enable scale-to-zero for your component. Note The scale-to-zero service should start within 60 seconds. If it doesn’t, the gateway will timeout the request. You can independently scale Choreo components in both the Development and Production environments. The deployment card indicates the scaling status of each environment. To configure the scale-to-zero feature for a specific environment, click on the scale-to-zero link, which redirects to the Devops → Scaling page. When you turn on the scale-to-zero for your application, the minimum replicas for your app will be set to zero. However, you can still select an appropriate maximum number of replicas. Scheduled tasks and manually triggered components cannot connect to a service on a project scope if scale-to-zero is enabled. Attempting to do so results in the following error: To allow a task-type component to invoke a project-level service, set it to HPA mode if you are on a paid plan, or to no scaling if you are on the Developer plan. When your Choreo application scales down to zero, an intermediary proxy service intercepts incoming requests. If a request is directed at your application, this service initiates a scale-up. Requests are held in the proxy's queue until your application becomes active. After scaling up, the proxy forwards the queued requests to your application. If your application remains without HTTP traffic for an extended period (default idle time is 5 minutes), it will be scaled down to zero until more HTTP requests arrive. Conversely, if there's a surge in HTTP traffic to your scaled-up application, Choreo will further increase its scale to manage the demand. Choreo considers adding additional replicas if the number of queued requests surpasses the 'Target Pending Requests' threshold, which is set to 100 by default. You can adjust this threshold in the user interface. Note The initial request after a long period of inactivity experiences a delay because the application must first scale up from zero. If your API operates in a service-chain sequence (e.g., service-1 activates service-2, which in turn calls service-3), this waiting time may extend further. If your application or its chain takes a considerable time to scale up, be aware that the first request might face a timeout. When Choreo enables scale-to-zero by default, it will configure the readiness probe with some default values. However, in some cases, you may observe that your first request responds with a 503 status code. To overcome these behaviors, fine-tune the readiness probe in the DevOps → Health Checks view to match your application's needs. In Choreo, you can view detailed information about the container that comprises a component, such as its image tag, the corresponding commit ID, any imposed resource usage limits, and so on. Each component in Choreo is limited to a single main container. Resource Limits Resource limits ensure that a single component does not take up more resources than it requires, which can affect other workloads on the data plane. If a process exceeds the allocated memory limit, the corresponding container will be forcefully shut down and restarted. If the process exceeds the allocated CPU limit, it gets throttled and can result in significant latencies in compute and I/O operations. Choreo allows you to edit the default container configuration depending on your requirement. Follow these steps to update container configurations: Apply the necessary changes and click Save. The following topics walk you through the container configuration changes you can apply. Note The capability to update resource requests and limits is only available in paid pricing plans. To update resource requests and limits, move the corresponding slider to a required position. A resource request cannot be less than its corresponding limit. You can select one of the following options as the image pull policy. If Not Present - The image is pulled from the container registry only if a matching image is not present in the data plane. Tip The recommended option is If Not Present. You can specify appropriate values for the Container Port and Service Port. The Service Port is the port exposed outside of the container to your project-scoped endpoint. If you do not know the value to specify as the Service Port, specify the Container Port value in both fields. Tip You do not need to configure port values manually for Ballerina components. The capability to edit port values is primarily for containerized/Dockerfile-based components. You can also select an appropriate Protocol. You can define a command and arguments for a container when you want to provide or override the When you define a command and arguments, The All components you create in Choreo have a default read-only file system, which you cannot access or write to from your applications. Volume mounts allow you to create either temporary or persisted writable file system storage locations for your applications. Tip All components have a writable location in the Empty directory (in-memory or on-disk) mounts allow you to create temporary file systems that your application can read from and write to. This option provides a convenient way to create a scratch space to write files temporarily before storing them in a more permanent storage location such as a cloud-backed storage bucket.
-For example, unzipping a file, temporarily writing results from a memory-intensive operation to disk, a temporary local cache, etc.
-However, it is important to note that these volumes destroy when you restart or update a container because the volumes are attached to the lifetime of a container. Follow these steps to create a temporary storage space for your container: Click Next. In-memory (tmpfs) storage uses up container memory Storage capacity for this type of volume will count against the container's memory limit. To add a mount location, specify a Mount Path and click Add mount. Tip Click Create. This applies the volume mount immediately to your container and triggers a rolling restart. Follow these steps to create a persistent storage space for your container: Note Persistent volume options are only available in private data plane organizations. Select an appropriate Access Mode. Check and specify an access mode supported by the storage class Click Next. To add a mount location, specify a Mount Path and click Add mount. Tip Click Create. This applies the volume immediately to your container. Secure access to private networks from the Choreo cloud data plane is an essential use case for cloud data plane users. Choreo allows this secure connection using Tailscale. For this, Choreo provides a prebuilt Tailscale image component that can act as a forward proxy, which you can deploy in your Choreo project as a service. This service allows you to forward traffic to your external networks via Tailscale’s peer-to-peer WireGuard network. The following diagram illustrates the high-level deployment architecture of the Tailscale pre-installed forward proxy: Let's take a look at the specifics of each part to understand the deployment architecture. Choreo project In Choreo, a project groups various components. For more information on what a project in Choreo is, see the documentation on Project. Tailscale proxy This acts as the Tailscale pre-installed forward proxy, facilitating secure peer-to-peer WireGuard connections from the Choreo cloud data plane to private networks. It includes a Tailscale Daemon, SOCKS5 proxy, and a configurable TCP forwarder. Tailscale daemon This is the core component of Tailscale. It is a software service that provides secure network connectivity and private networking solutions. For more details see the Tailscale documentation. SOCKS5 proxy This uses Tailscale’s userspace networking mode, rather than the kernel mode. Therefore, the inbuilt SOCKS5 proxy handles the forwarded traffic and directs it through the Tailscale network. TCP forwarder Forwards inbound TCP (transmission control protocol) traffic from the Tailscale proxy container’s network interface to the SOCKS5 proxy, ensuring it reaches its destination via the secured WireGuard tunnel. User applications and the Choreo API gateway User applications within the same namespace (project) can use the Kubernetes service created to front the Tailscale proxy, for connecting to the corresponding private endpoints. You can either expose this service within the organization via the internal API gateway or expose it to the public via the external API gateway. For more details, see the documentation on Choreo endpoints. Now that you understand the deployment architecture, let’s explore how you can use Tailscale to secure connections to your private networks. This section walks you through the steps to create, configure, deploy, and use the Tailscale proxy component. Let's get started. If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the organization home page. Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Info In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and takes you to the project home page. Enter a display name, component name, and a description for the service. For this guide, let's enter the following values: Click the Container Registry tab. Now you have successfully created the Tailscale proxy. You can proceed to configure and deploy it. Here, you will add the required volume mounts, set the Tailscale authentication key, configure the TCP forwarder, configure endpoints, and deploy the Tailscale proxy. Follow the steps given below: Tailscale requires the following volume mounts for its operations: To create the volume mounts, follow the step-by-step instructions in Configure Storage. To configure and deploy the component, follow the steps given below: To mount a configuration file to the Tailscale proxy component and specify the port mapping for the TCP forward proxy running there, do the following: Specify the following in the sample configuration file:
- Note In this sample configuration, the TCP traffic arriving at port 8080 on your Tailscale proxy will be forwarded to port 8090 on the node with IP address 100.108.78.93 in your Tailscale network. Similarly, port 8081 will map to the corresponding address. You can find the IP addresses of your nodes on the Tailscale machines page in your Tailscale network's admin console or via the Tailscale clients running on your machine. Click Next. In the Endpoints pane that opens, click + Add and edit the Note The sample Click Save. Click Next and then click Deploy. Note Deploying the component may take a while. You can track the progress by observing the logs. Once the deployment is complete, the build status changes to Active on the Development environment card. When the component is deployed, you can observe a new node connected to your Tailscale network. To view this, go to the Tailscale machines page of your Tailscale coordination server. Now you have successfully deployed the Tailscale proxy in your project and it is connected to your Tailnet. You can proceed to use the Tailscale proxy to provision access for other components to securely access private network endpoints. You can configure endpoints of the Tailscale proxy to use it for various aspects within Choreo. Tailscale nodes have a default node key expiry time of 180 days. Nodes require re-authentication after key expiry to avoid connection losses and application downtime. There is an option to disable node key expiry if necessary. For more details, see Node key expiry documentation. Auth keys are used to register new nodes into your Tailscale network. The default expiry time for auth keys is 90 days, but nodes remain connected even after auth key expiry. This becomes an issue only if the Tailscale Proxy component is redeployed or restarted. If you want to add a new private endpoint to your network and access it via the same Tailscale proxy within Choreo, you must add a new port mapping entry in the port mapping configuration of your Tailscale proxy deployment. Since the Tailscale proxy acts as a forward proxy, it is important to configure health checks. You can use one of the open ports of the TCP forwarder as a health endpoint. For details on how to set up health probes in Choreo, see Set up health checks. You can use Tailscale ACLs to precisely manage permission for users and devices on your Tailnet. It is recommended to disable Scale-to-Zero for the Tailscale proxy because it acts as a forward proxy and should always be up and running to make consistent connections with the Tailscale VPN mesh.
-If you enable Scale-to-Zero, you may experience service downtime. To achieve high availability and resiliency for the Tailscale proxy, you must run multiple replicas with HPA. To configure multiple replicas for the Tailscale proxy component, go to the Scaling page under DevOps. For more details, see Autoscale component replicas Before deploying the Tailscale proxy in production environments, it is recommended to follow the Tailscale production best practices and security best practices. Note Choreo blocks incoming connections from other nodes in your Tailnet to the Tailscale proxy to prevent access to your project’s namespace in the Choreo cloud data plane. For assistance in resolving common Tailscale proxy issues, see Troubleshoot Tailscale proxy issues. Choreo allows you to easily manage and version your component's configurations and secrets as file mounts or environment variables. Note All configurations and secrets applied to a Choreo component are stored in an encrypted secret vault in the cloud data plane, which is managed by WSO2.
-If you are on a private data plane, the configurations and secrets are stored in an Azure key vault or AWS secret manager attached to your data plane in your cloud environment. Choreo considers all configurations and secrets to be sensitive content when storing them, but gives you the option to choose between secret or configuration when you create a file mount or an environment variable. Configurations can be read and updated via the Choreo Console after you create them. Note If you want to include sensitive data such as database passwords, cloud credentials, service accounts, and so on, the recommended approach is to use a secret instead of a configuration. Follow these steps to apply a file mount to a component you have created: If you want to create the file mount as a secret, select Mark as a Secret. Otherwise, proceed to the next step. Note If you create the file mount as a secret, you will not be able to read the file content after you create the file mount. In the Display Name field, specify a name for the file mount. Tip The display name does not affect the file mount or its content. It is only a reference to identify the configuration or secret you create. In the File Mount Path field, specify where to mount the file inside the container. Use an absolute file path with the file name and extension if applicable. Tip The file name in the mount path does not need to match the configuration name or the name of the file you upload. Upload a configuration file or copy and paste the configuration content into the editor. Click Create. Note Configurations and secrets are applied immediately to your environment on creation. To ensure that the container reflects the new content, your existing running replicas undergo a rolling restart. Follow these steps to apply environment variables to a component you have created: If you want to create the environment variable values as secrets, select Mark as a Secret. Otherwise, proceed to the next step. Note If you create environment variables as secrets, you will not be able to read the values you set for the environment variables after you create them. In the Display Name field, specify a name to identify the configuration or secret. Tip The display name you specify does not affect the environment variables you set. It is only a reference to identify the configuration or secret you create. Under Add Environment Variables, specify the necessary environment variables as key-value pairs. You can click Add Item to add any number of environment variables. Click Create. Follow these steps to update a configuration or secret you have defined: Follow these steps to delete a configuration or secret you have defined: Choreo manages the Ballerina configurables for the Ballerina components you create. When you deploy or promote a Ballerina application, you can modify the Ballerina configurables via the Deploy page. Tip You can use configurables instead of environment variables to add file mounts to a Ballerina component.
- Environment variables are primarily for components written in other languages. By default, all projects created in the cloud data planes (irrespective of the data plane region) are provisioned with two environments (i.e., development and production). The environments are listed in the order of deployment and promotion. The initial deployment takes place in the first environment and you can proceed to promote a component to subsequent environments. To create a new environment, follow the steps given below: On the Environments page, click Create and specify the following details to create a new environment: Data Plane - The data plane to create the new environment. Tip The Data Plane list displays all the private data planes registered under your organization. DNS Prefix: A DNS prefix to identify the exposed APIs in the environment. Here, the base domain depends on the custom domain attached to the API gateways provisioned on the selected data plane. Mark environment as a Production environment: Select if you want this environment to be a production environment. Tip In Choreo, you can have multiple non-production and production environments. To work in a production environment, you must have privileged permissions to access and deploy to production environments. The order in which environments are listed on the Environments page is the same order in which promotion takes place. To change the order of promotion across environments in an organization, follow the steps given below: On the Environments page, click and drag environment list items to rearrange the order of listed environments. Note Although changes to the order of promotion for environments are applied immediately, the change does not affect the components already running in environments. Only subsequent builds and promotions will follow the new order. To see the changes, go to the Deploy page of a component (in any project). To delete an environment, follow the steps given below: Warning Environment deletion is a permanent, non-reversible operation. Health checks ensure that a running container is always healthy and ready to serve traffic. Liveness probes run periodically on your container and restart if the probe fails.
-This allows the container to self-heal in scenarios where the application may have crashed or become unresponsive. Similar to liveness probes, readiness probes run periodically throughout the lifecycle of a container.
-However, unlike liveness probes, these probes do not restart the container if the probe fails. Instead, they stop the container from receiving network traffic. Readiness probes on single replicas You must be mindful when you configure readiness probes on a single-running replica. If the readiness probe fails, your application stops receiving traffic because there is only one active replica. The application may not recover unless the liveness probe fails and restarts the container. You can configure the following probe types for both readiness and liveness probes. This probe sends an HTTP Depending on your requirement, you can configure additional HTTP headers. The recommended approach is to create a This probe attempts to open a socket to the container on the specified port. If it cannot establish a TCP connection, it becomes a failure. This probe executes a given script inside the container. A non-zero return from the command is considered a failure. For example, Follow these steps to configure liveness and readiness probes on a container: Configure the liveness probe depending on your requirement. Click Save. Click Save. Note You can update or remove a probe at any time. Follow these steps to ensure that the container works as expected: In Choreo, you can view details about running replicas of a component in a specific environment (i.e., Development or Production). To view the runtime details of a component, follow the steps given below: The runtime details you can see here are analogous to a zoomed-in view of a specific environment on the Deploy page. The following topics walk you through the specific details you can view and actions you can perform via the Runtime page. On the Runtime page, you can click Redeploy Release to immediately redeploy all resources, including configurations and secrets, to a specific environment. This triggers a rolling update to sync all the latest changes to the data plane. What is a release? A release in Choreo uniquely identifies an underlying deployment of a component to an environment for a given version. For example, if you deploy a component to two environments across two versions, the component will have four active releases. The capability to redeploy a release also allows you to quickly restart all the running replicas of a component in a specific environment. The running instances you see on the Runtime page provide insights into the active replicas of your component in the selected environment. If you want to see the real-time logs and information on conditions and events of a replica, click the menu icon of the replica and then click Real-time Logs or Conditions & Events depending on what you need to view. These options provide insights that help to diagnose issues in deployments. Note Unlike the logs available in the Observability Metrics of a component, these logs are fetched in real-time from the data plane and are not historical. Therefore, you can only see logs of active containers and the last shutdown container. Conditions and events provide information necessary to troubleshoot failing deployments. If a component is not behaving as expected and you cannot detect any issues via the application logs, these events can provide necessary debugging information, such as the following: Any platform services you create within your Choreo Organization will be included in your current Choreo subscription. The quantity included will vary depending on the service plan of the resources you create. A few important considerations: Try out the free trial Choreo provides a 7 day free trial for all database types on the 'Hobbyist' service plan (for free tier users). Fully compatible with legacy Redis® OSS. Choreo-Managed Cache provides fully-managed in-memory NoSQL databases on AWS, Azure, GCP, and Digital Ocean and can be used as a cache, database, streaming engine, or message broker. Follow the steps below to create a Choreo-Managed Cache: To connect to your Choreo-Managed Cache, follow these guidelines: The high availability and the automatic backup retention periods for a Choreo-Managed Cache can vary as follows depending on the service plan you select. In general, service plans are recommended for production scenarios due to the following reasons: Minor failures: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once it automatically restarts the crashed process or when it restores the network access. Severe failures: Failures such as losing a node entirely in case of hardware or severe software problems, require more drastic recovery measures. The monitoring infrastructure automatically detects a failing node when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created. The number of simultaneous connections in a Choreo-Managed Cache depends on the total available memory on the server instances. You can use the following to estimate: Here, This number is estimated by the exact available memory so it can vary between different plans and cloud providers. To see the exact maximum connections allowed, use the * redis-cli and info command as follows: To maintain the stability and security of a managed environment, Choreo restricts certain commands on Choreo-Managed Cache services. Support for Lua scripts on Choreo-Managed Cache The following commands are disabled on Choreo: The following Choreo allows you to create PostgreSQL and MySQL databases as well as Choreo-Managed Cache instances on all major cloud providers (AWS, Azure, GCP, and DigitalOcean) as fully Choreo-managed platform services.
-These databases and caches can be seamlessly provisioned to offer persistence and caching capabilities for all your Choreo components. Choreo provides various service plans for each type, ranging from smaller instances for development purposes to production-grade databases with automatic backups and high-availability multi-nodes. PostgreSQL (also known as Postgres), is an open-source object-relational database management system. You can create PostgreSQL databases on Choreo as fully Choreo-managed, flexible SQL databases that are ideal for both structured and unstructured data. If you want to perform an efficient vector similarity search, you can create a PostgreSQL vector database. MySQL is a user-friendly, flexible, open-source relational database management system with a well-established history in the SQL database realm. Choreo allows you to swiftly create fully Choreo-managed MySQL databases, enabling rapid setup and utilization. A fully-managed cache compatible with legacy Redis® OSS. A versatile, in-memory NoSQL database that serves as a cache, database, streaming engine, and message broker. Choreo-managed Cache allows you to have fully-managed instances that can be swiftly provisioned and integrated into your applications within minutes.
- PostgreSQL, MySQL, and Redis® are trademarks and property of their respective owners. All product and service names used in this documentation are for identification purposes only.
- MySQL on Choreo offers fully managed, flexible relational databases on AWS, Azure, GCP, and Digital Ocean. Follow the steps below to create a Choreo-managed MySQL database: To connect to your Choreo-managed MySQL database, consider the following guidelines: The high availability characteristics and the automatic backup retention periods for Choreo-managed MySQL databases vary based on your service plan as explained below: In general, we recommend service plans for production scenarios for multiple reasons:
-- Provides another physical copy of the data in case of hardware, software, or network failures.
-- Typically reduces the data loss window in disaster scenarios.
-- Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running. Choreo runs full backups daily to automatically back up Choreo-managed MySQL databases and record binary logs continuously.
-Choreo encrypts all backups at rest. Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database. The maximum number of simultaneous connections to MySQL databases is fixed for each service plan and depends on how much RAM your service plan offers. Note An For plans under 4 GiB of RAM, the number of allowed connections is For plans with 4 GiB or more RAM, the number of allowed connections is PostgreSQL on Choreo offers fully Choreo-managed, efficient object-relational databases on AWS, Azure, GCP, and Digital Ocean. Additionally, Choreo allows you to create fully-managed PostgreSQL vector databases if you want to perform efficient vector similarity search. Follow the steps below to create a Choreo-managed PostgreSQL database: Follow the steps below to create a Choreo-managed PostgreSQL vector database: To connect to your Choreo-managed PostgreSQL database, consider the following guidelines: The high availability characteristics and the automatic backup retention periods for Choreo-managed PostgreSQL databases vary based on the selected service plan as shown below. Service plans with standby nodes are generally recommended for production scenarios for multiple reasons:
-- Provides another physical copy of the data in case of hardware, software, or network failures.
-- Typically reduces the data loss window in disaster scenarios.
-- Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running. Choreo runs full backups daily to automatically back up Choreo-managed PostgreSQL databases and copies the write-ahead logs (WAL) at 5-minute intervals or for every new file generated.
-Choreo encrypts all backups at rest. Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database. Minor failures: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once Choreo automatically restarts the crashed process or when Choreo restores the network access. Severe failures: To handle severe failures such as losing a node entirely in case of hardware or severe software problems, requires more drastic recovery measures. The monitoring infrastructure automatically detects a failing node, both when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created. The following connection limits apply to Choreo-managed PostgreSQL databases based on the selected service plan. This section explains how you can configure alerts for your API manager deployments. Setting up alerts allows you to proactively monitor your API ecosystem and take corrective measures when necessary. You can configure alerts for each environment within your organization. You can add, modify, or delete alerts per API. Optionally, you can specify a list of emails for each alert configuration. Alerts are subject to a suppression policy to prevent duplicate notifications within a specific time frame. By default, a 10-minute suppression window is applied, and this is not configurable. The suppression policy is specific to each alert configuration. Info Alerts can be categorized as either latency alerts or traffic alerts. Latency alerts notify you if the response latency of an API exceeds a predefined threshold. This is useful for APIs that need to meet specific SLAs and for proactively identifying slow APIs. To configure a new latency alert, follow the steps given below: Click Alert Configuration. This opens the Alert Configuration pane with the Latency tab open by default. In the API Name field, select the API for which you want to configure the alert. Info Only the APIs that you have invoked at least once are listed here. For other APIs, you need to give the API name in the required format as instructed in the UI. In the Metric field, select the required metric against which you want to evaluate the alert configuration. Tip The list includes all available options. If there are multiple metrics, you can select the required metric. If there is only one metric to choose, that metric is selected by default, and the field is disabled. In the Latency field, specify the threshold in milliseconds. Info When the 95th percentile of the selected metric exceeds the threshold provided here, alerts are triggered. In the Emails field, specify the list of emails that should be notified when the alert is added. Click + Add. Once an alert is successfully added, the alert configuration is listed in the Alert Configuration pane. Each configuration can be edited and removed via this pane. Traffic alerts notify you when the request count of an API exceeds a predefined threshold. This is useful for managing APIs with backend traffic limits or monetized backends that require proactive scaling based on incoming traffic. To configure a new traffic alert, follow the steps below: In the API Name field, select the API for which you want to configure the alert. Info Only the APIs that you have invoked at least once are listed here. For other APIs, you need to give the API name in the required format as instructed in the UI. In the Metric field, select the required metric against which you want to evaluate the alert configuration. Tip The list includes all available options. If there are multiple metrics, you can select the required metric. If there is only one metric to choose, that metric is selected by default, and the field is disabled. In the Threshold field, specify the threshold number of requests per minute. If required, specify the list of emails that should be notified when the alert is generated in the Emails field. Click Add. Once an alert is successfully added, the alert configuration is listed in the Alert Configuration pane. Each configuration can be edited and removed via this pane. You can view DORA metrics in Choreo to use as KPIs to measure your organization's DevOps team's performance. Choreo enables this feature by default for all organizations. DORA includes the following four key metrics that are regarded as the most important metrics to indicate team performance: Choreo enables two DORA metrics by default; deployment frequency and lead time for change. To configure the CIO dashboard by enabling the other two metrics, follow the steps below: To configure GitHub as the incident management system, follow the steps below: First, let's authorize Choreo to access the repositories used to record incidents. On the Add Integration page, select GitHub and click Authorize with GitHub. Once the authorization process is complete, you can start configuring the GitHub repository. By default, Choreo collects incident details(issues) from all repositories containing Choreo components. However, you can configure a GitHub account and a GitHub repository to allow Choreo to read issues from a specific repository, and then click Next. The filter label allows Choreo to scrape issues associated with that label. Incident Label: The label Choreo uses to identify incidents. For example, Invalid incident label(Optional): Choreo will not scrape issues with this label and will proceed to skip these issues. For example, Once you configure the labels, click Save. Choreo will enable incident data publishing in the background once you save. Once completed, DORA metric charts will appear in the CIO dashboard for Mean Time To Recover and Change Failure Rate. If there are any issues in the configuration, the configure banner will reappear, and the user can proceed to reconfigure. Choreo extracts deployment information from the relevant incident and generates DORA metrics that help you analyze the deployment statistics related to the incidents. Therefore, you must manually update the GitHub issue with the relevant deployment-related information. Follow the steps below to add the deployment information to the GitHub issue. On the right-hand side panel, select the relevant deployment, and click Release details to copy the deployment details to the clipboard. That's it! You have successfully configured your CIO dashboard to include the DORA metrics. Note The CIO Dashboard is expected to reflect the latest statistics within approximately 30 minutes. You can edit or override the configurations you made via the edit option in the dashboard. DORA metrics comprise four key metrics. Let's explore what each metric represents in Choreo. Choreo displays a summary and graphical representation of each metric. The snapshot view includes four tiles on the top of the dashboard, summarizing DORA metrics for the entire time period you select. The snapshot view categorizes each metric into four performance levels: elite, high, medium, and low. The categorization is based on the 2020 DORA metric report. The time series view provides a graphical representation of how the statistics have changed over a period of time. You can use this view to analyze team performance and identify trends. DORA team definition: The frequency at which an organization successfully releases to production. In Choreo, this translates to the number of times an organization deploys a component to the production environment. Choreo does not count the deployment done to the development or other lower environments. The snapshot view of the A lower deployment frequency indicates that your organizational efficiency is low and that you need to evaluate and improve the processes to encourage frequent releases. Choreo also displays the total number of deployments for the selected time range and the percentage increase or decrease compared to the previous time range. The time series view for the DORA team definition: The time it takes for a commit to reach production. In Choreo, this translates into the time between committing and promoting a deployment to production. Although this approach may overlook any commits you push to production between two commits, it effectively assesses the efficiency of the review, approval, and CI/CD processes. Therefore, focusing on the production commits is adequate. If a team commits locally for extended periods without deploying to production, this gets reflected in the The snapshot view of this metric displays the 95th percentile of the lead time for the selected time period. 95th percentile serves as a better representation as it filters out large outliers that can taint the average value. Lower lead times for change suggest that your organization has efficient processes for change review, approval, and CI/CD, while longer times suggest that the process needs to improve. Organizations can also use the categorization label to determine their standpoint on global standards. Additionally, Choreo also displays the percentage increase or decrease compared to the last time period. The time series view of this metric visualizes the lead time as a bar chart for the selected time period. The time is summed based on the ‘view by’ selector. To handle outliers, the y-axis employs a log scale that represents values read dynamically. Hovering over each bar displays the actual counts for the aggregated period.
-Using this chart, organizations can identify trends in their release process. For example, organizations can identify the time of the year when lead time rises, such as summer break. Also, organizations can use this to benchmark and evaluate new process changes. For example, if you introduced a process to include peer programming and reviewing, this chart can be used to evaluate its effect on the lead time and provide leadership with factual information to proceed further. The DORA team definition: The percentage of deployments causing a failure in production. In Choreo, this translates to the ratio of deployments causing production failures to the total number of deployments. If there is at least one incident reported against a deployment, Choreo considers that deployment as a failed deployment in production. Any deployment-time failures are not counted as production failures because such failures don't impact the end user. For this metric to be accurate, the organization is expected to open incidents adhering to the proper format as it is crucial for Choreo to identify production failures. The snapshot view of this metric visualizes the change failure rate as a percentage for the selected time period. This will be the absolute percentage for the entire time period. When deciding on the time, the time of deployment is considered instead of the incident reported time. For example, the change failure rate for January 2023 will reflect the following:
- - All deployments that happened within January.
- - Any incidents that were reported at any time (in or after January) against the January deployments. This view helps leadership assess the quality of deliverables and identify areas for improvement. Higher rates suggest that the organization needs to improve its processes to bring in more quality assurance aspects such as improved code coverage and end-to-end test coverage. Additionally, Choreo also shows the percentage increase or decrease compared to the previous time period. The time series view of this metric displays it as a line chart with data points corresponding to the granularity selected by the ‘view by’ selector. The absolute percentage is shown for each granularity. Hovering over the line chart displays the actual counts for the aggregated period.
-This chart helps leadership identify timely trends in product quality aspects. For example, this view displays the months of the year where the failure rate is high (for example, close to quarterly release/announcement dates). Also, you can use this to measure the effectiveness of changes introduced to improve quality. For example, if the organization introduced an end-to-end test pipeline integration to the PR approval process, they can use this view to factually observe the timely impact of that change and determine how it decreases the failure rate. The DORA team definition: The time it takes for an organization to recover from a production failure. In Choreo, this measures the time from identifying a production incident to resolving it. This metric reflects the responsiveness and agility of incident management teams. Choreo depends on the open and close times of incidents to gather the relevant information. Therefore, for the dashboards to be accurate, organizations must follow process guidelines to update and close incident tickets efficiently in their incident management system. The snapshot view for this metric displays the mean recovery time for the selected time period. Choreo dynamically adjusts the time unit to measure this metric for better readability.
-This chart helps organizations evaluate the response time and agility of their incident handling teams, which in turn is an indication of stability. Higher MTTR means the leadership should look at new ways of improving the efficiency and agility of the teams handling incidents. The time series view of this metric shows how the mean time to recovery changes over time on a granularity based on the ‘view by’ selector. Each time the Choreo insights allow you to generate custom reports to view the information that is important to you to make timely decisions for the betterment of your business. With custom reports, you can generate reports for a set of metrics of your choice and aggregate results by specific fields. Once generated, the metrics can be filtered out using any selected group-by filters. Custom reports support three visualizations: overtime charts, pie charts, and tables. Choreo Insights allow you to retrieve data for the following metrics: Group-by fields specify how to group the metric data. e.g., You can select Successful Hit Count in the Metrics field and API Name under Group-by to retrieve the successful hit count grouped by the API name. Choreo Insights allow you to group metric data by the following fields: To generate a custom report, follow the steps below: In the left navigation menu, click Custom Reports. Select metric(s) from the Metrics drop-down selector. Select a minimum of 1 and a maximum of 3 group-by field(s) from the Group By drop down selector. Set the order of the group-by filters by drag and drop to determine the grouping order of the selected metric(s). Once you determine the order of the group-by fields, you can set values for each group-by field from the respective dropdown. Click Generate. Choreo Insights allow you to download report data related to each chart as a PDF or a CSV file. To do this, click the Download icon on the top right of the relevant chart and select the required file format.
- Choreo provides comprehensive insights into APIs created within both the on-premises API Manager and the Choreo platform. Choreo insights provide a range of metrics, including API traffic, error rates, and latency, allowing you to monitor and optimize API performance effectively. With Choreo insights, you can: By leveraging these insights, businesses can make informed decisions to enhance their API strategies and drive their digital transformation initiatives forward. To view usage insights, go to the Choreo Console and click Usage Insights in the left navigation menu. If you are viewing insights on the Choreo platform at the organization level, note the following: By ensuring proper permissions are set, organizations can manage access to insights effectively while maintaining data security and relevance. Once you access the Usage Insights page, you can access the following subpages. The Overview page gives you a quick overview of the system status. The information displayed is as follows: Total Traffic This widget displays the total traffic of the selected environment received during a given time interval. Both successful requests and failed requests are displayed. To investigate further, you can click the arrow icon on the bottom right corner of the widget to open the Traffic page. Error Request Count This widget displays the total number of requests that have resulted in errors in your selected environment during the selected time range. Average Error Rate This widget displays the average error rate (i.e., error count/total request count) of the selected environment for a given time interval. You can use this widget as an indicator to understand the health of the system. If the error rate is high, you can investigate further by clicking the arrow on the bottom right of the widget and opening the Errors page. 95th Percentile Latency This widget displays the 95th percentile of all API latencies in your selected environment for the given time interval. You can use this widget to know whether the complete system operates under given SLAs. This metric provides the first indication of slow APIs. To investigate further, you can click the arrow on the bottom right of the widget to open the Latency page where you can further analyze the latency. API Request Summary This chart displays the total successful requests, the total requests that have resulted in errors, and the latency in a timeline. The y-axis on the left displays the request count and the error count. The x-axis shows time, and the y-axis on the right shows the latency in milliseconds. The granularity of the data points is decided based on the time range you have selected. The tooltip provides the exact value of all three metrics accurately. The Traffic page shows information related to the traffic that goes through your API management deployments. This includes API usage, application usage, resource usage, etc. You can use this page to investigate the usage of APIs and applications, traffic patterns, etc. You can filter the information displayed in the widgets as follows: You can view the following information for the APIs you have selected using the above filtering criteria: API Usage Over Time This timeline shows the count of API hits for the APIs for the filtered APIs. If multiple APIs are selected, the timeline shows each API in a separate line with a legend separating each line. You can also zoom in on a selected time range by selecting that area in the chart. To restore to the original view use the Zoom out button on the top right-hand corner of the plot. API Usage By Application This widget shows the per-application breakdown of requests for the APIs you selected. You can use the pie chart view or the line chart view. You can switch between the two views using the small icon at the upper-right corner of the widget. API Usage By Target This widget shows the per-backend breakdown of requests for the APIs you selected. This information is useful when multiple APIs share the same backend that has traffic restrictions. You can use these stats to scale your backends proactively. You can switch between the two views using the small icon at the upper-right corner of the widget. API Resource Usage This table shows a resource-level breakdown of API traffic. Each row represents an API resource and it shows the API name, resource path, API method, and the hit count for that combination. The Errors page shows information related to erroneous API calls that are received by your system. The errors are categorized based on the error type. You can further drill down using the error subtypes. Use this page as the starting point for debugging any API errors. You can filter the information displayed in the widgets as follows: The following widgets are available for monitoring errors when you have selected Category in the upper-right corner of the page. This graph shows the error by category over time for the selected period. Apply the required filters as explained above to select the APIs and the error categories to which this content applies. When you select multiple APIs, the error count is grouped by category. This table provides further information about the errors such as application details and the error reason. For some authentication errors, the application name is not available. You can use this table to get more concrete information about the errors related to your APIs and then start the problem identification. The following widgets are available for monitoring errors when you select Status Code in the upper-right corner of the page. Errors by Status Code This graph shows the distribution of HTTP status codes received for errors over time for the selected period. Apply the required filters as explained above to select the APIs and status code groups to which this content applies. When you select multiple APIs, the error count is grouped by the status code. Target Errors by Status Code This graph shows the distribution of target errors that have occurred during the selected time interval by HTTP status code. Apply the required filters as explained in the table above to view the APIs and status code groups to which this content applies. If you select multiple APIs, the widget groups the target error count by the status code. Errors The Errors heat map shows the HTTP response codes of errors sent to the client by the API Gateway. Each row displays the number of times the system returned each status code for the selected APIs. The cell color is red for higher numbers and white for lower numbers. If required, you can further filter the results by the error code groups you identified with the Errors by Status Code graph. Target Errors The Target errors heat map shows the HTTP response codes of errors that the API Gateway received from the backend. Each row displays the number of times the system returned each status code for the selected APIs. The cell color is red for higher numbers and white for lower numbers. If required, you can further filter the results by the error code groups you identified with the Target Errors by Status Code graph. The Latency page shows information related to the latency of API calls within the API management deployment. You can view a summary of the slowest APIs and then drill down into the API view for further analysis. Use this page as a starting point to debug API slowness. The information displayed is as follows: Top 10 Slowest APIs This widget allows you to identify the slowest APIs of the API management system at a glance. Since these are the APIs that contribute to the higher 95th percentile of the system, improving these APIs lowers the 95th percentile of latency in the API Management deployments. Latencies By Category This widget allows you to further drill down details in the above chart. Use the API selector in this widget to select the slow API you identified in the earlier step and then analyze further. Use the charts available in the widget to view the 95th percentile and the median latency over the selected period of the following: You can use these charts to further drill down and analyze whether the latency occurs in the backend, request mediation, or response mediation. Also, because you can see both the median and 95th percentile, you can easily identify whether the slowness is occurring in each request or whether it is intermittent. The Cache page shows statistics that indicate the efficiency with which response caching is carried out for the requests sent to your APIs. The page displays the following statistics: Cache Hit Percentage This graph shows the percentage of requests the system has handled via the response cache over time and the total hits over time. This information allows you to assess how efficiently the backend handles API requests. For example, if the cache hit rate is low, it may indicate that the backend generates the same response each time a specific request is sent instead of returning the response via the cache. In such a scenario, there is scope to improve performance via response caching. Latency This section shows the total latency reported during the same time interval applied to the Cache Hit Percentage graph above. The Devices page displays information about operating systems and HTTP agents that end users use to invoke the APIs. You can use this page to get an idea of the distribution of your user base and improve your APIs to match the audience. To filter the information displayed on this page by API, select the required API(s) in the API field. All is selected by default. The information displayed is as follows: Top Platforms This chart shows the breakdown of the API clients by the operating system. The pie chart only shows platforms with a significant amount of requests. Other platforms are grouped under the Other category. Top User Agents This chart shows the breakdown of the API clients by user-agent. The pie chart only shows user agents with a significant amount of requests. Other platforms are grouped under the Other category. The Alerts page shows information related to business alerts issued by Choreo for your currently selected environment and organization. You can use this page as a health monitoring dashboard and make it visible to your project team. Using this page you can drill down on each alert and discover possible anomalies in your published APIs. See the topics given below to get details of the available widgets and understand how to use them effectively. Prerequisites To use this page, be sure to configure alerts and have API invocations that trigger alerts. Note Alerts are retained only for a week. Alert Summary This table lists each alert generated during the selected time interval. The message of the alert can be viewed by expanding the arrow icon on the details column. The drop-downs can be used to filter alerts based on the alert type and API. Top APIs by Alert Count This shows a pie chart and a table to visualize the alert distribution during the selected time interval. The Reports page allows you to download monthly usage reports for your system. There are preconfigured reports with system-wide statistics, and a custom report generator to generate reports based on a subset of APIs/applications. This widget allows you to generate a custom report for the statistics that have been generated up to now and download it. To generate a custom report, follow the steps below: In the API field, select one or more APIs for which you want to generate the report. If required, you can select all the APIs by selecting All. If you need to further filter the content printed in the report, select one or more applications in the Application field. By default, all the applications that have subscribed to one or more of the selected APIs are selected. Tip If you want to filter the report content by the API consumer instead of the application, click on the toggle switch to the right of the Application field, and then select the required consumer. Only consumers who have subscribed to one or more of the selected APIs are displayed in the list. You can either select one or all of them. Select the required year and the month in the Year and Month fields to specify the time interval for which you want to generate the report. Click Download, and select the required format. The report is downloaded in the specified format. The following is a sample report generated in PDF format. The contents of the report are as follows. The table in the report contains the following rows. These widgets allow you to download monthly reports for the last three months. To download a pregenerated report, click Download for the relevant month and then click on the required format. The Geo Map page allows you to see a geographical representation of your API usage. You can use this page to make business decisions such as identifying growing regions, analyzing the impact of a region-specific marketing campaign, etc. To filter the information displayed on this page by API, select the required API(s) in the API field. The default value is All. This heat map highlights the countries with the appropriate color based on the hit count. It uses a relative color scale to depict the highest hit count to the lowest non-zero hit count. You can hold the pointer over the highlighted countries to view the country name and the total number of hits from that location. You can also use the mouse to zoom the map or pan it. Optionally, you can download geo-map data in a tabular format using the PDF or CSV download options by clicking Note Moesif is an API analytics and monetization service that helps you grow your API products. You can integrate Choreo with Moesif and gain valuable insights into your API's usage. While Moesif's API analytics capabilities empower you to make informed decision-making on behalf of your organization, its monetization options simplify revenue generation from your APIs, eliminating the need for complex coding. In this guide, you will: Let's generate an API key in Moesif.
-If you're an existing Moesif user with a registered organization, proceed to step 1.2. If you are a new user, follow the steps below to register an organization and generate a key: On the Get Started page, enter meaningful values for the fields and create a new organization. Click Next. On the Overview page, click Next. This opens the Quick Install page. As there is no data, you cannot proceed. Let's configure Moesif to receive data from Choreo. Select a WSO2 Choreo as the Server Integration Copy the Application Id. If you are an existing user with a registered organization, or you do not have an API key for the organization you created, follow the steps below to access the generated API key: Let's configure Choreo to publish events to Moesif. Once you successfully add the key, you will see a delete option next to it. Currently, you can only configure one API key. If you need to add a new API key, you need to delete the existing key and add the new one. Note Once you configure the Moesif API key on Choreo, wait for five minutes before you publish any data to the Moesif API analytics platform. You have configured Choreo to publish data to Moesif. Let's see how you can view the insights on Moesif. Tip Invoke your API by following the Test REST Endpoints via the OpenAPI Console guide. Once you publish data, your Moesif dashboard will receive events. Once Moesif receives events, you will see a notification on Moesif confirming that it received data. Click Next on the notification. This will take you to the final step, where you can opt to add team members. In this guide, let's skip this step. You can now view your API's insights in the Moesif dashboard. Choreo offers the capability to access runtime logs through its console. However, in cases where viewing logs for your PDP is not supported by Choreo yet, you can still view the runtime logs of your components via the log analyzing solution provided by your cloud vendor as a workaround. Before you try out this guide, complete the following: You can view your PDP logs with Azure Log Analytics by following the steps below: The Choreo observability dashboard provides a comprehensive interface to visualize and monitor the performance of services deployed on Choreo. The Observability dashboard allows you to: Tip If you are a Choreo private data plane customer and you want to observe your private data plane using New Relic, see Observing Choreo Private Data Planes With New Relic. The throughput graph depicts the throughput of requests per second for a selected timestamp. By default, Choreo renders this graph for the data generated within the past 24 hours. You can change the default time window by selecting the time range and zone from the options bar. To expand the graph, click and drag the cursor over the period you want to drill down. You can view the Choreo service logs in the Logs pane below the throughput and latency graph. Clicking on a graph updates the Logs view to contain the corresponding log entries generated at that time. You can use these logs to identify the reasons for any latency and throughput anomalies you detect using the graph. The Diagnostics view allows you to simultaneously analyze errors, throughput, latencies, CPU usage, memory usage, and logs for a particular event. This facilitates detailed error detection and analysis. By default, the time range selected for the Throughput & Latency graphs is the same time range used for the Diagnostics view. Each horizontal section of the graph, termed a bin, represents a specific period and comprises: The Logs pane serves as a centralized view to observe logs of the components you deploy on Choreo. This facilitates rigorous troubleshooting and analysis. The unified log view in Choreo allows you to view runtime and audit logs to gain application and user insights while ensuring data privacy. Choreo provides real-time insights through live logs and allows you to view historical logs for insights into the past. You also have the flexibility to define a required time range to view relevant log entries, where an intuitive scrolling capability facilitates easy viewing of appropriate logs within the selected time frame. The log view also provides advanced filtering capabilities that allow you to efficiently navigate through appropriate logs to expedite troubleshooting in distributed environments. Note All personally identifiable information (PII) gets resolved at the frontend service level, with only relevant UUIDs stored in logs. Choreo runtime logs provide insights into both project and component-level logs, covering application and gateway logs. These logs streamline the debugging process by centralizing diverse log sources. In Choreo, any organization member can view runtime logs via the runtime logs page. Choreo allows you to apply filters based on parameters such as log level (error, warn, info, debug), log type (application, gateway), and environment (development, staging, production) to simplify the debugging process. To access runtime logs, follow the steps below: In the left navigation menu, click Observability and then click Runtime Logs. This displays runtime logs for the past 30 days by default. To view logs based on a specific time range and other requirements, you can apply the necessary filter criteria. When you view component-level logs on the Runtime Logs page, you will see both application and gateway logs. Each application log entry displays the following details: Each gateway log entry displays the following details: Note Occasionally, a request may not fit into any of the above categories. In such instances, the Audit logs, also called audit trails, enhance security, ensure compliance, provide operational insights, and help manage risks. In Choreo, an audit log records organization-level user-specific operations performed via the Choreo Console. It also captures the timestamp and the outcome of the action. As of now, Choreo captures the following user-specific operations as audit logs: In Choreo, organization administrators are allowed to view audit logs by default. If other members need to access organization-specific audit logs, the administrator can create a role with the relevant permission and assign it to members. For step-by-step instructions on how to create and assign a role with relevant permission, see Manage audit log access. To view audit logs, follow these steps: In the Choreo Console, go to the top navigation menu and click Organization. Tip As of now, you can only view organization-level audit logs. In the left navigation menu, click DevOps and then click Audit Logs. This displays audit logs for the past 30 days by default. To view audit logs based on a specific time range and other requirements, you can apply the necessary filter criteria. Choreo retains audit logs for one year and archives them for an additional year. Therefore, the total retention period for audit logs is two years. Follow the steps given below to create a role with audit log access permission and assign it to organization members who need access to audit logs: Note You must be the organization administrator to perform this action. Enter a name and description for the role. Click Next. In the Create Role dialog, select LOG-MANAGEMENT under Permissions. Click Create. Click on a member who needs to have access to audit logs, and then click + Add Role. Tip If you want to invite one or more members and assign them the audit log viewer role, follow the steps given below: Click to expand the Roles list and select the role you created in Step 1. The Usage Insights page in the Choreo Console displays data retrieved from the Insights API exposed over the Internet. However, in some scenarios, you may need to retrieve data from external systems and implement custom dashboards to display the data. Choreo provides a secure and user-friendly approach to accomplish this requirement. Follow the steps given below: Access the Developer Portal of the To obtain access to the To create an application and generate keys, follow the steps below: To create a new application in the Enter a name for the application and click Create. This creates the application and takes you to the Overview page. To subscribe to the Insights API via the newly created application, follow the steps below: To generate credentials for the application, follow the steps given below: To specify an appropriate token expiry time for the application, follow the steps given below: Execute the following cURL command to generate an access token: Info To obtain your organization handle, follow the steps given below: You can use the generated token to access the Insights API exposed via https://choreocontrolplane.choreo.dev/93tu/insights/1.0.0/query-api. The following is a sample cURL command to invoke the Insights API: The Choreo Insights API is a GraphQL API that allows you to retrieve data from external systems based on specific criteria. This guide describes the operations and schema-defined types you can use to retrieve data via the Choreo Insights API. You can try out the Choreo Insights API with your data via GraphQL Explorer. Warning The GraphQL Explorer is currently not compatible with the Safari web browser due to a known issue. The query root of the Choreo Insights GraphQL API. Represents API details. Represents latency values for a single API over time. Represents the API usage for a single timestamp. The timestamp is calculated based on the granularity value provided. Represents API usage across APIs by a single application. Represents API usage across APIs by applications over time. Represents a single API usage by a single application. Represents API usage across APIs by a single backend. Represents API usage across APIs by each backend over time. Represents a single API usage over time. Represents alert summaries. Represents a summary for an alert. Represents application details. Represents the response cache hits and misses for a single timestamp. The timestamp is calculated based on the
-granularity value provided. Represents the response cache hits and misses over time. Represents the usage data overtime for the selected parameters of a specific Represents usage data overtime for the selected parameters. Represents usage data overtime for the selected parameters grouped by the top N Represents usage data for a single timestamp in Represents error details over time. Represents an environment. Represents the number of errors from each category for a single timestamp. The timestamp is calculated according to the
-provided granularity value. If you select some categories, the error counts are retrieved only for those categories,
-and a Represents the error count for a single error status code. Represents the error count for each status code for a single API. Represents details of an error for a single timestamp. The timestamp is calculated according to the granularity value
-provided. Represents errors by the main status code ( Provides the unsuccessful usage (i.e., Represents the unsuccessful request count (i.e., Represents the errors by category over time. Represents the error counts grouped by status code for each API. Represents the error category values (grouped as Represents latency values for each latency category for a single timestamp. The timestamp is calculated based on the
-granularity value provided. Provides the latency summary. Represents the latency value for a single timestamp. The timestamp is calculated according to the provided granularity
-value. Represents an organization. Represents the overall latency values. Represents pagination details. Represents a platform. Represents API Provider details. Represents the usage of a single API resource. Represents API resource usages. A slow API identified based on the response latency (95th percentile). Represents API Subscriber details. Represents successful usages(that have resulted in the Provides the successful (2xx response code) usage summary across all the APIs. Represents the successful request count (i.e., requests that have received the Represents a top API by alert count. Represents the top APIs by alert count. Represents the total errors. Represents the usage of a single API in a single country. Represents a user agent. Filters the API usage by application results. Filters the results for API usage by backend over time. Filters the results for API usage over time. Filters the alerts summary results. Filters applications by the application owner and API IDs. Filters response cache results. Filters results by the given combination of organization, environment, and tenant. Filters results related to devices. Filters errors by status code results. Filters errors by category results. Filters errors by status code results. Filters the results for error details. Filters the API usage by geolocation results. Filters latency results. Filters latency summary results. Filters results for the given organization. Filters related to pagination. Filters resource usage results. Filters results by searching matching results for the provided search text. Filters the subscriber results. Filters successful API usage by application results. Filters results by the tenant. Filters results by the provided date range. Filters the top APIs by alert count results. Represents an error type. Represents an error code type. Represents an error type. Represents an Represents a metric used in The The The The The Choreo is an Internal Developer Platform (IDevP) that streamlines the entire process of building, deploying, monitoring, and managing your cloud-native applications easily. In this quick start guide, you will explore how to expose a service endpoint via Choreo and securely consume the service from a web application. You will use a simple reading list web application with a sign-in page and functionality to interact with a secure backend service. You will also use Choreo's managed authentication to easily set up authentication for your web application without having to dive into the details of security protocols. The application will allow users to sign in and view their reading lists, add books to a reading list, delete books from the reading list, and sign out of the application effortlessly. This guide walks you through the following steps: Before you try out this guide, complete the following: Create a GitHub repository to save the service implementation. For this guide, you can fork the Choreo sample book list app repository. If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the organization home page. Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Tip In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and opens the project home page. To connect to the repository you forked in the prerequisites and configure the sample service, follow the steps given below: To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo sample book list app repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: In the Add Component Directories pane under Configure Components, click the + icon corresponding to In the Component Configuration dialog that opens, specify values as follows for each of the fields: Click Save. This adds the Click Finish. This initializes the service with the implementation from your GitHub repository and takes you to the project home page. You can see the To build the service, follow the steps given below: !!! note
- Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. For the REST endpoint of the service to be invokable, you need to deploy it. To deploy the service, follow the steps given below: To test the endpoint via the integrated OpenAPI Console in Choreo, follow the steps given below: Update the request body so that the parameters have the values given below: The request body should look as follows: Check the Server Response section. On successful invocation, you will receive the Similarly, you can expand and try out the GET and DELETE methods. Now that the In this section of the guide, you will deploy a sample front-end application to consume the service. This application will serve as the interface for users to interact with the reading list. The sample application used in this guide is designed to personalize the book lists based on the user ID that it obtains from its identity provider. To host the front-end application in Choreo, you will create a web application component, set up authentication for it, and deploy it. To establish a connection between your web application and the deployed service, you will create a Connection. To create a web application component, follow the steps given below: Enter a display name, unique name, and a description to create the web application. You can enter the values given below: Info In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component. Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo sample Book List Service repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Select React as the buildpack because the sample front-end application is a React application built with Vite. Enter the following information: Click Create. This initializes the component with the implementation from your GitHub repository and takes you to the Overview page of the component. A connection allows you to integrate the service you intend to deploy on Choreo with other services on Choreo or external resources. For more information on Choreo Connections refer to the Connection documentation. To establish a connection between the web application you created and the deployed service, follow the steps given below: Specify values as follows for each of the fields: Click Create. This creates the connection and displays the service URL of the connection for
-each environment the service is deployed in. In this guide, you will see the service URL for the Development environment. You can copy the service URL to use when you configure the web application before deploying it. To build the web application, follow the steps given below: !!! note
- Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. In this step, you will configure managed authentication, create a user to access the web application, and then deploy the web application. For more information on Choreo's managed authentication capability, see the Managed Authentication documentation. To configure managed authentication, follow the steps given below: Specify the following in the You must replace Tip You can refer to the configuration file mounted at Click Next. This opens the Authentication pane. Under Authentication Settings, make sure that you have the Managed authentication with Choreo toggle enabled. Tip Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks. Specify values as follows for each of the fields: Next, you can create a user to access the web application. To create a user to access the readingListApp application, follow the steps given below: To proceed with creating a user with the populated username and password, click Create. Make sure you copy the populated username and password to use when you test the front-end application. Tip Now, you can deploy the web application. To deploy the web application and obtain the URL to access it, follow the steps given below: To test the front-end application and send requests to the Reading List Service via it, follow the steps given below: Click Login, and sign in with the credentials of the user that you created. The application opens as follows. Add three new reading items with different statuses. For example, the details can be as follows: To add each record, follow the steps given below: Three tabs open for each status. To delete a reading list item, you can click Delete. To verify whether the reading list is personalized for each user, you can sign in as a different user. The reading list items you entered above will not appear for the other user. Congratulations! You have successfully exposed a service endpoint via Choreo and securely consumed it from a web application. After you have successfully tested your service and web application, you can now try out various other Choreo features such as managing, observing, DevOps, etc., similar to any other component type within Choreo. Choreo, an Internal Developer Platform (IDevP), simplifies the deployment, monitoring, and management of your cloud-native services, allowing you to focus on innovation and implementation. Choreo allows you to easily deploy services you've created in your preferred programming language in just a few steps. In this guide, you will: For a video tutorial that walks you through these steps, see Deploy Your First Service with Choreo. You must have a GitHub account with a repository that contains your service implementation. To proceed with the steps in this guide, you can fork the Choreo sample book list service repository, which contains the sample for this guide. If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the organization home page. Let's familiarize ourselves with the key files in this sample application. The below table gives a brief overview of the important files in the sample book list service. Note The following file paths are relative to the path Let's get started! Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Info In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and takes you to the project home page. Let's create a service component by following these steps: Enter a unique name and a description for the service. For this guide, let's enter the following values: Go to the GitHub tab. To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the Choreo sample Book List Service repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Select the NodeJS buildpack. Enter the following information. Click Create. You have successfully created a Service component with the NodeJS buildpack. Now let's build and deploy the service. Now that the source repository is connected and Choreo has set up the endpoints based on the repository's configuration, it's time to proceed with building the service. Choreo will create a Docker image in the build process. You can then deploy the built Docker image and test the book list service. To build the service, follow these steps: !!! note
- Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. Now you are ready to deploy the service. Follow these steps: Review the Endpoint Details and click Deploy. Note Deploying the service component may take a while. You can track the progress by observing the logs. Once the deployment is complete, the build status changes to Active on the Development environment card. To test the Book List service via the integrated OpenAPI Console in Choreo, follow the steps given below: Similarly, you can expand and try out the other methods. After you have successfully tested your service, you can now try out various other Choreo features such as managing, observing, DevOps, etc., similar to any other component type within Choreo. Choreo is an internal developer platform as a service that takes care of the complexities of building platforms, allowing application developers to focus on innovation and implementation. Choreo streamlines the entire process of building, deploying, monitoring, and managing your cloud-native applications. In this quick start guide, you will explore how easy it is to deploy a web application using Choreo. Here, you will use a simple web application designed to add tasks to a to-do list. This guide walks you through the following steps: For a video tutorial that walks you through these steps, see Deploy a Static Web App on Choreo. Before you try out this guide, complete the following: If you are signing in to the Choreo Console for the first time, create an organization as follows: This creates the organization and opens the organization home page. Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Tip In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and opens the project home page. To create a Web Application component, follow the steps given below: To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App. Alternatively, you can paste the choreo-sample-todo-list-app repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component. Note The Choreo GitHub App requires the following permissions: You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository. Enter the following information: Select NodeJS as the Buildpack Enter the following information: Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component. Now let's build and deploy the web application. To build the web application, follow the steps given below: In the Builds pane, click Build Latest. Note Building the component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success. Now you can proceed to deploy your web application. After you have successfully tested your web application, you can now try out various other Choreo features such as observability, DevOps, etc., similar to any other component type within Choreo. Explore key limitations in Choreo, covering areas like HTTP request parameters, components, applications, and API definition files. You can gain insights into the limitations to enhance your understanding and optimize your use of Choreo effectively. Below are key limitations when working with APIs in Choreo: Below are key limitations when working with web applications in the Choreo cloud data plane: Choreo is an internal developer platform designed to accelerate the creation of digital experiences. With Choreo, you can effortlessly build, deploy, monitor, and manage your cloud native applications. Our goal is to enhance developer productivity and enable innovation. An organization is a logical grouping of users and their resources. It may represent a company, community, or a single user. Users can belong to multiple organizations, and each organization can have different roles assigned to its users to control access to Choreo features. A project is a logical grouping of related components to help you organize your work. Each project provides runtime isolation through namespaces when you deploy components. A component is a workload designed to run on Choreo. Examples of components include integrations, APIs, microservices, manual/scheduled jobs, web apps, and triggers. In Choreo, you can publish an API as an internal or an external API. A user or an application can access an external API publicly over the internet, whereas an internal API is only accessible through other components within the same organization. A connector is a reusable Ballerina package that simplifies connecting to external or internal systems and APIs, such as Salesforce, SAP, GitHub, and Twilio. You can use the connectors available in the Choreo marketplace to implement your integration use cases. Connectors can be created and published by both WSO2 and Choreo users. A trigger is a construct that enables users to receive known event payloads from external systems, facilitating event-driven programming. A sample or template is a prebuilt Ballerina program that covers a popular integration use case or pattern. Examples include connecting Salesforce to Slack or implementing content-based routing. You can find information about our support plans, including If you have a log monitoring product or service, such as Azure Monitor, you can use it together with Choreo. Note: The log monitoring tool is not included in the infrastructure cost. Choreo allows a maximum request payload size of 10 MB. Choreo now supports GitHub, Bitbucket and GitLab. You are allowed to build your component any number of times. However, Choreo has a limit on retaining undeployed builds. For users on the free-tier, Choreo will retain only one undeployed build. For those on any other tier, Choreo will retain the latest five undeployed builds. Ballerina is an open-source programming language designed for the cloud. It simplifies the process of using, combining, and creating network services. When you use Ballerina to write integrations in Choreo, you can save time and deliver 2-3x faster. To learn more, check out https://ballerina.io/. Asgardeo is an identity provider (IdP) that allows developers to secure access for consumers, business partners, employees, and APIs. Asgardeo is Choreo’s default IDP. To learn more, visit https://wso2.com/asgardeo/. If you are a Choreo cloud data plane user, you can create projects in multiple regions only if you have a paid subscription in Choreo. Otherwise, your projects will be created in the same region you selected when onboarding the organization. If you are a private data plane user, there will be no region selector in project creation at all. When an organization admin onboards a new organization in Choreo, they can choose the preferred data plane. Choreo then sets the selected data plane as the default for the entire organization. Subsequently, users within the free tier of the cloud data plane can create components only in the set default data plane. If a free-tier user needs to create components in a different data plane, the user must get a paid subscription. Choreo manages data using WSO2 containers and Kubernetes clusters, which provide scalability, resilience, and security. Find out more here. This is a detailed list of all subprocessors used by WSO2, including their name, location, and purpose. This information is updated frequently to ensure compliance with data protection regulations and is found here. WSO2 uses a range of security controls and design patterns to protect against several threats, including internal attacks, software supply chain attacks, service and platform attacks, and more. Find out more regarding this here. To connect a Choreo component with a third-party application, it is necessary to establish seamless communication between the component and the protected third-party application, especially when connecting to external databases like MySQL, MSSQL, PGSQL, Oracle DB, etc.
-To ensure this, the requests coming from the Choreo data plane must be allowed by adding the specific data plane IP ranges to your allowlist. If your component is deployed in the Choreo US data plane, add the following IP range to your allowlist: If your component is deployed in the Choreo EU data plane, add the following IP range to your allowlist: If you are working on the Cybertruck Challenge, add the following IP range to your allowlist: The Choreo control plane is a centralized management component that oversees and coordinates the workloads deployed by customers. It provides a unified point of control and visibility for the organization, allowing administrators to manage, monitor, and orchestrate the organization’s resources efficiently. A data plane in Choreo is a computing environment designed for running customer workloads. These environments are hosted in either a dedicated cloud infrastructure owned by the customer (private data planes) or on public cloud infrastructure owned by WSO2, also known as the Choreo data plane. The Choreo data plane is currently supported in the US East 2 and North Europe. However, WSO2 is planning to add support for additional regions as needed. Private data planes can be deployed in any region where Azure and AWS are available and meet the requirements for PDPs. We recommend using a minimum of two (2) workload nodes to ensure high availability. The Choreo control plane and data plane are designed for high availability using Azure components like AKS, MSSQL, ACR, KV, Service Bus, and so on, with a high availability of 99.99%, which allows at least three workload nodes. In the event of a node failure or upgrade, this setup provides reliable failover. WSO2 also has a backup and recovery strategy in place, including continuous restore drills. If you require AKS cluster-level redundancy, we can consider multiple zones. In this case, the cost will include an additional infrastructure cost. You can create environments only if you have a paid subscription in Choreo. It can be either Pay-as-you-Go (PAYG) or an Enterprise plan. You can create up to 5 environments at the organization level, including the existing Development & Production environments by default. If you have projects in both data planes (US & EU), there will be 4 environments already created in total, and you will only be allowed to create one additional environment either in the US or EU data plane. As an Enterprise subscription customer, the number of environments you can use is not limited. However, the more environments you use, the more resources you will consume in the data plane for the workload you deploy. This may result in higher infrastructure costs for the private data plane. You will see both US & EU data planes only if you have a paid subscription and have created projects in both US & EU data planes. Initially, you will receive the requested number of environments when establishing your private data plane. Subsequently, you can create additional environments as needed. You can reach out to cloud-billing-support@wso2.com or create a support ticket via our support portal. A Developer plan allows you to try out Choreo’s capabilities at no cost. It’s ideal for proof of concept (PoC) tasks or workloads with limited transactions. This plan allows you to experiment with up to 5 components and provides US$1,000/year of Choreo data plane (CDP) credits. Calculating infrastructure costs depends on the type of workload you want to manage. Here are a few examples: Your bill will detail the number of components used, infrastructure consumed, support plans used, and any additional services you may have purchased. If you are unsure about any charges on your bill, reach out to choreo-support@wso2.com for clarification. The Choreo Enterprise plan does not automatically include support; however, you can purchase support plans in addition to the Enterprise plan at any time. Find out more at https://wso2.com/choreo/customer-support/. You can start by using a basic plan or contact us for an Enterprise support plan. No, there are no outages when upgrading a plan. If you didn't download the binary directly, you can uninstall the CLI by deleting the You can update the CLI by running the following command:
- The Choreo CLI currently supports the following component types:
-- Service
-- Web Application
-- Webhook
-- Scheduled Task
-- Manual Task You can get help with a specific command by running the following command:
- You can configure the component build configurations depending on the component type as follows: The build configurations required for existing buildpacks are as follows: Choreo supports various management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios. The following sections provide insights into WSO2's fully managed solutions and shared responsibility models, allowing you to make informed decisions regarding cloud-based operations and security. WSO2 fully managed private data planes are supported only on Azure, AWS, and GCP cloud providers. The following table outlines the private data plane security levels supported in Choreo: * Not available in the on-premises private data plane. Tip Available add-ons:
- - Security incident and event management (SIEM).
- - 24/7 security operation center. This page walks you through common problems you may encounter when building and deploying components with Choreo, along with the recommended solutions to resolve each issue. This occurs due to specifying an incorrect build output directory when you set up your Angular application in Choreo.
-To resolve the issue, follow the guidelines given below: The recommended approach to address this issue is to fix the identified vulnerability and rebuild the component. However, if you want to add a To resolve this issue, follow the steps given below: Reference it from the To ensure correct loading of the Reference the Verify that the path in the script tag matches the location where the Merge commits and commits pushed directly to the branch can trigger a build in Choreo. This can happen if an incorrect build output directory is specified during component creation. During the build process, output files including the In such scenarios, you can use the Dockerfile buildpack to create the component. You can go to the build page of the component and update the build command in the build configurations section. For step-by-step instructions on how to manage users with Choreo's built-in identity provider (IdP), see Configure a User Store with the Built-In IdP. For details on setting up other OpenID Connect (OIDC) supported IdPs, see Manage OAuth Keys. To troubleshoot Tailscale proxy issues, you can view the Runtime Logs of the running container for your Tailscale proxy deployment. These logs can help you diagnose most of the issues.
- You can also view real-time container logs via the Runtime page under DevOps. For more details, see Observe real-time container logs. If you encounter the following log lines in your Tailscale proxy deployment, it indicates a misconfiguration of the If you encounter the following log lines in your Tailscale proxy deployment, it indicates that your authentication key is invalid or expired.
- To resolve this, you must verify the correctness of your authentication key. If the key has expired, you must generate a new key from Tailscale admin console. To resolve this, do the following: NoteThe Home page will be designed to provide a guided experience to any user coming to docs with a valid Choreo use case. We intend to ONLY INCLUDE conceptual information in the documentation for the relevant topics and **NOT INCLUDE** any how to guides, or instructions with the exception of Tutorials. Try one of the navigation links above or use the search engine in the top right corner.\u00a0 Choreo is an internal developer platform that redefines how you create digital experiences. Choreo empowers you to seamlessly design, develop, deploy, and govern your cloud native applications, unlocking innovation while reducing time-to-market. The following are some of the cutting-edge capabilities of Choreo: Design that leads to end-to-end security, governance, and operational efficiency: Efficient and effective development: Seamless deployment: Effortless management of APIs, integrations, microservices, and web applications: Reusable digital assets: Comprehensive observability: Robust governance: A custom domain is essential for effective branding, discoverability, and credibility of a website. Choreo allows you to easily configure custom domains for your organization, enabling developers to utilize it to configure custom URLs for their components such as API proxies, services, web applications, and webhooks. This section provides an overview of Choreo\u2019s custom domain configuration model and guides you through configuring a custom domain for your organization. It also walks you through utilizing a custom domain to configure a custom URL for a component. Choreo allows organization administrators to add custom domains for their organizations. When an administrator adds custom domains to an organization, component developers can submit requests to utilize the custom domains for their respective components. These requests require approval from the organization administrator. Upon approval, the custom domain and the relevant URL customization become available to the component. Create an organization in Choreo. To add a custom domain for your organization, follow the steps given below: Note To add a custom domain, you must have organization administrator privileges. In the Add a Custom Domain pane, do the following: Select the entity type to apply the domain name. Tip In this context: Take a look at the generated CNAME target value displayed and create a DNS record associating the domain name to the CNAME target value with your DNS provider. Info When you select Developer Portal as the type, the environment is not applicable, and the CNAME alias will be displayed as follows: Once the CNAME type DNS record is created, click Verify. Note If the CNAME mapping is correct, the verification completes successfully. It can take some time for the configured CNAME mapping to be globally available. On successful verification of the custom domain, click Next. Select a TLS certificate provider depending on your preference. You can either import the TLS certificates you created for the custom domain or click Let's Encrypt to allow Choreo to generate and manage the certificates for you. If you want to import your own certificate, it should adhere to specific guidelines To proceed with this step in this guide, click Let's Encrypt. To save the custom domain, click Add. Now, you have successfully added a custom domain for your organization. You can see the added custom domain listed in the Active Domains tab under the URL Settings tab. The custom domain you added will be available to the entity types in the specified environment. You can request the custom domain when configuring a custom URL for a component. Note If you add a custom domain for the Developer Portal type, the customization is applied immediately, and you can access the organization\u2019s Developer Portal via the added domain. If you want to view the entity types that use a particular custom domain, click the specific custom domain listed in the Active Domains tab under URL Settings. When an organization administrator adds custom domains for specific environments, developers can request any available custom domain to configure a custom URL for a component in a specific environment. To request a custom URL for your component, follow the steps given below: Note Before you request a custom domain for a specific environment, ensure that the component is deployed to that environment. Click the URL Settings tab. This displays the active deployments of the component across different environments and indicates whether a custom URL is configured. If an active custom domain is available to configure a custom URL for a component in a specific environment, the Edit URL Mapping icon in the corresponding Action column becomes enabled. To configure a custom URL for a component in a specific environment, click the Edit URL Mapping icon under the Action column corresponding to the respective environment. This opens the URL Settings dialog, where you can specify values to request for a custom URL. In the URL Settings dialog, select a domain to configure a custom URL. Tip Click Configure. This creates the custom URL mapping, which you can see under the URL Settings tab. The custom URL request will be in the Pending status until an organization administrator approves the request. When a developer requests a custom URL, the request will be listed in the organization-level settings page under the URL Settings tab. To approve a custom URL mapping, follow the steps given below: Note To approve custom URL requests, you must have organization administrator privileges. Click the URL Settings tab and then click the Pending URL Requests tab. You will see all the pending URL mapping requests sent by developers. Go to the custom URL you want to approve and click the corresponding Approve URL Mapping icon under the Action column. Once approved, the invoke URL of the component gets replaced with the configured custom URL. Now you have successfully utilized the configured custom domain to set up a custom URL for a component. Developers looking to experiment with a complete application development process that includes user authentication and authorization can utilize Choreo's built-in identity provider (IdP). Choreo's built-in identity provider allows you to seamlessly test your application's authentication by setting up test users and groups within Choreo. Note Although the built-in IdP facilitates user management support, it is limited to adding users with attributes and groups. Therefore, the built-in IdP user management capabilities are not recommended for use in production. Before you try out the steps in this guide, be sure you have administrator rights to your Choreo organization. This permission is essential to configure a user store with the built-in IdP. Follow the steps given below to configure a Choreo built-in IdP user store for an environment: Note The provided template file includes a sample user with associated attributes. To add new users, insert additional rows in the With Choreo, you can configure enterprise login to allow users from an external identity provider (IdP) to sign in to Choreo seamlessly without changing their credentials. This guide walks you through the steps to configure enterprise login for your organization in Choreo. Before you proceed with the configuration, set up the following: To configure enterprise login for your Choreo organization, follow the steps given below: If you already have a support account with us, send us your organization name/handle and the email domains specific to your organization through our support portal. If you do not have a support account with us yet, send an email to Tip Ensure you include the following information in the request: Sample email Subject : [Stark Industries] Configure enterprise login Hi CS team, I need to configure enterprise login for my organization. Can you please do the necessary configurations to proceed? My organization details are as follows: Thank you. The Choreo support team will perform the necessary configurations and respond to you with a verification code. You must sign in to your domain host account and configure the DNS record for your email domain with the following values: Now, you are ready to bring your own identity to Choreo. When you create an organization in Choreo, an organization with the same name is provisioned for you in Asgardeo. To bring your own identity to Choreo, you must configure a federated enterprise IdP on Asgardeo in the organization that is provisioned for you. Follow the steps given below to configure the federated IdP: Now, users in your enterprise IdP can sign in to the Choreo Console using their enterprise IDs. To streamline the enterprise login process and grant appropriate permission, Choreo provides the flexibility to configure role-based access control for users who reside in an external IdP. To set up role-based access control for enterprise login within Choreo, follow the steps given below: Before you proceed with the configuration, make sure you complete the following: Configure your IdP as an external IdP in Asgardeo. Depending on your IdP, you can select OpenID Connect or SAML as the protocol between Asgardeo and your IdP. Note If you are using OpenID Connect, configure the requested scopes accordingly for Asgardeo to get the relevant group/role details from the external IdP. To configure the application, follow the steps given below: Configure the IdP for login depending on the protocol you selected: Click the User Attributes tab. To add the user attributes as OpenID Connect scopes, follow the steps given below: Note Before you map Choreo groups to enterprise IdP groups, ensure you meet the following criteria: Click Manage IdP Group Mapping. Click the edit icon corresponding to the Choreo group you want to map to the enterprise IdP group. In the IdP Group Name field, specify the exact name you configured in the enterprise IdP and enter to add it. Tip If there is a change to the IdP group mapping, it takes effect from the next login session onwards. Click Save. By following these steps, you have successfully configured role-based access control for enterprise login in Choreo, allowing users from the external IdP to have the appropriate permission. With Choreo, you can set up a self-sign-up page for your Developer Portal. The self-sign-up page allows users to easily access your Developer Portal and subscribe to APIs. When you configure self-sign-up, users can create their accounts and access your Developer Portal without any manual intervention from you. This page walks you through the steps to configure self-sign-up for your Developer Portal. To configure self-sign-up, follow the steps given below: Send an email to choreo-help@wso2.com requesting to configure enterprise IdP for the Developer Portal of your organization. Tip Ensure you include the organization name or handle in the request. Sample email Subject : [Stark Industries] Configure enterprise IdP for Developer Portal Hi CS team, I need to configure enterprise IdP for my organization\u2019s Developer Portal to enable self-sign-up. Can you please do the necessary configurations to proceed? My organization details are as follows: Thank you The Choreo support team will perform the necessary configurations and respond to your request. When you receive a response, sign in to Asgardeo using the same credentials that you used to sign in to Choreo. In the Asgardeo Console, click View all applications. You will see an application named WSO2_LOGIN_FOR_CHOREO_DEV_PORTAL. Click on the application to edit it and enter your organization\u2019s Developer Portal URL as the Access URL of the application. For example, To add user attributes, follow these steps: Note If you have enabled enterprise login and you want to add the Groups attribute during self-sign-up configuration, avoid making it mandatory. This ensures proper access control and prevents unauthorized privileges. If you make the Groups attribute mandatory, it allows self-signed-up users to specify a group and assume roles associated with it. To add the email as a mandatory user attribute, select Email and click the arrow to expand the section. Then, select the Requested and Mandatory checkboxes. To add the first name and last name as optional attributes, select Profile and click the arrow to expand the section. Then, select the Requested checkbox for the First Name and the Last Name attributes. Click Update. To add the user attributes as OpenID Connect scopes, follow these steps: Click Save and then click Save Changes. To configure basic authentication as the sign-in method, follow these steps: Click the Sign-in Method tab and then click Start with default configuration. Click Update. To configure self-registration, follow these steps: Click Update. Once you complete these steps, you will see a sign up link similar to the following in your Developer Portal: Users can click LOGIN/SIGN UP and then click Create an account to sign up to access your Developer Portal. To manage users who want to access your Developer Portal via self-sign-up, you have two possible approaches: To automatically approve each new user account registered on your Developer Portal, follow the steps given below: Once you enable auto-approval, users can sign in to your Developer Portal and view your APIs and applications immediately after creating an account. If you have not enabled auto-approval, you can manually approve or reject new user registrations. Once a user creates an account, Choreo sends an email to ask the user to confirm the account. To manually approve or reject user accounts, follow the steps given below: To approve a user account, click Approve. To reject an account, click Reject. If you reject an account, the user will receive an email mentioning that their account is rejected. Note A rejected user cannot sign up to your Developer Portal using the same account again. In the Choreo Console, you have the ability to manage access to projects and the actions that can be performed within them. Administrators have the capability to restrict project access to specific user groups. This feature is useful when you need certain user groups to have access to particular projects or for a set of projects. Choreo uses Roles, Groups, and a Mapping level to control access to the Choreo Console as follows: Group : Group is a collection of users. A user group requires a role or multiple roles to be assigned to it so that the users in those groups get the relevant permissions via the assigned roles. Learn more Mapping level : A mapping level defines the extent at which a role-group mapping can be done. Choreo has two defined resource levels. In Choreo, authorization operates by assigning a role to a group at a specified level. The level at which the role is assigned determines the extent of permissions granted to users. Important Avoid assigning multiple roles to a single user across different projects or levels (organization and project). Such assignments can grant users unintended permission to some projects, allowing them to perform tasks they shouldn't have access to. Therefore, it is recommended to assign only one role to a user across projects or levels to ensure proper access control. Info In Choreo, organization-level permissions take precedence over project-level permissions. To elaborate further, refer to the following diagram. The following diagram depicts a role-group assignment at a specific resource level. In the diagram, an admin user has assigned the Developer role to all members of the Engineering group within the Engineering Project. This grants users in the Engineering group the ability to perform all actions allowed by the Developer role within the Engineering Project. Now that you understand the basic concepts of access control within the Choreo Console, let\u2019s try out a sample scenario to manage access within a project. Assume you are overseeing the Engineering Project within your organization and you need to grant development access to specific users solely within this project. Here's a step-by-step guide on how to achieve this: Follow the steps given below to create a project: Enter a display name, unique name, and description for the project. You can enter the values given below: Info In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project. Click Create. This creates the project and takes you to the project home page. Follow the steps given below to create a group with the name Enter a group name and group description. You can enter the values given below: Click Create. Follow the steps given below to assign the Developer role to the Engineering Project Developer group that you created: Click Add. This assigns the Developer role to the group. You should see the mapping level as Project (Engineering Project) as follows, indicating the scope of the mapping: This means that you have granted developer access to users in the Engineering Project Developer group in the scope of the Engineering Project. Now that you have set up access control, you can proceed to add users to the new group. There are two approaches you can follow to add users to the group. Follow the steps given below to add a new user as a project developer: Follow the steps given below to add an existing user as a project developer: Tip Make sure to remove the user from any other groups to avoid granting organization-level access unintentionally. Note Now you have successfully set up access control within your project. API subscription plans are essential to control and manage access to APIs. These plans define the rules and limitations on how clients can interact with APIs, ensuring efficient resource utilization and robust security. With the option to set rate limits and burst control, subscription plans allow API providers to manage traffic, prevent misuse, and offer tiered service levels. Organizations can implement subscription plans to provide varying levels of API access, accommodating different user needs and business models, while ensuring optimal performance and security. In Choreo, users with the administrator role can create, update, and delete subscription plans at the organization level. Tip Deleting a subscription plan is only possible if there are no active subscriptions associated with it. To create an organization-level subscription plan, follow the steps given below: In the Create Subscription Plan pane, enter the appropriate values for each field: Note Click Create. This creates the subscription plan and lists it under Subscription Plans. After creating subscription plans, users with the API publisher role can assign subscription plans to APIs. API consumers can then choose the appropriate subscription plan during the subscription process depending on their requirements. The Developer Portal allows API consumers to find and consume APIs with ease. You can change the look and feel of your Developer Portal by changing the theme to match your brand. Doing so will help you give a better developer experience to your users. To customize the Developer Portal theme, follow the steps given below: Note Sign in to the Choreo Console at https://console.choreo.dev/ using a Google/ GitHub/ Microsoft account. In the left pane, click Settings. In the header, click the Organization list. This will open the organization level settings page. In the API Management tab, click Devportal Theme. Once you access the theme, you can customize the Home page, color theme, font, header and footer, logos, etc., by expanding the relevant sections. Make a change to the theme. For example, let's change the title on the Home page and the color theme. To update the title on the Home page, expand the Home Page section, and in the Title field, change the default text (for example, to To update the color theme, expand the Color Palette section, and change the colors as required (for example, change the background color to Click Preview to view a preview of the Developer Portal with the changes you made. Based on the changes given in the examples, the preview appears as follows. Click Save to save your changes as a draft theme. To apply the changes to the Developer Portal, toggle the Go Live switch. To confirm that you want to go live with the changes, click Enable in the message that appears. Sign in to the Choreo Developer Portal at https://devportal.choreo.dev. The Home page will appear as it did in the preview. To reset the Developer Portal theme to the default theme, follow the steps given below: Sign in to the Choreo Console at https://console.choreo.dev/ using a Google, GitHub, or Microsoft account. In the left pane, click Settings. In the header, click the Organization list. This will open the organization level settings page. In the Organization tab, click Devportal Theme, and then click Reset to Default. An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization. An organization in Choreo is a logical grouping of users and user resources. A first-time user must create an organization and be a user of it when signing in to Choreo. Users and resources in an organization cannot access resources in another organization unless an admin of the other organization invites them and adds them as a user of that organization. An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization. For details on how Choreo manages user permission, see Manage user permission. Asgardeo is an identity-as-a-service (IDaaS) solution designed to create seamless login experiences for your applications. Asgardeo seamlessly integrates with Choreo, providing powerful API access control through the use of API scopes. This enables restricting API access to designated user groups. By configuring Asgardeo as an external IdP in Choreo, you can leverage your Asgardeo user stores to manage API access control effectively. This guide walks you through the steps to set up Asgardeo as your external IdP. Before you proceed, be sure to complete the following: Create an Asgardeo application. You can follow the Asgardeo guide to register a standard-based application. Find the well-known URL: Go to the info tab of the Asgardeo application to view the endpoints and copy the Discovery endpoint. Find the Client ID: Go to the Protocol tab of the Asgardeo application and copy the Client ID. Follow the steps below to add Asgardeo as an external IdP in Choreo: Leave the Apply to all environments checkbox selected. This allows you to use the tokens generated via this IdP to invoke APIs across all environments. Note If you want to restrict the use of tokens generated via this IdP to invoke APIs in specific environments, clear the Apply to all environments checkbox and select the necessary environments from the Environments list. Click Next. This displays the server endpoints that are useful to implement and configure authentication for your application. Now you have configured Asgardeo as an external IdP in Choreo. In organizations leveraging Microsoft Azure Active Directory (Azure AD) for identity and access management (IAM), integrating it with Choreo offers powerful API access control. This control hinges on the use of API scopes. That is, it enables the restriction of access to a designated group of users. This document guide you step-by-step to configure Azure AD as your external IdP. Before you try out this guide, be sure you have the following: Follow the steps below to add Azure AD as an IdP in Choreo: To obtain the Info Leave the Apply to all environments checkbox selected. However, if you want to restrict the use of the external IdP to a certain environment, you can select them from the Environments list. API policies are units of business logic that you can apply to modify the flow of API invocations. You can apply a policy to alter the Choreo supports a set of inbuilt mediation policies that can handle common API transformation and mediation tasks. These policies run within a single mediation service, making it straightforward to implement and manage complex mediation logic. The following inbuilt policies are available in Choreo: These inbuilt mediation policies provide flexibility to manage API requests and responses, allowing for custom transformations and logic without requiring custom code. You can easily attach one or more policies to an API proxy component implementation via the Choreo Console. If necessary, you can also rearrange or swap the policies you attach. In Choreo, when you attach a mediation policy to a proxy, the deployment is a two-step process. Deployment initiation: If the component to which you want to attach the mediation policy is new, the system creates and commits a new repository with the mediation service code based on the attached policy. This new service is called the mediation application. Deploying the API: Once the deployment initiation is complete, you can specify configuration values if any, and proceed to deploy. Choreo builds the generated mediation application and pushes the Docker image to the Docker registry. Finally, Choreo deploys the mediation application with the API Proxy. When a mediation policy is attached to a specific flow, the API invocation undergoes the following behavioral modification: In the request path, the requests that pass through the gateway reach the relevant component, and Choreo executes any attached policies to the resource's request path before sending it to the backend. In the response path, the mediation component receives response messages from the backend, and Choreo executes any mediation policies attached to the If an error occurs during the execution of policies or due to an internal error, Choreo executes the To attach a policy to the If the attached policy requires parameter configuration, on the policy pane enter the appropriate values and configure the parameters. To make a parameter a configurable variable, input the value in the To attach the policy, click Add. After attaching an API Policy, it is necessary to deploy the API for the policy to become active within its corresponding flow. To deploy the API follow the steps below: In the left navigation menu, click Deploy and then click Configure & Deploy. Choreo performs the mediation application generation step and opens the Configure & Deploy pane. In the Configure & Deploy pane, if you have any configurable variables that require values, specify appropriate values for them. Click Save & Deploy. Choreo selectively generates and builds the mediation application code during component deployment depending on specific changes. These changes include: If none of the above changes occur during deployment, Choreo skips the code generation and build process of the mediation application. Info Choreo allows you to implement an API policy as a Ballerina project and attach it to an API proxy component. Info Supported Ballerina version: 2201.5.5 To implement a policy, follow the steps given below: Alternatively, you can set the access token via the Choreo provides a template to initialize a mediation policy project with all the required configurations. The mediation policy project will be created as a Ballerina project. To create a Ballerina project for the mediation policy using Format: Example:
e.g.,
- `web: python main.py`
- `web: gunicorn --bind :8080 --workers 1 --threads 8 --timeout 0 main:app`
- `web: flask run --host=0.0.0.0`
-
- For more examples, see [Choreo samples](https://github.com/wso2/choreo-samples).
+ - python main.py
+ - gunicorn --bind :8080 --workers 1 --threads 8 --timeout 0 main:app
+ - flask run --host=0.0.0.0
=== "Ballerina"
@@ -110,22 +102,6 @@ Follow the guidelines below based on your language:
- The `Main` class should be defined in the manifest file.
- If Maven files such as `mvn.cmd` exist in the project without the `.mvn` directory, the build will fail. To ensure a successful build, you must either commit the `.mvn` directory along with any Maven files or not include any Maven files in the project if you choose not to commit the `.mvn` directory.
-
- #### Procfile
-
- A `Procfile` is a configuration file used to declare the commands that are run by your application's containers.
- If you want to customize the default entry point of the container, you can include a `Procfile` with the `web` process type in the project root directory.
- In **Java** projects, it is optional to include a `Procfile`.
-
- Here's an example `Procfile` for an application:
-
- ```
- web:
For more examples, see [Choreo samples](https://github.com/wso2/choreo-samples).
@@ -139,22 +115,6 @@ Follow the guidelines below based on your language:
| Service| [Reading Books List Service](https://github.com/wso2/choreo-samples/tree/main/reading-books-list-service-nodejs)|
| Manual Task | [Hello World Task](https://github.com/wso2/choreo-samples/tree/main/hello-world-nodejs-task)|
- #### Procfile
-
- A `Procfile` is a configuration file used to declare the commands that are run by your application's containers.
- If you want to customize the default entry point of the container, you can include a `Procfile` with the `web` process type in the project root directory.
- In **NodeJS** projects, it is optional to include a `Procfile`.
-
- Here's an example `Procfile` for an application:
-
- ```
- web:
-
For more examples, see [Choreo samples](https://github.com/wso2/choreo-samples).
=== "PHP"
@@ -168,22 +128,6 @@ Follow the guidelines below based on your language:
| Manual Task | [Hello World Task](https://github.com/wso2/choreo-samples/tree/main/hello-world-php-task)|
| Web Application | [Hello World Web Application](https://github.com/wso2/choreo-samples/tree/main/hello-world-php-webapp)|
- #### Procfile
-
- A `Procfile` is a configuration file used to declare the commands that are run by your application's containers.
- If you want to customize the default entry point of the container, you can include a `Procfile` with the `web` process type in the project root directory.
- In **PHP** projects, it is optional to include a `Procfile`.
-
- Here's an example `Procfile` for an application:
-
- ```
- web:
-
For more examples, see [Choreo samples](https://github.com/wso2/choreo-samples).
=== "Ruby"
@@ -197,23 +141,6 @@ Follow the guidelines below based on your language:
| Manual Task | [Hello World Task](https://github.com/wso2/choreo-samples/tree/main/hello-world-ruby-task)|
| Web Application | [Hello World Web Application](https://github.com/wso2/choreo-samples/tree/main/hello-world-ruby-webapp)|
- #### Procfile
-
- A `Procfile` is a configuration file used to declare the commands that are run by your application's containers.
- If you want to customize the default entry point of the container, you can include a `Procfile` with the `web` process type in the project root directory.
- In **Ruby** projects, it is optional to include a `Procfile`.
-
- Here's an example `Procfile` for an application:
-
- ```
- web:
- `web:bundle exec ruby app.rb -p 8080`
-
For more examples, see [Choreo samples](https://github.com/wso2/choreo-samples).
=== "WSO2 MI"
@@ -232,23 +159,8 @@ Follow the guidelines below based on your language:
- 8, 11, 17, 18 (OpenJDK Runtime Environment Temurin)
!!! info
- You can use this buildpack only with web applications. For other component types, use the **Java** buildpack. Additionally, if the generated artifact is a `WAR` file, it is necessary to include a **Procfile**.
-
- #### Procfile
-
- A `Procfile` is a configuration file used to declare the commands that are run by your application's containers.
- If you want to customize the default entry point of the container, you can include a `Procfile` with the `web` process type in the project root directory.
- In **Java** projects, it is optional to include a `Procfile`.
-
- Here's an example `Procfile` for an application:
-
- ```
- web:
+ You can use this buildpack only with web applications. For other component types, use the **Java** buildpack. Additionally, if the generated artifact is a `WAR` file, you must include the run command in the **Build Configurations** editor on the component's **Build** page.
e.g.,
+ `java -jar target/sample.war`
### Configure build-time environment variables
@@ -262,3 +174,13 @@ During the build process, the build-time environment variables and their values
For example, if you want to override the Maven command of the **Java** buildpack, you can use `GOOGLE_MAVEN_BUILD_ARGS` as the environment key and `clean install` as the value.
For more examples, see [Google Cloud's buildpacks documentation](https://cloud.google.com/docs/buildpacks/service-specific-configs).
+
+### Customize the Default Run Command
+
+You can configure the run command required to start the component via the **Build Configurations** editor on the component's **Build** page. This overrides the default run command provided by the buildpack. After configuring the run command, you must rebuild the component for the changes to take effect.
+
+e.g.,
+
+- java -jar target/sample.jar
+- node app.js
+- php -S 0.0.0.0:8000 index.php
diff --git a/en/docs/develop-components/develop-a-webhook.md b/en/developer-docs/docs/develop-components/develop-a-webhook.md
similarity index 100%
rename from en/docs/develop-components/develop-a-webhook.md
rename to en/developer-docs/docs/develop-components/develop-a-webhook.md
diff --git a/en/developer-docs/docs/develop-components/develop-an-api-proxy.md b/en/developer-docs/docs/develop-components/develop-an-api-proxy.md
new file mode 100644
index 0000000000..479933f61c
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/develop-an-api-proxy.md
@@ -0,0 +1,136 @@
+# Develop an API Proxy from Scratch
+
+An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, allowing you to apply essential API management features such as security policies and rate limiting.
+
+In this guide, you will:
+
+- Create an API proxy component to expose an existing API.
+- Deploy the API proxy.
+- Test the API proxy to verify its functionality.
+- Manage the API.
+- Consume the API.
+
+## Prerequisites
+
+- If you're signing in to the Choreo Console for the first time, create an organization:
+ 1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in using your preferred method.
+ 2. Enter a unique organization name. For example, `Stark Industries`.
+ 3. Read and accept the privacy policy and terms of use.
+ 4. Click **Create**.
+
+ This creates the organization and opens the **Project Home** page of the default project created for you.
+
+## Step 1: Create an API proxy
+
+To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this guide, you will specify a URL to an OpenAPI definition of a sample API.
+
+1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
+2. If you already have one or more components in your project, click **+ Create**. Otherwise, proceed to the next step.
+3. Click the **API Proxy** card. This opens the **Create an API Proxy** pane.
+4. Select **Creare from Scratch** option.
+5. Specify the following values as Proxy Metadata:
+
+ | **Field** | **Value** |
+ |-----------------|--------------------------------------------|
+ | **Context** | `department-service` |
+ | **Version** | `v1.0` |
+ | **Target** | `https://samples.choreoapps.dev/company/hr` |
+
+6. Enter following details for the Component Details:
+
+ !!! info
+ The **Component Name** field must be unique and cannot be changed after creation.
+
+ | **Field** | **Value** |
+ |---------------------------|--------------------|
+ | **Component Display Name**| `Department Service` |
+ | **Component Name** | `department-service` |
+ | **Description** | `Sample proxy for department service` |
+
+7. Click **Create**. This creates the API proxy component and takes you to the **Deploy** page.
+
+## Step 2: Define resources for the API proxy
+
+To add a new resource that retrieves a department by the department ID, follow these steps:
+
+1. In the left navigation menu, click **Develop** and then click **Resources**.
+2. Select **GET** as the **HTTP Verb** and enter `/department/{departmentId}` as the **URI Pattern**.
+3. Click **+** to add the resource.
+4. Expand the added resource and specify the following values:
+
+ | **Field** | **Value** |
+ |------------------|--------------------------------------|
+ | **Operation ID** | `findDepartment` |
+ | **Description** | `Find a department by department ID` |
+
+5. Remove the five default resources that start with `/*` by clicking the delete icon corresponding to each resource.
+6. Click **Save**.
+
+## Step 3: Deploy the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. In the **Build Area** card, click **Configure & Deploy**. This opens the **Configure & Deploy** pane.
+3. Select **External** as the API access mode and click **Deploy**. The **Development** card indicates the **Deployment Status** as **Active** when the API proxy is successfully deployed.
+
+Now you are ready to test the API proxy.
+
+## Step 4: Test the API proxy
+
+Choreo allows you to test your API proxy using either the [integrated OpenAPI Console](../../testing/test-rest-endpoints-via-the-openapi-console.md) or [cURL](../testing/test-apis-with-curl.md). In this guide, you will use the OpenAPI Console.
+
+!!! tip
+ Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API.
+
+ - Choreo automatically generates a key to test the API via the OpenAPI Console. To view the key, click the show key icon in the **Security Header** field.
+ - To disable security for the entire API or a specific resource:
+ 1. In the left navigation menu, click **Deploy**.
+ 2. Go to the **Build Area** card and click **Security Settings**.
+ 3. In the **Security Settings** pane:
+ - To disable security for the entire API, clear the **OAuth2** checkbox.
+ - To disable security for a specific resource, expand the relevant resource and turn off the **Security** toggle.
+ 4. Click **Apply**.
+
+1. In the left navigation menu, click **Test** and then click **OpenAPI Console**.
+2. Select **Development** from the environment drop-down list.
+3. Expand the `GET /department/{departmentId}` resource and click **Try it Out**.
+4. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+ This indicates that your API proxy is working as expected.
+
+## Step 5: Manage the API proxy
+
+Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. In this guide, you will apply rate limiting to the API and publish it.
+
+### Step 5.1: Apply rate limiting to the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. Go to the required environment card and click the settings icon corresponding to **CORS, Rate Limiting and Resiliency**.
+3. In the **CORS, Rate Limiting and Resiliency** pane, click **Rate Limiting** to expand the section.
+4. Select **API Level** as the **Rate Limiting Level**.
+5. Specify appropriate values for the **Request Limit** and **Time Unit** fields. You can proceed with the default values.
+6. Click **Apply**. This applies the rate limiting level to the API proxy and redeploys it.
+
+### Step 5.2: Publish the API proxy
+
+1. In the left navigation menu, click **Lifecycle** under **Manage**. This takes you to the **Lifecycle** page.
+2. Click **Publish**.
+3. In the **Publish API** dialog, click **Confirm** to proceed with publishing the API. If you want to change the display name, make the necessary changes and then click **Confirm**. This changes the API lifecycle state to **Published**.
+
+## Step 6: Invoke the API
+
+To generate credentials for the published API and invoke it via the Choreo Developer Portal, follow these steps:
+
+1. In the **Lifecycle** page, click **Go to Devportal**. This takes you to the `Department Service` in the Choreo Developer Portal.
+
+2. **Invoke the API**:
+ 1. In the Developer Portal left navigation menu, click **Try Out**.
+ 2. In the **Endpoint** list, select **Development** as the environment to try out the API.
+ 3. Click **Get Test Key** to generate an access token.
+ 4. Expand the `GET /department/{departmentId}` resource and click **Try it out**.
+ 5. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo.
\ No newline at end of file
diff --git a/en/docs/develop-components/develop-an-external-consumer.md b/en/developer-docs/docs/develop-components/develop-an-external-consumer.md
similarity index 100%
rename from en/docs/develop-components/develop-an-external-consumer.md
rename to en/developer-docs/docs/develop-components/develop-an-external-consumer.md
diff --git a/en/docs/develop-components/develop-components-using-vs-code.md b/en/developer-docs/docs/develop-components/develop-components-using-vs-code.md
similarity index 100%
rename from en/docs/develop-components/develop-components-using-vs-code.md
rename to en/developer-docs/docs/develop-components/develop-components-using-vs-code.md
diff --git a/en/docs/develop-components/develop-components-with-git.md b/en/developer-docs/docs/develop-components/develop-components-with-git.md
similarity index 100%
rename from en/docs/develop-components/develop-components-with-git.md
rename to en/developer-docs/docs/develop-components/develop-components-with-git.md
diff --git a/en/docs/develop-components/develop-integrations/develop-a-manual-task.md b/en/developer-docs/docs/develop-components/develop-integrations/develop-a-manual-task.md
similarity index 97%
rename from en/docs/develop-components/develop-integrations/develop-a-manual-task.md
rename to en/developer-docs/docs/develop-components/develop-integrations/develop-a-manual-task.md
index 7f7c01553d..248fdde8c2 100644
--- a/en/docs/develop-components/develop-integrations/develop-a-manual-task.md
+++ b/en/developer-docs/docs/develop-components/develop-integrations/develop-a-manual-task.md
@@ -134,7 +134,7 @@ In this guide, you will:
!!! info
When working on Java projects:
- - The **Run with Arguments** capability is not supported if `Procfile` is available in the project.
+ - The **Run with Arguments** feature is not supported if a `Run Command` is defined or a `Procfile` is present in the project.
- The `Main` class should be defined in the `manifest` file.
- If Maven files such as `mvn.cmd` exist in the project without the `.mvn` directory, the build will fail. To ensure a successful build, either commit the `.mvn` directory along with any Maven files or exclude Maven files if you choose not to commit the `.mvn` directory.
@@ -143,7 +143,7 @@ In this guide, you will:
!!! info
When working on NodeJS projects:
- - The **Run with Arguments** capability is not supported if `Procfile` is available in the project.
+ - The **Run with Arguments** feature is not supported if a `Run Command` is defined or a `Procfile` is present in the project.
- The project root must contain the `package.json` file with the `main` attribute defined.
=== "WSO2 MI"
diff --git a/en/docs/develop-components/develop-integrations/develop-a-scheduled-task.md b/en/developer-docs/docs/develop-components/develop-integrations/develop-a-scheduled-task.md
similarity index 100%
rename from en/docs/develop-components/develop-integrations/develop-a-scheduled-task.md
rename to en/developer-docs/docs/develop-components/develop-integrations/develop-a-scheduled-task.md
diff --git a/en/docs/develop-components/develop-integrations/develop-an-event-handler.md b/en/developer-docs/docs/develop-components/develop-integrations/develop-an-event-handler.md
similarity index 100%
rename from en/docs/develop-components/develop-integrations/develop-an-event-handler.md
rename to en/developer-docs/docs/develop-components/develop-integrations/develop-an-event-handler.md
diff --git a/en/docs/develop-components/develop-integrations/develop-an-integration-with-integration-studio.md b/en/developer-docs/docs/develop-components/develop-integrations/develop-an-integration-with-integration-studio.md
similarity index 100%
rename from en/docs/develop-components/develop-integrations/develop-an-integration-with-integration-studio.md
rename to en/developer-docs/docs/develop-components/develop-integrations/develop-an-integration-with-integration-studio.md
diff --git a/en/developer-docs/docs/develop-components/develop-mcp-servers/develop-a-mcp-server.md b/en/developer-docs/docs/develop-components/develop-mcp-servers/develop-a-mcp-server.md
new file mode 100644
index 0000000000..afffa2be7a
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/develop-mcp-servers/develop-a-mcp-server.md
@@ -0,0 +1,83 @@
+# Develop a MCP Server
+
+Choreo allows you to create and deploy MCP Server applications in Python and Node.js.
+
+In this guide, you will:
+
+- Deploy an stdio-based [github-mcp-server](https://github.com/github/github-mcp-server) in Choreo over SSE (Server-Sent Events) using a `NodeJs` buildpack.
+
+## Prerequisites
+
+1. If you're signing in to the Choreo Console for the first time, create an organization:
+ 1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in using your preferred method.
+ 2. Enter a unique organization name. For example, `Stark Industries`.
+ 3. Read and accept the privacy policy and terms of use.
+ 4. Click **Create**.
+
+ This creates the organization and opens the **Project Home** page of the default project created for you.
+
+2. Create a [GitHub Personal Access Token (PAT)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) for your account.
+
+## Step 1: Create a MCP Server component
+
+To create a mcp server component, follow these steps:
+
+1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
+2. If you already have one or more components in your project, click **+ Create**. Otherwise, proceed to the next step.
+3. Click **View All Component Types** link button.
+4. Click the **MCP Server** card.
+5. Under **MCP Server Metadata**, enter the following details:
+
+ | **Field** | **Value** |
+ |------------------------|--------------------|
+ | **Server Package** | @modelcontextprotocol/server-github |
+ | **Run Command** | npx -y @modelcontextprotocol/server-github |
+
+6. Select **NodeJs** as the buildpack.
+7. Provide component display name, name and description:
+
+ !!! info
+ The **Component Name** field must be unique and cannot be changed after creation.
+
+ | **Field** | **Value** |
+ |---------------------------|--------------------|
+ | **Component Display Name**| GitHub MCP Server |
+ | **Component Name** | github-mcp-server |
+ | **Description** | Mcp server for GitHub |
+
+8. Click **Create**. This creates the component and lists it under **Component Listing** on the project home page.
+
+You have successfully created the server. The initial build has been triggered. Please wait until it completes.
+If you need to rebuild the component later, follow the steps below.
+
+## Step 2: Build
+
+1. On the project home page, click on the `GitHub Mcp Server` component you created. This takes you to the component overview page.
+2. In the left navigation menu, click **Build**.
+3. On the **Build** page, click **Build Latest**.
+
+ !!! note
+ The build process may take some time. You can track progress in the **Build Details** pane. Once complete, the build status changes to **Success**.
+
+Now that you have built the component, it's time to deploy the mcp server.
+
+## Step 3: Deploy
+
+1. In the left navigation menu, click **Deploy**.
+2. On the **Set Up** card, click **Configure & Deploy**.
+3. In the **Environment Configurations** pane, click **Add a Configuration** and add following environment variables in the table. Then tick **Mark as a Secret** and save the configuration by clicking **Next** button.
+
+ | **Name** | **Value** |
+ |---------------------------|--------------------|
+ | **GITHUB_PERSONAL_ACCESS_TOKEN**| YOUR GITHUB PAT |
+
+4. In the **File Mount** pane, click **Next** to skip this step.
+5. Review the **Endpoint Details** and click **Deploy**.
+
+ !!! note
+ Deploying the service component may take some time. Once deployed, the **Development** environment card indicates the **Deployment Status** as **Active**.
+
+Once you have successfully deployed the service, you can test your server. You can view the invoke URL details from the **Test** tab in left navigation menu.
+
+!!! info
+ The path for SSE subscription is **/sse**, and the path for messages is **/messages**.
diff --git a/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-a-github-repository-source.md b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-a-github-repository-source.md
new file mode 100644
index 0000000000..2e4f29766f
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-a-github-repository-source.md
@@ -0,0 +1,166 @@
+# Develop an API Proxy from a GitHub Repository Source
+
+An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, allowing you to apply essential API management features such as security policies and rate limiting.
+
+In this guide, you will:
+
+- Create an API proxy component to expose an existing API.
+- Deploy the API proxy.
+- Test the API proxy to verify its functionality.
+- Manage the API.
+- Consume the API.
+
+## Prerequisites
+
+1. If you're signing in to the Choreo Console for the first time, create an organization:
+ 1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in using your preferred method.
+ 2. Enter a unique organization name. For example, `Stark Industries`.
+ 3. Read and accept the privacy policy and terms of use.
+ 4. Click **Create**.
+
+ This creates the organization and opens the **Project Home** page of the default project created for you.
+
+2. Fork the [Choreo samples repository](https://github.com/wso2/choreo-samples/), which contains the [sample proxy source](https://github.com/wso2/choreo-samples/tree/main/department-api-proxy-from-github).
+
+## Step 1: Create an API proxy
+
+You can create an API proxy either by selecting the source from a GitHub repository, uploading an OpenAPI specification file, or providing an OpenAPI specification URL. This guide demonstrates how to create an API proxy using a GitHub repository as the source.
+
+1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
+2. If you already have one or more components in your project, click **+ Create**. Otherwise, proceed to the next step.
+3. Click the **API Proxy** card. This opens the **Create an API Proxy** pane.
+
+4. Click on **Authorize With GitHub** card under **Connect a Git Repository** section to connect your GitHub account.
+ - If you haven’t connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you forked in the prerequisites section to install the [Choreo GitHub App](https://github.com/marketplace/choreo-apps).
+
+ !!! note
+ The **Choreo GitHub App** requires the following permissions:
+ - Read and write access to code and pull requests.
+ - Read access to issues and metadata.
+
+ You can [revoke access](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-authorized-integrations#reviewing-your-authorized-github-apps) if needed. Write access is only used for sending pull requests; Choreo will not push changes directly to your repository.
+
+5. Enter the following repository details:
+
+ | **Field** | **Value** |
+ |------------------------|--------------------|
+ | **Organization** | Your GitHub account|
+ | **Repository** | choreo-samples |
+ | **Branch** | **`main`** |
+ | **API Directory** | /department-api-proxy-from-github |
+
+ !!! note
+ To select the relevant directory, click on the **Edit** action next to the **API Directory** input field. Then, enter `department-api-proxy-from-github` as the directory name to quickly search and locate the correct directory.
+
+6. Specify the following values as Proxy Metadata:
+
+ !!! info
+ The **Context** field must be unique and cannot be changed after creation.**Version** and **Target** are mandatory fields. **Target** can be changed at any time after the creation.
+
+ | **Field** | **Value** |
+ |-----------------|--------------------------------------------|
+ | **Context** | `department-service` |
+ | **Version** | `v1.0` |
+ | **Target** | `https://samples.choreoapps.dev/company/hr`|
+
+7. Specify the following values as Component Details:
+
+ !!! info
+ The **Component Name** field must be unique and cannot be changed after creation. This value is automatically generated, but you can edit it if necessary.
+ **Component Display Name** is a required field.
+
+ | **Field** | **Value** |
+ |-----------------|--------------------------------------------|
+ | **Component Display Name**| `Department Service` |
+ | **Component Name** | `department-service` |
+ | **Description** | `This is a sample proxy for department service` |
+
+8. Click **Create**. This creates the API proxy component and takes you to the **Build** page.
+
+!!! note
+ When you create an API proxy from a GitHub repository source, the GitHub source serves as the single source of truth. Therefore, any modifications, such as adding or deleting resources, must be made through the GitHub repository.
+
+## Step 2: Build
+
+!!! info
+ The initial build starts automatically when you create the API proxy, and you will be redirected to the **Build** page. In this case, you can skip the steps below. If you need to manually trigger a build later, follow these steps.
+
+1. On the project home page, click on the `Department Service` component you created. This takes you to the component overview page.
+2. In the left navigation menu, click **Build**.
+3. On the **Build** page, click **Build Latest**.
+
+!!! note
+ The build process may take some time. You can track progress in the **Build Details** pane. Once complete, the build status changes to **Success**.
+
+## Step 3: Deploy the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. In the **Build Area** card, click **Configure & Deploy**. This opens the **Configure & Deploy** pane.
+3. Select **External** as the **API Access Mode** and click **Deploy**. The **Development** card indicates the **Deployment Status** as **Active** when the API proxy is successfully deployed.
+
+Now you are ready to test the API proxy.
+
+## Step 4: Test the API proxy
+
+Choreo allows you to test your API proxy using either the [integrated OpenAPI Console](../../testing/test-rest-endpoints-via-the-openapi-console.md) or [cURL](../../testing/test-apis-with-curl.md). In this guide, you will use the OpenAPI Console.
+
+!!! tip
+ Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API.
+
+ - Choreo automatically generates a key to test the API via the OpenAPI Console. To view the key, click the show key icon in the **Security Header** field.
+ - To disable security for the entire API or a specific resource:
+ 1. In the left navigation menu, click **Deploy**.
+ 2. Go to the **Build Area** card and click **Security Settings**.
+ 3. In the **Security Settings** pane:
+ - To disable security for the entire API, clear the **OAuth2** checkbox.
+ - To disable security for a specific resource, expand the relevant resource and turn off the **Security** toggle.
+ 4. Click **Apply**.
+ 5. Then click **Deploy**.
+
+1. In the left navigation menu, click **Test** and then click **OpenAPI Console**.
+2. Select **Development** from the environment drop-down list.
+3. Expand the `GET /department/{departmentId}` resource and click **Try it Out**.
+4. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+ This indicates that your API proxy is working as expected.
+
+## Step 5: Manage the API proxy
+
+Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. In this guide, you will apply rate limiting to the API and publish it.
+
+### Step 5.1: Apply rate limiting to the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. Go to the required environment card and click the settings icon corresponding to **API Configuration**.
+3. In the **CORS, Rate Limiting and Resiliency** pane, click **Rate Limiting** to expand the section.
+4. Select **API Level** as the **Rate Limiting Level**.
+5. Specify appropriate values for the **Request Limit** and **Time Unit** fields. You can proceed with the default values.
+6. Click **Apply**. This applies the rate limiting level to the API proxy and redeploys it.
+
+### Step 5.2: Publish the API proxy
+
+**Publishing** makes your API available in the **Choreo Developer Portal**, enabling application developers to access and use it.
+
+1. In the left navigation menu, click **Lifecycle** under **Manage**. This takes you to the **Lifecycle** page.
+2. Click **Publish**.
+3. In the **Publish API** dialog, click **Confirm** to proceed with publishing the API. If you want to change the display name, make the necessary changes and then click **Confirm**. This changes the API lifecycle state to **Published**.
+
+
+## Step 6: Invoke the API From DevPortal
+
+To generate credentials for the published API and invoke it via the Choreo Developer Portal, follow these steps:
+
+1. In the **Lifecycle** page, click **Go to Devportal**. This takes you to the `Department Service` in the Choreo Developer Portal.
+
+2. Invoke the API:
+ 1. In the Developer Portal left navigation menu, click **Try Out**.
+ 2. In the **Endpoint** list, select **Development** as the environment to try out the API.
+ 3. Click **Get Test Key** to generate an access token.
+ 4. Expand the `GET /department/{departmentId}` resource and click **Try it out**.
+ 5. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo.
diff --git a/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-an-open-api-specification.md b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-an-open-api-specification.md
new file mode 100644
index 0000000000..6ba1adf4aa
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-an-open-api-specification.md
@@ -0,0 +1,131 @@
+# Develop an API Proxy from Open API Document
+
+An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, allowing you to apply essential API management features such as security policies and rate limiting.
+
+In this guide, you will:
+
+- Create an API proxy component to expose an existing API.
+- Deploy the API proxy.
+- Test the API proxy to verify its functionality.
+- Manage the API.
+- Consume the API.
+
+## Prerequisites
+
+- If you're signing in to the Choreo Console for the first time, create an organization:
+ 1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in using your preferred method.
+ 2. Enter a unique organization name. For example, `Stark Industries`.
+ 3. Read and accept the privacy policy and terms of use.
+ 4. Click **Create**.
+
+ This creates the organization and opens the **Project Home** page of the default project created for you.
+
+## Step 1: Create an API proxy
+
+To create an API proxy, you can either upload an OpenAPI document or provide a hosted OpenAPI document's URL. In this guide, you will specify a URL to an OpenAPI definition of a sample API.
+
+1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
+2. If you already have one or more components in your project, click **+ Create**. Otherwise, proceed to the next step.
+3. Click the **API Proxy** card. This opens the **Create an API Proxy** pane.
+4. Select **Upload API Specification** option.
+5. Click on **Try with sample URL** to go ahead with the sample Open API Document.
+
+
+6. Specify the following values as Proxy Metadata:
+
+ !!! note
+ While most values are auto-generated from the specification, the context value has been explicitly set to **petstore** to enhance clarity
+
+
+ | **Field** | **Value** |
+ |-----------------|--------------------------------------------|
+ | **Context** | `petstore` |
+ | **Version** | `v1.0` |
+ | **Target** | `https://petstore3.swagger.io/api/v3` |
+
+7. Enter following details for the Component Details:
+
+ !!! info
+ The **Component Name** field must be unique and cannot be changed after creation.
+
+ | **Field** | **Value** |
+ |---------------------------|--------------------|
+ | **Component Display Name**| `Petstore Service` |
+ | **Component Name** | `pet-store-service` |
+ | **Description** | `Sample proxy for Petstore service` |
+
+8. Click **Create**. This creates the API proxy component and takes you to the **Deploy** page.
+
+## Step 2: Deploy the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. In the **Build Area** card, click **Configure & Deploy**. This opens the **Configure & Deploy** pane.
+3. Select **External** as the API access mode and click **Deploy**. The **Development** card indicates the **Deployment Status** as **Active** when the API proxy is successfully deployed.
+
+Now you are ready to test the API proxy.
+
+## Step 3: Test the API proxy
+
+Choreo allows you to test your API proxy using either the [integrated OpenAPI Console](../../testing/test-rest-endpoints-via-the-openapi-console.md) or [cURL](../../testing/test-apis-with-curl.md). In this guide, you will use the OpenAPI Console.
+
+!!! tip
+ Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API.
+
+ - Choreo automatically generates a key to test the API via the OpenAPI Console. To view the key, click the show key icon in the **Security Header** field.
+ - To disable security for the entire API or a specific resource:
+ 1. In the left navigation menu, click **Deploy**.
+ 2. Go to the **Build Area** card and click **Security Settings**.
+ 3. In the **Security Settings** pane:
+ - To disable security for the entire API, clear the **OAuth2** checkbox.
+ - To disable security for a specific resource, expand the relevant resource and turn off the **Security** toggle.
+ 4. Click **Apply**.
+ 5. Then click **Deploy**.
+
+1. In the left navigation menu, click **Test** and then click **OpenAPI Console**.
+2. Select **Development** from the environment drop-down list.
+3. Expand the `GET /pet/findByStatus` resource and click **Try it Out**.
+4. Select the status **available** from the dropdown and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+ This indicates that your API proxy is working as expected.
+
+## Step 4: Manage the API proxy
+
+Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. In this guide, you will apply rate limiting to the API and publish it.
+
+### Step 4.1: Apply rate limiting to the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. Go to the required environment card and click the settings icon corresponding to **CORS, Rate Limiting and Resiliency**.
+3. In the **CORS, Rate Limiting and Resiliency** pane, click **Rate Limiting** to expand the section.
+4. Select **API Level** as the **Rate Limiting Level**.
+5. Specify appropriate values for the **Request Limit** and **Time Unit** fields. You can proceed with the default values.
+6. Click **Apply**. This applies the rate limiting level to the API proxy and redeploys it.
+
+### Step 4.2: Publish the API proxy
+
+
+ **Publishing** makes your API available in the **Choreo Developer Portal**, enabling application developers to access and use it.
+
+1. In the left navigation menu, click **Lifecycle** under **Manage**. This takes you to the **Lifecycle** page.
+2. Click **Publish**.
+3. In the **Publish API** dialog, click **Confirm** to proceed with publishing the API. If you want to change the display name, make the necessary changes and then click **Confirm**. This changes the API lifecycle state to **Published**.
+
+
+## Step 5: Invoke the API From DevPortal
+
+To generate credentials for the published API and invoke it via the Choreo Developer Portal, follow these steps:
+
+1. In the **Lifecycle** page, click **Go to Devportal**. This takes you to the `Petstore Service` in the Choreo Developer Portal.
+
+2. Invoke the API:
+ 1. In the Developer Portal left navigation menu, click **Try Out**.
+ 2. In the **Endpoint** list, select **Development** as the environment to try out the API.
+ 3. Click **Get Test Key** to generate an access token.
+ 4. Expand the `GET /pet/findByStatus` resource and click **Try it out**.
+ 5. Select the status **available** from the dropdown and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo.
\ No newline at end of file
diff --git a/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-scratch.md b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-scratch.md
new file mode 100644
index 0000000000..c6c057c1d6
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/develop-proxy/develop-an-api-proxy-from-scratch.md
@@ -0,0 +1,139 @@
+# Develop an API Proxy from Scratch
+
+An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, allowing you to apply essential API management features such as security policies and rate limiting.
+
+In this guide, you will:
+
+- Create an API proxy component to expose an existing API.
+- Deploy the API proxy.
+- Test the API proxy to verify its functionality.
+- Manage the API.
+- Consume the API.
+
+## Prerequisites
+
+- If you're signing in to the Choreo Console for the first time, create an organization:
+ 1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in using your preferred method.
+ 2. Enter a unique organization name. For example, `Stark Industries`.
+ 3. Read and accept the privacy policy and terms of use.
+ 4. Click **Create**.
+
+ This creates the organization and opens the **Project Home** page of the default project created for you.
+
+## Step 1: Create an API proxy
+
+To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this guide, you will specify a URL to an OpenAPI definition of a sample API.
+
+1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
+2. If you already have one or more components in your project, click **+ Create**. Otherwise, proceed to the next step.
+3. Click the **API Proxy** card. This opens the **Create an API Proxy** pane.
+4. Select **Creare from Scratch** option.
+5. Specify the following values as Proxy Metadata:
+
+ | **Field** | **Value** |
+ |-----------------|--------------------------------------------|
+ | **Context** | `department-service` |
+ | **Version** | `v1.0` |
+ | **Target** | `https://samples.choreoapps.dev/company/hr` |
+
+6. Enter following details for the Component Details:
+
+ !!! info
+ The **Component Name** field must be unique and cannot be changed after creation.
+
+ | **Field** | **Value** |
+ |---------------------------|--------------------|
+ | **Component Display Name**| `Department Service` |
+ | **Component Name** | `department-service` |
+ | **Description** | `Sample proxy for department service` |
+
+7. Click **Create**. This creates the API proxy component and takes you to the **Deploy** page.
+
+## Step 2: Define resources for the API proxy
+
+To add a new resource that retrieves a department by the department ID, follow these steps:
+
+1. In the left navigation menu, click **Develop** and then click **Resources**.
+2. Select **GET** as the **HTTP Verb** and enter `/department/{departmentId}` as the **URI Pattern**.
+3. Click **+** to add the resource.
+4. Expand the added resource and specify the following values:
+
+ | **Field** | **Value** |
+ |------------------|--------------------------------------|
+ | **Operation ID** | `findDepartment` |
+ | **Description** | `Find a department by department ID` |
+
+5. Remove the five default resources that start with `/*` by clicking the delete icon corresponding to each resource.
+6. Click **Save**.
+
+## Step 3: Deploy the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. In the **Build Area** card, click **Configure & Deploy**. This opens the **Configure & Deploy** pane.
+3. Select **External** as the API access mode and click **Deploy**. The **Development** card indicates the **Deployment Status** as **Active** when the API proxy is successfully deployed.
+
+Now you are ready to test the API proxy.
+
+## Step 4: Test the API proxy
+
+Choreo allows you to test your API proxy using either the [integrated OpenAPI Console](../../testing/test-rest-endpoints-via-the-openapi-console.md) or [cURL](../../testing/test-apis-with-curl.md). In this guide, you will use the OpenAPI Console.
+
+!!! tip
+ Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API.
+
+ - Choreo automatically generates a key to test the API via the OpenAPI Console. To view the key, click the show key icon in the **Security Header** field.
+ - To disable security for the entire API or a specific resource:
+ 1. In the left navigation menu, click **Deploy**.
+ 2. Go to the **Build Area** card and click **Configure & Deploy**.
+ 3. In the **Configure & Deploy** pane:
+ - To disable security for the entire API, clear the **OAuth2** checkbox.
+ - To disable security for a specific resource, turn off the **Security** toggle in the relevant resource.
+ 4. Click **Deploy**.
+
+1. In the left navigation menu, click **Test** and then click **OpenAPI Console**.
+2. Select **Development** from the environment drop-down list.
+3. Expand the `GET /department/{departmentId}` resource and click **Try it Out**.
+4. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+ This indicates that your API proxy is working as expected.
+
+## Step 5: Manage the API proxy
+
+Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. In this guide, you will apply rate limiting to the API and publish it.
+
+### Step 5.1: Apply rate limiting to the API proxy
+
+1. In the left navigation menu, click **Deploy**.
+2. Go to the required environment card and click the settings icon corresponding to **CORS, Rate Limiting and Resiliency**.
+3. In the **CORS, Rate Limiting and Resiliency** pane, click **Rate Limiting** to expand the section.
+4. Select **API Level** as the **Rate Limiting Level**.
+5. Specify appropriate values for the **Request Limit** and **Time Unit** fields. You can proceed with the default values.
+6. Click **Apply**. This applies the rate limiting level to the API proxy and redeploys it.
+
+### Step 5.2: Publish the API proxy
+
+**Publishing** makes your API available in the **Choreo Developer Portal**, enabling application developers to access and use it.
+
+1. In the left navigation menu, click **Lifecycle** under **Manage**. This takes you to the **Lifecycle** page.
+2. Click **Publish**.
+3. In the **Publish API** dialog, click **Confirm** to proceed with publishing the API. If you want to change the display name, make the necessary changes and then click **Confirm**. This changes the API lifecycle state to **Published**.
+
+
+## Step 6: Invoke the API From DevPortal
+
+To generate credentials for the published API and invoke it via the Choreo Developer Portal, follow these steps:
+
+1. In the **Lifecycle** page, click **Go to Devportal**. This takes you to the `Department Service` in the Choreo Developer Portal.
+
+2. Invoke the API:
+ 1. In the Developer Portal left navigation menu, click **Try Out**.
+ 2. In the **Endpoint** list, select **Development** as the environment to try out the API.
+ 3. Click **Get Test Key** to generate an access token.
+ 4. Expand the `GET /department/{departmentId}` resource and click **Try it out**.
+ 5. Enter `1` as the **departmentId** and click **Execute**. You will see a response similar to the following:
+
+ {.cInlineImage-full}
+
+Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo.
\ No newline at end of file
diff --git a/en/docs/develop-components/develop-services/develop-a-ballerina-service.md b/en/developer-docs/docs/develop-components/develop-services/develop-a-ballerina-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/develop-a-ballerina-service.md
rename to en/developer-docs/docs/develop-components/develop-services/develop-a-ballerina-service.md
diff --git a/en/docs/develop-components/develop-services/develop-a-service-with-docker.md b/en/developer-docs/docs/develop-components/develop-services/develop-a-service-with-docker.md
similarity index 100%
rename from en/docs/develop-components/develop-services/develop-a-service-with-docker.md
rename to en/developer-docs/docs/develop-components/develop-services/develop-a-service-with-docker.md
diff --git a/en/docs/develop-components/develop-services/develop-a-service.md b/en/developer-docs/docs/develop-components/develop-services/develop-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/develop-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/develop-a-service.md
diff --git a/en/docs/develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service.md
diff --git a/en/docs/develop-components/develop-services/expose-a-grpc-endpoint-via-a-service.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-grpc-endpoint-via-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-grpc-endpoint-via-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-grpc-endpoint-via-a-service.md
diff --git a/en/docs/develop-components/develop-services/expose-a-prism-based-mock-server-using-an-openapi-specification.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-prism-based-mock-server-using-an-openapi-specification.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-prism-based-mock-server-using-an-openapi-specification.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-prism-based-mock-server-using-an-openapi-specification.md
diff --git a/en/docs/develop-components/develop-services/expose-a-tcp-server-via-a-service.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-tcp-server-via-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-tcp-server-via-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-tcp-server-via-a-service.md
diff --git a/en/docs/develop-components/develop-services/expose-a-udp-server-via-a-service.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-udp-server-via-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-udp-server-via-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-udp-server-via-a-service.md
diff --git a/en/docs/develop-components/develop-services/expose-a-websocket-endpoint-via-a-service.md b/en/developer-docs/docs/develop-components/develop-services/expose-a-websocket-endpoint-via-a-service.md
similarity index 100%
rename from en/docs/develop-components/develop-services/expose-a-websocket-endpoint-via-a-service.md
rename to en/developer-docs/docs/develop-components/develop-services/expose-a-websocket-endpoint-via-a-service.md
diff --git a/en/docs/develop-components/develop-services/service-component-overview.md b/en/developer-docs/docs/develop-components/develop-services/service-component-overview.md
similarity index 100%
rename from en/docs/develop-components/develop-services/service-component-overview.md
rename to en/developer-docs/docs/develop-components/develop-services/service-component-overview.md
diff --git a/en/docs/develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application.md b/en/developer-docs/docs/develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application.md
similarity index 100%
rename from en/docs/develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application.md
rename to en/developer-docs/docs/develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application.md
diff --git a/en/docs/develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication.md b/en/developer-docs/docs/develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication.md
similarity index 100%
rename from en/docs/develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication.md
rename to en/developer-docs/docs/develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication.md
diff --git a/en/docs/develop-components/integrate-unit-tests-into-the-build-pipeline.md b/en/developer-docs/docs/develop-components/integrate-unit-tests-into-the-build-pipeline.md
similarity index 100%
rename from en/docs/develop-components/integrate-unit-tests-into-the-build-pipeline.md
rename to en/developer-docs/docs/develop-components/integrate-unit-tests-into-the-build-pipeline.md
diff --git a/en/docs/develop-components/manage-component-source-configurations.md b/en/developer-docs/docs/develop-components/manage-component-source-configurations.md
similarity index 68%
rename from en/docs/develop-components/manage-component-source-configurations.md
rename to en/developer-docs/docs/develop-components/manage-component-source-configurations.md
index e5acb74eb3..153b28b88d 100644
--- a/en/docs/develop-components/manage-component-source-configurations.md
+++ b/en/developer-docs/docs/develop-components/manage-component-source-configurations.md
@@ -27,6 +27,183 @@ The source configuration file must be committed to your repository within the `.
Click the respective tab to view the structure for your current configuration file version:
+=== "Version 1.2"
+
+ ``` yaml
+ # +required The configuration file schema version
+ schemaVersion: 1.2
+
+ # +optional Incoming connection details for the component
+ endpoints:
+ # +required Unique name for the endpoint.
+ # This name will be used when generating the managed API
+ - name: greeter-sample
+ # +optional Display name for the endpoint.
+ displayName: Go Greeter Sample
+ # +required Service section has the user service endpoint details
+ service:
+ # +optional Context (base path) of the API that gets exposed via the endpoint.
+ basePath: /greeting-service
+ # +required Numeric port value that gets exposed via the endpoint
+ port: 9090
+ # +required Type of traffic that the endpoint is accepting.
+ # Allowed values: REST, GraphQL, WS, GRPC, TCP, UDP.
+ type: REST
+ # +optional Network level visibilities of the endpoint.
+ # Accepted values: Project|Organization|Public(Default).
+ networkVisibilities:
+ - Public
+ - Organization
+ # +optional Path to the schema definition file. Defaults to wild card route if not provided
+ # This is only applicable to REST or WS endpoint types.
+ # The path should be relative to the docker context.
+ schemaFilePath: openapi.yaml
+
+ # +optional Outgoing connection details for the component.
+ dependencies:
+ # +optional Defines the connection references from the Internal Marketplace.
+ connectionReferences:
+ # +required Name of the connection.
+ - name: hr-connection
+ # +required service identifer of the dependent component.
+ resourceRef: service:/HRProject/UserComponent/v1/ad088/PUBLIC
+
+ # +optional Defines runtime configurations
+ configurations:
+ # +optional List of environment variables to be injected into the component.
+ env:
+ # +required Name of the environment variable
+ - name: HR_SERVICE_URL
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required Choreo connection value source
+ connectionRef:
+ # +required Choreo connection name to refer the value from
+ name: hr-connection
+ # +required Choreo connection configuration key to refer the value from
+ key: ServiceURL
+ - name: DB_USER
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required config form value source
+ configForm:
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: DB User
+ # +optional default value is true if not specified
+ required: false
+ # +optional default value is string if not specified
+ # Allowed types - string, number, boolean, secret
+ type: string
+ # +optional List of files to be injected into the component from config form
+ file:
+ # +required name of the file
+ - name: application.yaml
+ # +required path to mount the file at
+ mountPath: /src/resources
+ # +required file type
+ # Supported types - yaml, json and toml
+ type: yaml
+ # +required define keys of the file
+ values:
+ # keys of the file
+ # +required at least one key
+ - name: version
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required config form value source
+ configForm:
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: Version
+ # +optional default value is string if not specified
+ # Allowed types - string, number, boolean, secret, object, array
+ type: number
+ ```
+
+ The descriptor-based approach of the `component.yaml` file simplifies and streamlines endpoint and connection configuration management. The use of versioned schemas ensures backward compatibility, providing a seamless transition with future updates.
+
+ You can define the following root-level configurations via the `component.yaml` file:
+
+ | Configuration | Required | Description |
+ |----------------------|--------------|--------------------------------------------------------------------------|
+ | **schemaVersion** | Required | The version of the `component.yaml` file. Defaults to the latest version.|
+ | **endpoints** | Optional | The list of endpoint configurations. |
+ | **dependencies** | Optional | The list of dependency configurations. |
+ | **configurations** | Optional | The runtime configuration definitions. |
+
+ ### Endpoint configurations
+ In the `endpoints` section of the `component.yaml` file, you can define multiple service endpoint configurations. Each endpoint must have a unique name and the required fields specified in the schema overview.
+
+ !!! tip "Why have a unique name?"
+ When you define multiple endpoints, the `endpoint.name` is appended to the Choreo-generated URL. A unique name ensures the endpoint is easily recognizable and readable within the URL.
+
+ | Configuration | Required | Description |
+ |----------------------|--------------|---------------------------------------------------------------------------------------------------------|
+ | **name** | Required | A unique identifier for the endpoint within the service component. Avoid using excessively long names. |
+ | **displayName** | Optional | A display name for the endpoint. |
+ | **service** | Required | Service details for the endpoint. |
+ | **.basePath** | Required | The base path of the API exposed via this endpoint. |
+ | **.port** | Required | The numeric port value exposed via this endpoint. |
+ | **type** | Required | The type of traffic the endpoint accepts. For example, `REST`, `GraphQL`, `WS`, `gRPC`, `UDP`, or `TCP`.|
+ | **networkVisibilities** | Required | The network-level visibility of the endpoint. For example, project, organization, or public. |
+ | **schemaFilePath** | Required | The file path to the swagger definition or AsyncAPI 2.0 specification file. Defaults to the wildcard route if not specified. This field should be a relative path to the project path when using **Java**, **Python**, **NodeJS**, **Go**, **PHP**, **Ruby**, or **WSO2 MI** buildpacks. For REST or WebSocket endpoint types, when using the **Ballerina** or **Dockerfile** buildpack, the path should be relative to the component root or Docker context. |
+
+ ### Dependency configurations
+
+ In the `dependencies` section of the `component.yaml` file, you can define multiple connection configurations under `dependencies.connectionReferences`. You can use the connection reference generated in the inline developer guide when creating a connection. For instructions on copying [connection configurations](https://wso2.com/choreo/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service/), see the inline developer guide displayed during connection creation.
+
+ You must include the following configurations in the `dependencies.connectionReferences` schema:
+
+ | Configuration | Required | Description |
+ |----------------------|--------------|----------------------------------------------------------------------------------|
+ | **name** | Required | The name given to the connection. |
+ | **resourceRef** | Required | A unique, human-readable identifier for the service you are connecting. |
+
+
+ !!! note
+ Choreo automatically generates connection configurations when you create a connection. The properties such as **name** and **resourceRef** are automatically generated. The configurations required to establish the connection will be injected into Choreo-defined environment variables.
+
+ To use custom environment variable names instead of Choreo's default ones, add the dependency as a `serviceReference` in your `component.yaml v1.1` file. You can copy the `serviceReference` section from the `component.yaml v1.0` tab and paste it under `dependencies` in your `component.yaml v1.1` file, which maintains backward compatibility with the v1.0 format.
+
+ ### Runtime configurations
+ In the `configurations` section of the `component.yaml` file, you can define runtime configurations for the component. These configurations currently support defining configurations shown in the configuration form and environment variable injection related to dependencies.
+
+ #### Environment variable injection related to dependencies
+
+ | Configuration | Required | Description |
+ |-------------------------------|--------------|-----------------------------------------------------------------------------------|
+ | **env** | Optional | An array of environment variable configurations. |
+ | **name** | Required | A unique name for the environment variable, starting with a letter or an underscore, and containing only letters, numbers, or underscores. |
+ | **valueFrom** | Required | The source of the environment variable value. |
+ | **connectionRef** | Required | Connection reference value source definition. |
+ | **name** | Required | The name of the Choreo connection to reference the value from. |
+ | **key** | Required | The Choreo connection configuration key to reference the value from. For details on available keys, see [connection configurations](https://wso2.com/choreo/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service/) or the inline developer guide. |
+
+ !!! note
+ Runtime configurations are supported starting from `component.yaml v1.1`.
+
+ When an environment variable value is specified using `connectionRef`, the connection's environment variable is renamed to the environment variable name defined in the `configurations` section. For example, in the sample `component.yaml` file given above, the `CHOREO_HR_CONNECTION_SERVICEURL` variable in the `hr-connection` is renamed to `HR_SERVICE_URL`.
+
+ #### Configuration Form
+
+ | Configuration | Required | Description |
+ |-------------------------------|--------------|-----------------------------------------------------------------------------------|
+ | **env** | Optional | An array of environment variable configurations. |
+ | **name** | Required | A unique name for the environment variable, starting with a letter or an underscore, and containing only letters, numbers, or underscores. |
+ | **file** | Optional | An array of file configurations. |
+ | **mountPath** | Required | Path that file to be mounted in the container |
+ | **values** | Required | Required under file section. File key-values definition |
+ | **valueFrom** | Required | The source of the configuration form. |
+ | **configForm** | Required | Configuration form value source definition |
+
+ Refer [use configuration form](./use-configuration-form.md) for more details on defining configurations in configuration form.
+
+ !!! note
+ Configuration form is supported starting from component.yaml v1.2.
+
+
=== "Version 1.1"
``` yaml
@@ -127,14 +304,14 @@ Click the respective tab to view the structure for your current configuration fi
!!! note
Choreo automatically generates connection configurations when you create a connection. The properties such as **name** and **resourceRef** are automatically generated. The configurations required to establish the connection will be injected into Choreo-defined environment variables.
- To use custom environment variable names instead of Choreo's default ones, add the dependency as a `serviceReference` in your `component.yaml v1.1` file. You can copy the `serviceReference` section from the `component.yaml v1.0` tab and paste it under `dependencies` in your `component.yaml v1.1` file, which maintains backward compatibility with the v1.0 format.
+ If you'd like to use custom environment variable names instead of the default Choreo-defined ones, you can rename them in the `configurations` section of the `component.yaml v1.1` file.
### Runtime configurations
In the `configurations` section of the `component.yaml` file, you can define runtime configurations for the component. These configurations currently support environment variable injection related to dependencies.
| Configuration | Required | Description |
|-------------------------------|--------------|-----------------------------------------------------------------------------------|
- | **env** | Optional | An array of env variable configurations. |
+ | **env** | Optional | An array of environment variable configurations. |
| **name** | Required | A unique name for the environment variable, starting with a letter or an underscore, and containing only letters, numbers, or underscores. |
| **valueFrom** | Required | The source of the environment variable value. |
| **connectionRef** | Required | Connection reference value source definition. |
diff --git a/en/docs/develop-components/manage-deployment-tracks-for-choreo-components.md b/en/developer-docs/docs/develop-components/manage-deployment-tracks-for-choreo-components.md
similarity index 100%
rename from en/docs/develop-components/manage-deployment-tracks-for-choreo-components.md
rename to en/developer-docs/docs/develop-components/manage-deployment-tracks-for-choreo-components.md
diff --git a/en/docs/develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project.md b/en/developer-docs/docs/develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project.md
similarity index 100%
rename from en/docs/develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project.md
rename to en/developer-docs/docs/develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project.md
diff --git a/en/docs/develop-components/sharing-and-reusing/create-a-connection.md b/en/developer-docs/docs/develop-components/sharing-and-reusing/create-a-connection.md
similarity index 94%
rename from en/docs/develop-components/sharing-and-reusing/create-a-connection.md
rename to en/developer-docs/docs/develop-components/sharing-and-reusing/create-a-connection.md
index 22c11e6946..cb71ee1936 100644
--- a/en/docs/develop-components/sharing-and-reusing/create-a-connection.md
+++ b/en/developer-docs/docs/develop-components/sharing-and-reusing/create-a-connection.md
@@ -17,7 +17,7 @@ To create a connection to a service or a database, follow the step-by-step instr
- **Project Connection**: Select an organization and a project in that organization.
- **Component Connection**: Select an organization, a project in that organization, and a component in the selected project.
- 2. In the left navigation menu, click **Dependencies** and then **Connections**. This page lists all the existing connections.
+ 2. In the left navigation menu, click **Connections**. This page lists all the existing connections.
3. Click **+Create**. This opens the Marketplace view where you can browse and search for services or databases.
4. Click the **Services** tab. You can search and apply filters to efficiently find a service.
5. Click on the service you want to connect to.
@@ -57,7 +57,7 @@ To create a connection to a service or a database, follow the step-by-step instr
- **Project Connection**: Select an organization and a project in that organization.
- **Component Connection**: Select an organization, a project in that organization, and a component in the selected project.
- 2. In the left navigation menu, click **Dependencies** and then **Connections**. This page lists all the existing connections.
+ 2. In the left navigation menu, click **Connections**. This page lists all the existing connections.
3. Click **+Create**. This opens the Marketplace view where you can browse and search for services or databases.
4. Click the **Databases** tab. You can search and apply filters to efficiently find a database.
5. Click on the database you want to connect to.
diff --git a/en/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service.md b/en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service.md
similarity index 100%
rename from en/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service.md
rename to en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-service.md
diff --git a/en/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-web-application.md b/en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-web-application.md
similarity index 100%
rename from en/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-web-application.md
rename to en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-connection-in-your-web-application.md
diff --git a/en/docs/develop-components/sharing-and-reusing/use-a-database-connection-in-your-component.md b/en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-database-connection-in-your-component.md
similarity index 100%
rename from en/docs/develop-components/sharing-and-reusing/use-a-database-connection-in-your-component.md
rename to en/developer-docs/docs/develop-components/sharing-and-reusing/use-a-database-connection-in-your-component.md
diff --git a/en/docs/develop-components/submit-and-manage-workflow-approval-requests.md b/en/developer-docs/docs/develop-components/submit-and-manage-workflow-approval-requests.md
similarity index 74%
rename from en/docs/develop-components/submit-and-manage-workflow-approval-requests.md
rename to en/developer-docs/docs/develop-components/submit-and-manage-workflow-approval-requests.md
index 3a22f8bebf..60553fb5a7 100644
--- a/en/docs/develop-components/submit-and-manage-workflow-approval-requests.md
+++ b/en/developer-docs/docs/develop-components/submit-and-manage-workflow-approval-requests.md
@@ -2,7 +2,7 @@
In Choreo, if an administrator [configures a workflow to require approval](../administer/configure-approvals-for-choreo-workflows.md), you must submit a request to obtain approval to perform the task.
-Upon submitting a workflow approval request, Choreo notifies all authorized assignees via email about the [review request](../administer/review-workflow-approval-requests.md). When an authorized assignee approves or rejects the request, you will receive an email with details of the decision.
+When you submit a workflow approval request, Choreo notifies all authorized reviewers via email. Once an authorized reviewer approves or rejects the request, you will receive an email with the decision details. See [Review Workflow Approval Requests](../administer/review-workflow-approval-requests.md) for more information on workflow approval request reviews.
The approach to request approval can vary depending on the workflow.
@@ -10,7 +10,7 @@ The approach to request approval can vary depending on the workflow.
**Prerequisites**:
-- Ensure you have a component created, built, and deployed to the development environment.
+- Ensure you have a component created, built, and deployed to the first environment of your [CD pipeline](../devops-and-ci-cd/manage-continuous-deployment-pipelines.md).
- Ensure that an approval workflow is configured for environment promotion.
- Ensure you are promoting the component to a critical environment, such as production.
@@ -20,7 +20,7 @@ To request approval to promote a component from the development environment to p
2. In the **Component Listing** pane, click on the component you want to deploy. This takes you to the **Overview** page of the component.
3. In the left navigation menu, click **Deploy**.
4. Go to the **Development** card and click **Request to Promote**.
-5. In the **Request Approval** pane that opens, enter your request details and click **Submit**. This creates a request and notifies all authorized assignees via email about the request.
+5. In the **Request Approval** pane, enter your request details and click **Submit**. This creates a request and notifies all authorized assignees via email about the request.
!!! note
When an environment promotion request for a specific component is pending review, Choreo restricts other developers from making the same request until the pending request is either approved or rejected.
diff --git a/en/developer-docs/docs/develop-components/use-configuration-form.md b/en/developer-docs/docs/develop-components/use-configuration-form.md
new file mode 100644
index 0000000000..eee301cbc1
--- /dev/null
+++ b/en/developer-docs/docs/develop-components/use-configuration-form.md
@@ -0,0 +1,172 @@
+Choreo allows you to inject values for your configurations through a rich user interface.
+
+!!! info
+ - This feature is currently only available for Go, Python, Java, .NET, NodeJs, Ruby and PHP buildpacks (excluding Web Applications).
+ - The configuration form is supported starting from component.yaml v1.2.
+
+You can configure configurations in the [component.yaml](./manage-component-source-configurations.md). Based on these configurations, a form is displayed in the Choreo console. Users can define environment variables and file keys under the `configurations` section in the component.yaml.
+
+Refer to the following examples for more details.
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **env** | [Object[ ]](#environment-variables) | Optional | An array of environment variable configurations. |
+| **file** | [Object[ ]](#file-mount) | Optional | An array of file configurations. |
+
+## Environment Variables
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **name** | String | Required | A unique name for the environment variable, starting with a letter or an underscore, and containing only letters, numbers, or underscores. |
+| **valueFrom** | [Object](#valuefrom-object) | Required | The source of the configuration form. |
+
+
+```yaml
+configurations:
+ # +optional List of environment variables to be injected into the component.
+ env:
+ - name: DB_USER
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required config form value source
+ configForm:
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: DB User
+ # +optional default value is true if not specified
+ required: false
+ # +optional default value is string if not specified
+ # Allowed types - string, number, boolean, secret
+ type: string
+```
+
+!!! notes
+ Only string, boolean, number, and secret are allowed as environment variable types.
+
+## File Mount
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **mountPath** | String | Required | Path that file to be mounted in the container |
+| **name** | String | Required | A unique name for the environment variable, starting with a letter or an underscore, and containing only letters, numbers, or underscores. |
+| **type** | String | Required | File extension type. Supported types are yaml, json, and toml, and type is required |
+| **values** | [Object[ ]](#values-object) | Required | Required under file section. File key-values definition |
+
+```yaml
+configurations:
+ # +optional List of files to be injected into the component from config form
+ file:
+ # +required name of the file
+ - name: application.yaml
+ # +required path to mount the file at
+ mountPath: /src/resources
+ # +required file type
+ # Supported types - yaml, json and toml
+ type: yaml
+ # +required define keys of the file
+ values:
+ # keys of the file
+ # +required at least one key
+ - name: version
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required config form value source
+ configForm:
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: Version
+ # +optional default value is string if not specified
+ # Allowed types - string, number, boolean, secret, object, array
+ type: number
+ # +required if type is object or array
+ # define the properties of the object
+ properties:
+ # +required sub key of the object
+ - name: logger_name
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: Logger Name
+ # +required sub key of the object
+ - name: level
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: Level
+ # +optional define enum list for value selection
+ values:
+ - info
+ - debug
+ # keys of the file
+ - name: users
+ # +required value source
+ # Allowed value sources: connectionRef, configForm
+ valueFrom:
+ # +required config form value source
+ configForm:
+ # +optional display name inside the config form, name will be shown in config form if not specified
+ displayName: Users
+ # +optional default value is string if not specified
+ # Allowed types - string, number, boolean, secret, object, array
+ type: array
+ # +required if type is array
+ items:
+ # +optional default value is string if not specified
+ type: object
+ # +required if type is object or array
+ # define the properties of the object
+ properties:
+ - name: name
+ - name: description
+ required: false
+ - name: age
+ type: number
+ - name: address
+ type: object
+ properties:
+ - name: street
+ - name: city
+```
+
+## General Configuration Form Definitions
+
+### Values object
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **name** | String | Required | The name of the file sub key |
+| **valueFrom** | [Object](#valuefrom-object) | Required | Configuration form value source definition |
+
+### ValueFrom object
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **configForm** | [Object](#configform-object) | Required | Configuration form value source definition |
+
+### ConfigForm object
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **displayName** | String | Optional | The display name of the defined key in the configuration form |
+| **type** | String | Optional | The type of value. Supported types are string, number, boolean, secret, object, |
+| **required** | Boolean | Optional | Define whether the value is required or not for the key. Defaults to true when not specified. |
+| **properties** | Object | Optional | Required if type is an object. Definition for defining the sub-properties of the object |
+| **items** | [Object](#items-object) | Optional | Required if type is an array. Definition for defining the array |
+
+### Properties object
+
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **name** | String | Required | The name of the file sub key |
+| **displayName** | String | Optional | The display name of the defined key in the configuration form |
+| **type** | String | Optional | The type of value. Supported types are string, number, boolean, secret, object, |
+| **required** | Boolean | Optional | Define whether the value is required or not for the key. Defaults to true when not specified. |
+
+### Items object
+| Configuration | Type | Required | Description |
+|-------------------------------|--------------|--------------|-----------------------------------------------------------------------------------|
+| **type** | String | Optional | The type of value. Supported types are string, number, boolean, secret, object, |
+| **properties** | [Object[ ]](#properties-object) | Optional | Required if type is an object. Definition for defining the sub-properties of the object |
+
+
+!!! notes
+ - It is allowed to define nested configurations under the types `object` and `array`.
+ - `properties` is required if the type is `object` and define sub-object keys under it.
+ - `items` is required if the type is `array` and define array properties under it.
+
+Once user clicks the `Configure and Deploy` button, defined configurtions are shown and user can inject values through the form.
diff --git a/en/docs/develop-components/work-with-the-micro-integrator-runtime-in-choreo.md b/en/developer-docs/docs/develop-components/work-with-the-micro-integrator-runtime-in-choreo.md
similarity index 100%
rename from en/docs/develop-components/work-with-the-micro-integrator-runtime-in-choreo.md
rename to en/developer-docs/docs/develop-components/work-with-the-micro-integrator-runtime-in-choreo.md
diff --git a/en/docs/devops-and-ci-cd/autoscale/autoscale-component-replicas.md b/en/developer-docs/docs/devops-and-ci-cd/autoscale/autoscale-component-replicas.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/autoscale/autoscale-component-replicas.md
rename to en/developer-docs/docs/devops-and-ci-cd/autoscale/autoscale-component-replicas.md
diff --git a/en/docs/devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero.md b/en/developer-docs/docs/devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero.md
rename to en/developer-docs/docs/devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero.md
diff --git a/en/docs/devops-and-ci-cd/configure-container-resources-commands-and-arguments.md b/en/developer-docs/docs/devops-and-ci-cd/configure-container-resources-commands-and-arguments.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/configure-container-resources-commands-and-arguments.md
rename to en/developer-docs/docs/devops-and-ci-cd/configure-container-resources-commands-and-arguments.md
diff --git a/en/docs/devops-and-ci-cd/configure-storage.md b/en/developer-docs/docs/devops-and-ci-cd/configure-storage.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/configure-storage.md
rename to en/developer-docs/docs/devops-and-ci-cd/configure-storage.md
diff --git a/en/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md b/en/developer-docs/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md
similarity index 99%
rename from en/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md
rename to en/developer-docs/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md
index bd479b3b32..28c66c1bd3 100644
--- a/en/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md
+++ b/en/developer-docs/docs/devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane.md
@@ -83,7 +83,7 @@ Follow the steps given below to create a project:
#### Step 1.2: Create the Tailscale proxy component
-1. On the project home page, click **Service** under **Create a Component**.
+1. On the project home page, click **+ Create**, and select the **Service** card to create a service component.
2. Click the **Container Registry** from the **Connect a Docker Image** section
3. In the **Container Registry** list, select **Choreo Samples Registry**.
4. Click the **Tailscale Proxy** card.
diff --git a/en/docs/devops-and-ci-cd/manage-configuration-groups.md b/en/developer-docs/docs/devops-and-ci-cd/manage-configuration-groups.md
similarity index 98%
rename from en/docs/devops-and-ci-cd/manage-configuration-groups.md
rename to en/developer-docs/docs/devops-and-ci-cd/manage-configuration-groups.md
index 93f266cc9c..d054a38557 100644
--- a/en/docs/devops-and-ci-cd/manage-configuration-groups.md
+++ b/en/developer-docs/docs/devops-and-ci-cd/manage-configuration-groups.md
@@ -9,6 +9,7 @@ Configuration groups can be defined at organization level and link to components
- All configuration group values are encrypted and stored in environment-specific key vaults.
- Management of configuration groups is restricted to users with Choreo Admin, DevOps, and Platform Engineer roles.
- Developers can discover configuration groups available within the organization via the **Choreo Internal Marketplace**.
+ - This feature is currently not supported for WSO2 MI and Ballerina buildpacks, or for Web Application and Test Runner components.
## Create a configuration group
diff --git a/en/docs/devops-and-ci-cd/manage-configurations-and-secrets.md b/en/developer-docs/docs/devops-and-ci-cd/manage-configurations-and-secrets.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/manage-configurations-and-secrets.md
rename to en/developer-docs/docs/devops-and-ci-cd/manage-configurations-and-secrets.md
diff --git a/en/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md b/en/developer-docs/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md
similarity index 86%
rename from en/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md
rename to en/developer-docs/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md
index a7675db2cb..c085e5b3d7 100644
--- a/en/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md
+++ b/en/developer-docs/docs/devops-and-ci-cd/manage-continuous-deployment-pipelines.md
@@ -109,3 +109,19 @@ To change the default pipeline of a project, follow the steps given below:
!!! info "Note"
The **default** continuous deployment pipeline is configured separately at both the organization and project levels. When a project is created, it inherits the organization's **default** pipeline. The project's **default** pipeline then defines the default promotion order for its components on the Deploy page.
+
+## Use multiple continuous deployment pipelines within a component
+
+### Prerequisites
+
+- To use multiple continuous deployment pipelines on a component's deploy page, the component's project must have more than one continuous deployment pipeline assigned.
+
+To use multiple continuous deployment pipelines in a component, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the Organization, then the Project and finally the Component where you want to use multiple continuous deployment pipelines.
+3. In the left navigation menu, click **Deploy**.
+4. At the top of the page, click on the dropdown next to the Deployment Track/Version dropdown and choose the continuous deployment pipeline you want to use to deploy the component.
+
+ !!! info "Note"
+ The user will be able to view all continuous deployment pipelines assigned to the project and select one to deploy the component. Existing permissions will continue to control deployment and promotion access for specific environments.
diff --git a/en/developer-docs/docs/devops-and-ci-cd/manage-environments.md b/en/developer-docs/docs/devops-and-ci-cd/manage-environments.md
new file mode 100644
index 0000000000..811ea95a92
--- /dev/null
+++ b/en/developer-docs/docs/devops-and-ci-cd/manage-environments.md
@@ -0,0 +1,44 @@
+# Manage Environments
+
+By default, all projects created in the cloud data planes (irrespective of the data plane region) are provisioned with two environments (i.e., development and production).
+
+The environments are listed in the order of deployment and promotion. The initial deployment takes place in the first environment and you can proceed to promote a component to subsequent environments.
+
+## Create a new environment
+
+### Prerequisites
+
+- To create a new environment in a private data plane organization, you must have the `ENVIRONMENT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles.
+
+To create a new environment, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. In the left navigation menu, click **DevOps** and then click **Environments**.
+4. On the **Environments** page, click **Create** and specify the following details to create a new environment:
+
+ - **Name**: A display name for the new environment.
+ - **Data Plane** - The data plane to create the new environment.
+
+ !!!tip
+ The **Data Plane** list displays all the private data planes registered under your organization.
+
+ - **DNS Prefix**: A DNS prefix to identify the exposed APIs in the environment. Here, the base domain depends on the custom domain attached to the API gateways provisioned on the selected data plane.
+ - **Mark environment as a Production environment**: Select if you want this environment to be a production environment.
+
+ !!!tip
+ In Choreo, you can have multiple non-production and production environments. To work in a production environment, you must have privileged permissions to access and deploy to production environments.
+
+## Delete an environment
+
+To delete an environment, follow the steps given below:
+
+!!! warning
+ Environment deletion is a permanent, non-reversible operation.
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. In the left navigation menu, click **DevOps** and then click **Environments**.
+4. In the **Environments** list, click the delete icon corresponding to the environment you want to delete. This displays a confirmation dialog with details on the impact of deletion.
+5. Review the details, then type the environment name to confirm the deletion.
+6. Click **Delete**.
diff --git a/en/docs/devops-and-ci-cd/set-up-health-checks.md b/en/developer-docs/docs/devops-and-ci-cd/set-up-health-checks.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/set-up-health-checks.md
rename to en/developer-docs/docs/devops-and-ci-cd/set-up-health-checks.md
diff --git a/en/docs/devops-and-ci-cd/view-runtime-details.md b/en/developer-docs/docs/devops-and-ci-cd/view-runtime-details.md
similarity index 100%
rename from en/docs/devops-and-ci-cd/view-runtime-details.md
rename to en/developer-docs/docs/devops-and-ci-cd/view-runtime-details.md
diff --git a/en/developer-docs/docs/index.md b/en/developer-docs/docs/index.md
new file mode 100755
index 0000000000..524034e871
--- /dev/null
+++ b/en/developer-docs/docs/index.md
@@ -0,0 +1,3 @@
+---
+template: templates/home-page-2.html
+---
diff --git a/en/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md b/en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md
similarity index 90%
rename from en/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md
rename to en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md
index a732fc2493..502b6d28ba 100644
--- a/en/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md
+++ b/en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-gen-ai-services.md
@@ -31,7 +31,7 @@ To register a GenAI service, follow these steps:
2. Follow one of these steps depending on your requirements:
- To register a GenAI service at the organization level, go to the Choreo Console header and select your organization from the **Organization** list.
- To register a GenAI service at the project level, go to the Choreo Console header and select your project from the **Project** list.
-3. In the left navigation menu, click **Dependencies** and then click **GenAI Services**.
+3. In the left navigation menu, click **Resources** and then click **GenAI Services**.
4. Click **+ Register**.
5. Select a service provider.
6. Click **Next**.
@@ -72,7 +72,7 @@ When you create a GenAI service, it gets listed in the **GenAI Services** list.
To view or update a GenAI service, follow these steps.
1. Sign in to the [Choreo Console](https://console.choreo.dev/).
-2. In the left navigation menu, click **Dependencies** and then click **GenAI Services**. This lists all the GenAI services you have created.
+2. In the left navigation menu, click **Resources** and then click **GenAI Services**. This lists all the GenAI services you have created.
3. Click on a service to view or update its details.
- **General Details**: Displays service metadata. For example, the service name, overview, labels, etc.
- **Service Definition**: Displays the service definition. To update the definition, click **Upload** and select the new definition file.
@@ -82,13 +82,13 @@ To view or update a GenAI service, follow these steps.
!!! info
To add a GenAI service to the Internal Marketplace, you must provide all the required configurations.
-1. In the Choreo Console left navigation menu, click **Dependencies** and then click **GenAI Services**.
+1. In the Choreo Console left navigation menu, click **Resources** and then click **GenAI Services**.
2. Click on the service you want to add to the Internal Marketplace.
3. Click **Add to Marketplace**.
### Remove a GenAI service from the Internal Marketplace
-1. In the Choreo Console left navigation menu, click **Dependencies** and then click **GenAI Services**.
+1. In the Choreo Console left navigation menu, click **Resources** and then click **GenAI Services**.
2. Click on the service you want to remove from the Internal Marketplace.
3. Click **Remove from Marketplace**.
diff --git a/en/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md b/en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md
similarity index 92%
rename from en/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md
rename to en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md
index 762db1add9..64b97d3399 100644
--- a/en/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md
+++ b/en/developer-docs/docs/integrate-and-manage-external-services/integrate-and-manage-third-party-services.md
@@ -40,7 +40,7 @@ To register a third-party service, follow these steps:
2. Follow one of these steps depending on your requirement:
- To register a third-party service at the organization level, go to the Choreo Console header and select your organization from the **Organization** list.
- To register a third-party service at the project level, go to the Choreo Console header and select your project from the **Project** list.
-3. In the left navigation menu, click **Dependencies** and then click **Third-Party Services**.
+3. In the left navigation menu, click **Resources** and then click **Third-Party Services**.
4. Click **+ Register**.
5. Provide details for the service:
- Enter a **Name** and **Version**.
@@ -100,7 +100,7 @@ When you create a third-party service, it gets listed in the **Third-Party Servi
To view or update a third-party service, follow these steps.
1. Sign in to the [Choreo Console](https://console.choreo.dev/).
-2. In the left navigation menu, click **Dependencies** and then click **Third-Party Services**. This lists all the third-party services you have created.
+2. In the left navigation menu, click **Resources** and then click **Third-Party Services**. This lists all the third-party services you have created.
3. Click on a service to view or update its details.
- **General Details**: Displays service metadata. For example, the service name, overview, labels, etc.
- **Service Definition**: Displays the service definition. To update the definition, click **Upload** and select the new definition file.
@@ -111,13 +111,13 @@ To view or update a third-party service, follow these steps.
!!! info
To add a third-party service to the Internal Marketplace, you must provide all required parameters for at least one endpoint.
-1. In the Choreo Console left navigation menu, click **Dependencies** and then click **Third-Party Services**.
+1. In the Choreo Console left navigation menu, click **Resources** and then click **Third-Party Services**.
2. Click on the service you want to add to the Internal Marketplace.
3. Click **Add to Marketplace**.
### Remove a third-party service from the Internal Marketplace
-1. In the Choreo Console left navigation menu, click **Dependencies** and then click **Third-Party Services**.
+1. In the Choreo Console left navigation menu, click **Resources** and then click **Third-Party Services**.
2. Click on the service you want to remove from the Internal Marketplace.
3. Click **Remove from Marketplace**.
diff --git a/en/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md b/en/developer-docs/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md
similarity index 97%
rename from en/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md
rename to en/developer-docs/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md
index a667ead84f..9563019913 100644
--- a/en/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md
+++ b/en/developer-docs/docs/manage-databases-and-caches/add-choreo-managed-databases-and-caches-to-the-marketplace.md
@@ -15,7 +15,7 @@ To import credentials for a database, follow these steps:
1. Sign in to the [Choreo Console](https://console.choreo.dev/).
2. Go to the Choreo Console header and select your organization from the **Organization** list.
-3. In the left navigation menu, click **Dependencies** and then click **Databases**.
+3. In the left navigation menu, click **Resources** and then click **Databases**.
4. Click on a required database to view its details.
5. Click the **Databases** tab.
6. Click to expand the database for which you want to import credentials, then click **Import Credentials**.
diff --git a/en/docs/manage-databases-and-caches/choreo-managed-caches.md b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-caches.md
similarity index 98%
rename from en/docs/manage-databases-and-caches/choreo-managed-caches.md
rename to en/developer-docs/docs/manage-databases-and-caches/choreo-managed-caches.md
index 007e034193..e7de3b82db 100644
--- a/en/docs/manage-databases-and-caches/choreo-managed-caches.md
+++ b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-caches.md
@@ -10,7 +10,7 @@ Follow the steps below to create a Choreo-Managed Cache:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then click **Databases**.
+3. In the left navigation menu, click **Resources** and then click **Databases**.
4. Click **+ Create** and select **Choreo-Managed Cache** as the data store type. Provide a display name for this server and follow the instructions.
5. Select a preferred cloud provider (AWS, Azure, GCP, or Digital Ocean).
- The cloud provider provisions the compute and storage infrastructure for your data store.
diff --git a/en/docs/manage-databases-and-caches/choreo-managed-databases-and-caches.md b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-databases-and-caches.md
similarity index 100%
rename from en/docs/manage-databases-and-caches/choreo-managed-databases-and-caches.md
rename to en/developer-docs/docs/manage-databases-and-caches/choreo-managed-databases-and-caches.md
diff --git a/en/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md
similarity index 98%
rename from en/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md
rename to en/developer-docs/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md
index 4f0102f678..336e36c771 100644
--- a/en/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md
+++ b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-mysql-databases.md
@@ -7,7 +7,7 @@ MySQL on Choreo offers fully managed, flexible relational databases on AWS, Azur
Follow the steps below to create a Choreo-managed MySQL database:
1. From the environment list on the header, located next to the **Deployment Tracks** list, select your **Organization**.
-2. In the left navigation menu, click **Dependencies** and then **Databases**.
+2. In the left navigation menu, click **Resources** and then **Databases**.
3. Click **Create** and select **MySQL** as the database type. Provide a display name for this server and follow the instructions.
4. Select your preferred cloud provider from AWS, Azure, GCP, and Digital Ocean.
- Choreo uses the cloud provider to provision the compute and storage infrastructure for your database.
diff --git a/en/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md
similarity index 97%
rename from en/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md
rename to en/developer-docs/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md
index d577ad30bb..37cce4bbc9 100644
--- a/en/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md
+++ b/en/developer-docs/docs/manage-databases-and-caches/choreo-managed-postgresql-databases.md
@@ -8,7 +8,7 @@ Follow the steps below to create a Choreo-managed PostgreSQL database:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev/).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then **Databases**.
+3. In the left navigation menu, click **Resources** and then **Databases**.
4. Click **Create** and select **PostgreSQL** as the database type. Provide a display name for this server and follow the instructions.
5. Select your preferred cloud provider from AWS, Azure, GCP, or Digital Ocean.
- The cloud provider is used to provision the compute and storage infrastructure for your database.
@@ -24,7 +24,7 @@ Follow the steps below to create a Choreo-managed PostgreSQL vector database:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev/).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then **Vector Databases**.
+3. In the left navigation menu, click **Resources** and then **Vector Databases**.
4. Follow steps 4 onwards in the [Create a Choreo-managed PostgreSQL database](#create-a-choreo-managed-postgresql-database) section.
## Connecting to your Choreo-managed PostgreSQL database
diff --git a/en/docs/manage-message-brokers/choreo-managed-message-brokers.md b/en/developer-docs/docs/manage-message-brokers/choreo-managed-message-brokers.md
similarity index 100%
rename from en/docs/manage-message-brokers/choreo-managed-message-brokers.md
rename to en/developer-docs/docs/manage-message-brokers/choreo-managed-message-brokers.md
diff --git a/en/docs/manage-message-brokers/configure-a-kafka-service.md b/en/developer-docs/docs/manage-message-brokers/configure-a-kafka-service.md
similarity index 93%
rename from en/docs/manage-message-brokers/configure-a-kafka-service.md
rename to en/developer-docs/docs/manage-message-brokers/configure-a-kafka-service.md
index 027ed4c4d5..d4cfc7a26b 100644
--- a/en/docs/manage-message-brokers/configure-a-kafka-service.md
+++ b/en/developer-docs/docs/manage-message-brokers/configure-a-kafka-service.md
@@ -10,7 +10,7 @@ To create a Kafka topic, follow these steps:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then click **Message Brokers**.
+3. In the left navigation menu, click **Resources** and then click **Message Brokers**.
4. In the **Message Brokers** list, click the Kafka service for which you want to create a topic.
5. Click the **Topics** tab.
6. Click **+ Create**.
@@ -49,7 +49,7 @@ To manage users for a Choreo-managed Kafka service, follow these steps:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then click **Message Brokers**.
+3. In the left navigation menu, click **Resources** and then click **Message Brokers**.
4. In the **Message Brokers** list, click the Kafka service for which you want to manage users.
5. Click the **Users** tab.
6. Click **+ Add User**, specify a username, and then click **Add**.
@@ -68,7 +68,7 @@ To add an ACL entry, follow these steps:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then click **Message Brokers**.
+3. In the left navigation menu, click **Resources** and then click **Message Brokers**.
4. In the **Message Brokers** list, click the Kafka service for which you want to add an ACL entry.
5. Click the **Access Control List** tab.
6. Click **+ Add Entry**, select a username, topic, and permission.
diff --git a/en/docs/manage-message-brokers/create-choreo-managed-kafka-services.md b/en/developer-docs/docs/manage-message-brokers/create-choreo-managed-kafka-services.md
similarity index 99%
rename from en/docs/manage-message-brokers/create-choreo-managed-kafka-services.md
rename to en/developer-docs/docs/manage-message-brokers/create-choreo-managed-kafka-services.md
index db82e52e4f..fe05bd1c1b 100644
--- a/en/docs/manage-message-brokers/create-choreo-managed-kafka-services.md
+++ b/en/developer-docs/docs/manage-message-brokers/create-choreo-managed-kafka-services.md
@@ -12,7 +12,7 @@ Follow the steps below to create a Choreo-managed Kafka service:
1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
2. In the header, click the **Organization** list. This opens the organization home page.
-3. In the left navigation menu, click **Dependencies** and then click **Message Brokers**.
+3. In the left navigation menu, click **Resources** and then click **Message Brokers**.
4. Click **+ Create**.
5. Specify a display name for the Kafka service and click **Next**.
6. Select your preferred cloud provider from AWS, Azure, GCP, or Digital Ocean.
diff --git a/en/docs/manage-message-brokers/monitor-a-kafka-service.md b/en/developer-docs/docs/manage-message-brokers/monitor-a-kafka-service.md
similarity index 100%
rename from en/docs/manage-message-brokers/monitor-a-kafka-service.md
rename to en/developer-docs/docs/manage-message-brokers/monitor-a-kafka-service.md
diff --git a/en/docs/monitoring-and-insights/alerts-overview.md b/en/developer-docs/docs/monitoring-and-insights/alerts-overview.md
similarity index 99%
rename from en/docs/monitoring-and-insights/alerts-overview.md
rename to en/developer-docs/docs/monitoring-and-insights/alerts-overview.md
index d4992eb7a3..30d9de8134 100644
--- a/en/docs/monitoring-and-insights/alerts-overview.md
+++ b/en/developer-docs/docs/monitoring-and-insights/alerts-overview.md
@@ -1,4 +1,4 @@
-# Alert Overview
+# Alerts Overview
This section explains how you can configure alerts for your Choreo components. Setting up alerts allows you to proactively monitor your components ecosystem and take corrective measures when necessary.
diff --git a/en/developer-docs/docs/monitoring-and-insights/cost-optimization.md b/en/developer-docs/docs/monitoring-and-insights/cost-optimization.md
new file mode 100644
index 0000000000..2c8b143850
--- /dev/null
+++ b/en/developer-docs/docs/monitoring-and-insights/cost-optimization.md
@@ -0,0 +1,190 @@
+# Choreo Cost Optimization
+
+## Overview
+
+The Choreo cost optimization feature provides detailed cost insights across your organization, enabling you to analyze resource utilization and cost efficiency at the Organization, Project, and Component levels. The dashboards provide comprehensive visualizations and actionable recommendations to optimize cloud infrastructure costs while maintaining performance.
+
+**All metrics, visualizations, and analytics displayed across the Organization, Project, and Component levels reflect data for the current month, from the first day up to the current date.** This provides you with up-to-date insights into your resource utilization and cost efficiency.
+Monthly figures show the accumulated data for the current month so far, while comparisons to previous month are also available in some metrics. This approach gives you both immediate visibility into current spending patterns and understanding the trend compared to last month for optimization decisions.
+
+You can use this information to track ongoing cost optimization efforts and make timely adjustments to your resource allocations within the current billing cycle.
+
+## Organization Level
+
+
+
+At the Organization level, Choreo provides key insights into overall cost savings and resource efficiency across all your projects. You can view the following metrics and visualizations:
+
+* **Monthly Savings Summary**
+
+
+
+
+ This chart visualizes the percentage of cost savings achieved (by manual or automatic application of recommendations) compared to missed savings (potential savings missed due to recommendations not being applied) up to the current date. You should aim to maximize the saved cost and minimize missed savings.
+
+* **Total Monthly Savings**
+
+
+
+
+ This card shows the cost saved in the current month through manual or automatic application of recommendations. It includes a breakdown for Production and Non-Production environments, with a dropdown showing savings for each respective environment.
+
+* **Monthly Missed Savings**
+
+
+
+ This card displays the potential cost savings that were missed due to the failure to apply recommendations, whether manually or automatically. It provides a breakdown of these missed savings for both production and non-production environments, listing values for each individual environment. It is recommended to keep these missed savings as minimal as possible.
+
+* **Annual Savings**
+
+
+
+ This card shows accumulated savings throughout the year. It combines the savings completed through the end of the previous month with savings achieved up to the present day of the current month. This demonstrates that a fully cost-optimized organization with no savings for the current month has achieved this state by saving costs in previous months.
+
+* **Monthly CPU and Memory Cost**
+
+
+
+ This card shows the cost incurred for CPU and Memory allocation across all components in your organization. It includes a percentage change compared to the previous month to indicate cost trends.
+
+* **Estimated Monthly Cost**
+
+
+
+ This card shows the forecasted cost at the end of the month, with an environmental breakdown, regardless of which day of the month you view it.
+
+* **Monthly CPU and Memory Efficiency**
+
+
+
+ This card shows the percentage utilization of CPU and Memory compared to allocation. This metric indicates your resource optimization level, which directly reflects cost optimization. The breakdown of CPU and Memory efficiencies provides individual understanding of each resource's optimization. The percentage change shown compares current efficiency to last month's efficiency with an arrow indicating increase or decrease.
+
+* **Cost Analysis Plot**
+
+
+
+ The plot consists of three lines:
+
+ * **Allocation Cost** - The maximum of Request Cost and Utilization Cost at a given point in time. This is what you're billed for CPU and memory resource costs.
+ * **Utilization Cost** - The ideal cost that should be billed if no extra resources were allocated. This is typically not achievable in practice as some buffer is needed for uninterrupted service.
+ * **Optimized Cost** - The cost suggested by the optimization algorithm that provides sufficient buffer for efficient performance while optimizing costs.
+
+ You can filter the view to show All resources, CPU only, or Memory only for time-based cost analysis.
+
+* **Cost Savings (Deployments Summary)**
+
+
+
+ Under the Cost Savings section, these cards provide a summary of all deployments in your organization:
+
+ * **Under Provisioned Deployments** - Number of deployments with insufficient resource allocation
+ * **Over Provisioned Deployments** - Number of deployments with over-allocated resources
+ * **Idle Deployments** - Deployments with no traffic for the last 3 days
+ * **Auto-optimized deployments** - Number of deployments with auto-optimization enabled
+ * **Deployments that require attention** - Number of deployments with auto-optimization disabled that have recommendations for manual application
+ * **Total number of deployments** - Number of active deployments
+
+* **Cost Savings (Project Summary)**
+
+
+
+ This table under the Cost Savings section includes a summary of all projects in your organization. Each row represents a project with columns showing:
+ * Saved Cost after applying recommendations automatically/manually
+ * Actual Cost after Savings
+ * CPU and Memory Efficiency
+ * Ratio of Applied Suggestions to total available recommendations
+
+ You can click on any project in this table or use the top navigation to visit the Project Level cost insights.
+
+## Project Level
+
+
+
+The Project Level view is similar to the Organization Level, with all monthly metrics focused on the selected project. The charts, cards, plots, and tables follow the same format as the Organization Level.
+
+An additional feature at this level is the ability to toggle auto-apply for each component in the Cost Savings (Component Summary) table, or for all components. This simplifies the process of enabling auto-application of recommendations across all components in a project.
+
+
+
+
+These toggles enable automatic application of recommendations for all deployments in the selected components.
+
+## Component Level
+
+
+
+The Component Level differs from both Organization and Project levels. At the Component Level, you can access the release level through both deployment track (version) and environment configuration as shown:
+
+
+
+At the Release Level within the Component Level, you can view:
+
+* **Component details and Optimization Configurations**
+
+
+
+ This card shows configuration data for the deployment, including number of replicas, scale to zero settings, and horizontal pod auto-scaling that can be configured in DevOps.
+
+ #### Optimization Configurations
+ Under the Optimization Configurations section, you can configure how Choreo applies cost optimization recommendations:
+
+ Auto Apply Recommendations:
+
+ When enabled, this toggle automatically implements resource right-sizing recommendations daily. Every 24 hours the system automatically checks if the release has any recommendations that would save more than $0.01, and if found, applies them without requiring manual intervention. This feature helps maintain continuous cost efficiency without constant monitoring.
+
+
+ Safety Buffer:
+
+ This setting determines how conservatively the optimization algorithm calculates resource recommendations:
+
+ Low: Adds a 10% buffer above the calculated resource requirements, which maximizes cost savings but provides less headroom for unexpected traffic spikes
+
+ High: Adds a 20% buffer above the calculated resource requirements, offering more capacity for handling unexpected load increases - recommended for production environments
+
+
+
+ The Safety Buffer setting helps you balance between maximum cost efficiency and maintaining reliable performance. For mission-critical applications or services with variable workloads, the High setting provides additional capacity to handle sudden traffic increases, while the Low setting is suitable for predictable workloads where you want to optimize costs more aggressively.
+ These configurations allow you to tailor the optimization behavior to your specific needs, balancing cost-saving opportunities with operational requirements at the component level.
+
+* **Monthly Cost, Missed Savings, Efficiency and Estimated Cost**
+
+
+
+ These cards summarize the cost and resource metrics similar to those at the Organization and Project levels.
+
+* **CPU Metrics Analysis**
+
+
+
+* **Memory Metrics Analysis**
+
+
+
+* **Recommendations**
+
+
+
+ The system provides **automated** and **manual** recommendations for cost reduction.
+
+### Optimization Types
+
+* **Resource Right-Sizing**
+ * Suggests optimized CPU and memory limits
+ * Provides potential cost savings per adjustment
+
+* **Enable Scale to Zero**
+ * Stops a component when no requests are being served
+ * Reduces idle infrastructure costs
+
+* **Stop Deployment**
+ * Identifies and halts unused deployments
+ * Prevents unnecessary spending on unused resources
+
+### Applying Recommendations
+
+* **Manually Apply**: You can review and apply suggestions individually
+* **Auto-Apply Toggle**: Enables automatic cost optimizations for projects/components
+
+## Conclusion
+
+The Choreo Cost Optimization feature helps you improve cloud resource efficiency by providing insights and recommendations at various levels. With interactive visualizations, automated recommendations, and optimization tracking, you can reduce infrastructure costs while maintaining performance.
diff --git a/en/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md b/en/developer-docs/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md
similarity index 97%
rename from en/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md
rename to en/developer-docs/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md
index a9c1442c82..73f20788fc 100644
--- a/en/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md
+++ b/en/developer-docs/docs/monitoring-and-insights/delivery-insights/configure-dora-metrics.md
@@ -16,10 +16,10 @@ Choreo enables two DORA metrics by default; deployment frequency and lead time f
To configure the CIO dashboard by enabling the other two metrics, follow the steps below:
-1. Sign in to Choreo using your Google, GitHub, or Microsoft account.
+1. Sign in to Choreo using your Google, GitHub, or Microsoft account.
2. On the left navigation menu, click **Insights** and then click **Delivery**.
-4. Scroll to the bottom of the dashboard and click **Configure**.
-5. Select your incident management system. Currently, Choreo only supports GitHub.
+3. Scroll to the bottom of the dashboard and click **Configure**.
+4. Select your incident management system. Currently, Choreo only supports GitHub.
## Configuring GitHub as the incident management system
diff --git a/en/docs/monitoring-and-insights/delivery-insights/view-dora-metrics.md b/en/developer-docs/docs/monitoring-and-insights/delivery-insights/view-dora-metrics.md
similarity index 100%
rename from en/docs/monitoring-and-insights/delivery-insights/view-dora-metrics.md
rename to en/developer-docs/docs/monitoring-and-insights/delivery-insights/view-dora-metrics.md
diff --git a/en/docs/monitoring-and-insights/generate-custom-reports.md b/en/developer-docs/docs/monitoring-and-insights/generate-custom-reports.md
similarity index 100%
rename from en/docs/monitoring-and-insights/generate-custom-reports.md
rename to en/developer-docs/docs/monitoring-and-insights/generate-custom-reports.md
diff --git a/en/docs/monitoring-and-insights/insights-overview.md b/en/developer-docs/docs/monitoring-and-insights/insights-overview.md
similarity index 100%
rename from en/docs/monitoring-and-insights/insights-overview.md
rename to en/developer-docs/docs/monitoring-and-insights/insights-overview.md
diff --git a/en/docs/monitoring-and-insights/integrate-choreo-with-moesif.md b/en/developer-docs/docs/monitoring-and-insights/integrate-choreo-with-moesif.md
similarity index 100%
rename from en/docs/monitoring-and-insights/integrate-choreo-with-moesif.md
rename to en/developer-docs/docs/monitoring-and-insights/integrate-choreo-with-moesif.md
diff --git a/en/docs/monitoring-and-insights/logs/view-pdp-logs.md b/en/developer-docs/docs/monitoring-and-insights/logs/view-pdp-logs.md
similarity index 100%
rename from en/docs/monitoring-and-insights/logs/view-pdp-logs.md
rename to en/developer-docs/docs/monitoring-and-insights/logs/view-pdp-logs.md
diff --git a/en/docs/monitoring-and-insights/observability-overview.md b/en/developer-docs/docs/monitoring-and-insights/observability-overview.md
similarity index 100%
rename from en/docs/monitoring-and-insights/observability-overview.md
rename to en/developer-docs/docs/monitoring-and-insights/observability-overview.md
diff --git a/en/docs/monitoring-and-insights/view-logs.md b/en/developer-docs/docs/monitoring-and-insights/view-logs.md
similarity index 100%
rename from en/docs/monitoring-and-insights/view-logs.md
rename to en/developer-docs/docs/monitoring-and-insights/view-logs.md
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api.md b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api.md
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api.md
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api.md
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2 b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2 b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2 b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
diff --git a/en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg b/en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
similarity index 100%
rename from en/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
rename to en/developer-docs/docs/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
diff --git a/en/docs/page-not-found.md b/en/developer-docs/docs/page-not-found.md
similarity index 100%
rename from en/docs/page-not-found.md
rename to en/developer-docs/docs/page-not-found.md
diff --git a/en/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md b/en/developer-docs/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md
similarity index 99%
rename from en/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md
rename to en/developer-docs/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md
index cb72621798..82af89d7ad 100644
--- a/en/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md
+++ b/en/developer-docs/docs/quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service.md
@@ -198,7 +198,7 @@ Now that the `Reading List Service` is deployed and available in the Choreo Mark
A connection allows you to integrate the service with other services or external resources. For more information, refer to the [Connection](../choreo-concepts/connections.md) documentation.
-1. In the left navigation menu, click **Dependencies** and then click **Connections**.
+1. In the left navigation menu, click **Connections**.
2. Click **+ Create**.
3. In the **Select a Service** pane, click `Reading List Service`.
4. Specify the following:
diff --git a/en/docs/quick-start-guides/deploy-your-first-service.md b/en/developer-docs/docs/quick-start-guides/deploy-your-first-service.md
similarity index 100%
rename from en/docs/quick-start-guides/deploy-your-first-service.md
rename to en/developer-docs/docs/quick-start-guides/deploy-your-first-service.md
diff --git a/en/docs/quick-start-guides/deploy-your-first-static-web-application.md b/en/developer-docs/docs/quick-start-guides/deploy-your-first-static-web-application.md
similarity index 100%
rename from en/docs/quick-start-guides/deploy-your-first-static-web-application.md
rename to en/developer-docs/docs/quick-start-guides/deploy-your-first-static-web-application.md
diff --git a/en/docs/references/choreo-limitations.md b/en/developer-docs/docs/references/choreo-limitations.md
similarity index 100%
rename from en/docs/references/choreo-limitations.md
rename to en/developer-docs/docs/references/choreo-limitations.md
diff --git a/en/docs/references/choreo-platform-services-billing-and-upgrades.md b/en/developer-docs/docs/references/choreo-platform-services-billing-and-upgrades.md
similarity index 100%
rename from en/docs/references/choreo-platform-services-billing-and-upgrades.md
rename to en/developer-docs/docs/references/choreo-platform-services-billing-and-upgrades.md
diff --git a/en/docs/references/faq.md b/en/developer-docs/docs/references/faq.md
similarity index 100%
rename from en/docs/references/faq.md
rename to en/developer-docs/docs/references/faq.md
diff --git a/en/docs/references/private-data-plane-management-models.md b/en/developer-docs/docs/references/private-data-plane-management-models.md
similarity index 100%
rename from en/docs/references/private-data-plane-management-models.md
rename to en/developer-docs/docs/references/private-data-plane-management-models.md
diff --git a/en/docs/references/private-data-plane-security-levels.md b/en/developer-docs/docs/references/private-data-plane-security-levels.md
similarity index 100%
rename from en/docs/references/private-data-plane-security-levels.md
rename to en/developer-docs/docs/references/private-data-plane-security-levels.md
diff --git a/en/docs/references/troubleshoot-choreo.md b/en/developer-docs/docs/references/troubleshoot-choreo.md
similarity index 98%
rename from en/docs/references/troubleshoot-choreo.md
rename to en/developer-docs/docs/references/troubleshoot-choreo.md
index 736efc36c3..e16ad78d8f 100644
--- a/en/docs/references/troubleshoot-choreo.md
+++ b/en/developer-docs/docs/references/troubleshoot-choreo.md
@@ -66,7 +66,7 @@ To resolve the issue, follow the guidelines given below:
For step-by-step instructions on how to manage users with Choreo's built-in identity provider (IdP), see [Configure a User Store with the Built-In IdP](../administer/configure-a-user-store-with-built-in-idp.md).
- For details on setting up other OpenID Connect (OIDC) supported IdPs, see [Manage OAuth Keys](../authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-3-manage-oauth-keys).
+ For details on setting up other OpenID Connect (OIDC) supported IdPs, see [Manage OAuth Keys](../authentication-and-authorization/secure-web-applications-with-managed-authentication.md#step-3-configure-the-identity-provider-for-the-web-application).
## Troubleshoot Tailscale proxy issues
diff --git a/en/docs/resources/kubernetes-upgrade-notice.md b/en/developer-docs/docs/resources/kubernetes-upgrade-notice.md
similarity index 100%
rename from en/docs/resources/kubernetes-upgrade-notice.md
rename to en/developer-docs/docs/resources/kubernetes-upgrade-notice.md
diff --git a/en/docs/search-results.html b/en/developer-docs/docs/search-results.html
similarity index 98%
rename from en/docs/search-results.html
rename to en/developer-docs/docs/search-results.html
index 3e756c53b3..0fc8ea9509 100644
--- a/en/docs/search-results.html
+++ b/en/developer-docs/docs/search-results.html
@@ -4,7 +4,7 @@
-
+
diff --git a/en/docs/testing/test-apis-with-choreo-apichat.md b/en/developer-docs/docs/testing/test-apis-with-choreo-apichat.md
similarity index 100%
rename from en/docs/testing/test-apis-with-choreo-apichat.md
rename to en/developer-docs/docs/testing/test-apis-with-choreo-apichat.md
diff --git a/en/docs/testing/test-apis-with-curl.md b/en/developer-docs/docs/testing/test-apis-with-curl.md
similarity index 100%
rename from en/docs/testing/test-apis-with-curl.md
rename to en/developer-docs/docs/testing/test-apis-with-curl.md
diff --git a/en/docs/testing/test-components-with-test-runner.md b/en/developer-docs/docs/testing/test-components-with-test-runner.md
similarity index 100%
rename from en/docs/testing/test-components-with-test-runner.md
rename to en/developer-docs/docs/testing/test-components-with-test-runner.md
diff --git a/en/docs/testing/test-graphql-endpoints-via-the-graphql-console.md b/en/developer-docs/docs/testing/test-graphql-endpoints-via-the-graphql-console.md
similarity index 100%
rename from en/docs/testing/test-graphql-endpoints-via-the-graphql-console.md
rename to en/developer-docs/docs/testing/test-graphql-endpoints-via-the-graphql-console.md
diff --git a/en/docs/testing/test-rest-endpoints-via-the-openapi-console.md b/en/developer-docs/docs/testing/test-rest-endpoints-via-the-openapi-console.md
similarity index 100%
rename from en/docs/testing/test-rest-endpoints-via-the-openapi-console.md
rename to en/developer-docs/docs/testing/test-rest-endpoints-via-the-openapi-console.md
diff --git a/en/docs/testing/test-websocket-endpoints-via-the-websocket-console.md b/en/developer-docs/docs/testing/test-websocket-endpoints-via-the-websocket-console.md
similarity index 100%
rename from en/docs/testing/test-websocket-endpoints-via-the-websocket-console.md
rename to en/developer-docs/docs/testing/test-websocket-endpoints-via-the-websocket-console.md
diff --git a/en/docs/tutorials/consume-an-api-hosted-in-choreo.md b/en/developer-docs/docs/tutorials/consume-an-api-hosted-in-choreo.md
similarity index 86%
rename from en/docs/tutorials/consume-an-api-hosted-in-choreo.md
rename to en/developer-docs/docs/tutorials/consume-an-api-hosted-in-choreo.md
index 77c06f3288..bcaebf1e6c 100644
--- a/en/docs/tutorials/consume-an-api-hosted-in-choreo.md
+++ b/en/developer-docs/docs/tutorials/consume-an-api-hosted-in-choreo.md
@@ -122,23 +122,11 @@ Update the web app configurations to invoke the **Reading List Service** REST AP
To configure the front-end application:
-1. On the web application component page, click **DevOps** in the left menu, then click **Configs and Secrets**.
-2. Click **+ Create**.
-3. Select the following options and click **Next**:
+1. On the Choreo Console header, select the project and the created web application component.
+2. In the left navigation menu, click **Deploy**.
+3. On the **Deploy** page, under the **Set Up** card and click **Configure & Deploy**.
+4. Copy the following JSON configuration, paste it into the text area in the **File Mount pane**, and replace the placeholders with the values from the previous steps:
- | **Field** | **Value** |
- |-----------------------|-----------------------------------------|
- | **Config Type** | **Config Map** |
- | **Mount Type** | **File Mount** |
-
-4. Specify the following values:
-
- | **Field** | **Value** |
- |-----------------------|-----------------------------------------|
- | **Config Name** | **Web App Config** |
- | **Mount Path** | **/usr/share/nginx/html/config.js** |
-
-5. Copy the following JSON configuration into the text area. Replace the placeholders with the values from earlier steps:
```javascript
window.config = {
@@ -149,22 +137,21 @@ To configure the front-end application:
};
```
+
| **Field** | **Description** |
|-----------------------|-----------------------------------------------|
| **redirectUrl** | The web app URL you copied earlier. |
| **asgardeoClientId** | The **Client ID** from the Asgardeo application. |
| **asgardeoBaseUrl** | The IdP API URL with your organization name (e.g., `https://api.asgardeo.io/t/Welcome to the Choreo Learning Portal
-
The Home page will be designed to provide a guided experience to any user coming to docs with a valid Choreo use case.
We intend to ONLY INCLUDE conceptual information in the documentation for the relevant topics and **NOT INCLUDE** any how to guides, or instructions with the exception of Tutorials.
+
+
+
+All communication between the control plane and the private data plane is secured using TLS.
+
+### Observability architecture
+
+The following diagram depicts the architecture overview of Choreo's in-data-plane log and observability in Azure PDP:
+
+
+
+The private data plane observability architecture is centered around a strong commitment to data privacy and compliance. This is achieved through a strategic decision to retain logs and observability data within the data planes itself. Key aspects of this architecture include:
+
+- **Data storage at source**: Logs and observability data are stored within the data plane itself, enhancing security, simplifying access, and ensuring compliance.
+- **Direct browser-to-data-plane interaction**: The Choreo Console in the user's browser directly interacts with APIs in the data plane, reducing potential data routing complexities and ensuring a more secure, direct flow of information.
+- **Reduced data exposure points**: Fetching data directly from the data plane's APIs minimizes the number of data transfer points, effectively decreasing the chances of data exposure or interception.
+- **Compliance with regulatory standards**: The architecture supports data locality, aligning with global regulatory standards like GDPR and CCPA by keeping data in its original environment.
+- **Improved performance and real-time insights**: Direct interaction between the browser and data plane results in faster data retrieval, providing users with immediate insights.
+- **User transparency and control**: Users have a clear view of their data's location and access methods, alongside granular control over data access.
+
+### Security
+
+The Choreo private data plane ensures extensive, production-grade security, ranging from infrastructure and architecture to zero-trust network security. All incoming traffic is protected by a firewall and must undergo authentication and authorization via the API Gateway. It also provides end-to-end network traffic encryption using Cilium transparent encryption, ensuring efficient data path encryption.
+
+For details on the private data plane security levels supported in Choreo pricing plans, see [Private Data Plane Security Levels](../references/private-data-plane-security-levels.md).
+
+### Management models
+
+Choreo supports the following management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios:
+
+ - WSO2 fully managed (infrastructure and PDP in WSO2 subscription) model
+ - WSO2 fully managed (infrastructure and PDP in customer subscription) model
+ - Customer self-managed (WSO2 provides installation script and updates) model
+
+To explore each management model in detail so that you can make informed decisions depending on the supported cloud-based operations and security, see [Private Data Plane Management Models](../references/private-data-plane-management-models.md).
diff --git a/en/pe-docs/docs/choreo-concepts/deployment-tracks.md b/en/pe-docs/docs/choreo-concepts/deployment-tracks.md
new file mode 100644
index 0000000000..3c47cfa477
--- /dev/null
+++ b/en/pe-docs/docs/choreo-concepts/deployment-tracks.md
@@ -0,0 +1,50 @@
+# Deployment Tracks
+
+Deployment Tracks in Choreo are structured pathways for simplified software component deployment. They act like advanced CI/CD pipelines, ensuring your components reach their destinations seamlessly, whether from source code or prebuilt images. They establish an organized and structured approach that minimizes the chances of errors and challenges that are typically associated with deployment workflows.
+
+## The significance of Deployment Tracks
+
+Deployment Tracks offer practical solutions to enhance the API consumer experience by addressing two critical challenges:
+
+- **Streamlined deployment**: Deployment Tracks serve as well-designed routes for your software components, enhancing the organization and reliability of the deployment process, similar to a well-structured express route.
+
+- **Efficient API versioning**: Especially beneficial for managed APIs, Deployment Tracks provide a straightforward method for creating API versions that seamlessly interact with previous iterations. This simplified version management benefits both API creators and consumers alike.
+
+## Streamlined deployments
+
+For streamlined deployments, Choreo dissects two integral approaches that leverage Deployment Tracks: the comprehensive CI/CD integration and the focused CD-Only strategy.
+
+### CI/CD with Deployment Tracks
+
+A deployment track is linked to a particular branch within a GitHub repository. This connection is useful for handling deployments to various environments. On Choreo's Deploy page, you can easily visualize the deployments to specific environments associated with your selected deployment track. Moreover, the deployment track has a functionality that initiates automatic deployments for the linked branch. When activated, merging a pull request (PR) triggers a deployment to the development environment.
+
+{.cInlineImage-half}
+
+### CD-Only strategy with Deployment Tracks
+
+If you're inclined to use your own Continuous Integration (CI) systems and want to harness the deployment track as a Continuous Deployment (CD) pipeline, you can seamlessly link deployment tracks to a container registry repository. This configuration empowers users to effortlessly deploy images sourced directly from the linked container registry repository.
+
+{.cInlineImage-half}
+
+
+## Efficient API versioning
+
+**This section applies to only service components**. When working with service components in Choreo, it is important to have an effective API versioning mechanism. Choreo follows a versioning mechanism based on Semantic Versioning (SemVer) but only includes the major version and minor version with the prefix `v`.
+
+For example, `v1.2`.
+
+You can follow the approach given below when you version APIs in Choreo:
+
+ - Increment the major version when you make incompatible API changes.
+ - Increment the minor version when you add functionality in a backward-compatible manner.
+
+!!! info "What is Semantic Versioning?"
+ Semantic Versioning (SemVer) is a specification that defines how to assign and increment version numbers for software products, including APIs. For more information, see [Semantic Versioning specification](https://semver.org/#semantic-versioning-specification-semver).
+
+One of the primary concerns when dealing with SaaS APIs is to minimize disruption for API consumers while continuously developing and deploying updates.
+
+In compliance with SemVer, changes that don't introduce breaking or additive modifications to the API are categorized as patch updates. Hover, from the perspective of API consumers, these changes should ideally not disrupt their API clients. Typically, API consumers are most concerned with major API version alterations, but there might be instances where minor version changes are communicated to them.
+
+Therefore, in the context of deployment tracks, API developers only need to specify the major and minor versions being delivered from a particular deployment track. This information is treated as the API version attribute of a deployment track. If the publisher requires versioning for internal tracking purposes, this can be accomplished in Git through the use of Git tags, on GitHub with GitHub releases, and so forth.
+
+{.cInlineImage-half}
diff --git a/en/pe-docs/docs/choreo-concepts/endpoint.md b/en/pe-docs/docs/choreo-concepts/endpoint.md
new file mode 100644
index 0000000000..ffd5f0d892
--- /dev/null
+++ b/en/pe-docs/docs/choreo-concepts/endpoint.md
@@ -0,0 +1,5 @@
+# Endpoint
+
+An Endpoint is a network-exposed function that resides within a component. In Choreo, service and integration components expose one or more endpoints. Each endpoint in a component can have a service contract (OpenAPI, GraphQL SDL) associated with it. This contract is used to expose the endpoint to consumers. In the absence of a contract, Choreo uses /\* exposed on all HTTP verbs as the default contract to expose the service or the integration.
+
+Each endpoint exposed in a component is considered a single API. Therefore, Choreo allows you to do API management per endpoint for a given component. For example, you can perform lifecycle management and configure security settings per endpoint in a given component.
diff --git a/en/pe-docs/docs/choreo-concepts/environments.md b/en/pe-docs/docs/choreo-concepts/environments.md
new file mode 100644
index 0000000000..2e3f2a5799
--- /dev/null
+++ b/en/pe-docs/docs/choreo-concepts/environments.md
@@ -0,0 +1,9 @@
+# Environments
+
+Choreo offers developers one or more environments to run their applications within a given data plane. By default, the Choreo cloud data plane provides two environments (i.e., development and production). Each project in Choreo is associated with one or more environments available in the organization. For example, project A may choose to utilize dev, staging, and production environments, while project B may only use development and production environments.
+
+You can promote components within a project across available environments. When you promote a component, its configuration values can be overridden with environment-specific values.
+
+The following diagram illustrates how a component is promoted across environments.
+
+{.cInlineImage-threeQuarter}
diff --git a/en/docs/choreo-concepts/organization.md b/en/pe-docs/docs/choreo-concepts/organization.md
similarity index 60%
rename from en/docs/choreo-concepts/organization.md
rename to en/pe-docs/docs/choreo-concepts/organization.md
index b533a1dd1d..edf3a47979 100644
--- a/en/docs/choreo-concepts/organization.md
+++ b/en/pe-docs/docs/choreo-concepts/organization.md
@@ -6,7 +6,7 @@ An organization in Choreo is a logical grouping of users and user resources. A f
If you are a member of more than one organization, you can switch from one organization to another when necessary. To do this, select the required organization from the **Organization** list in the Choreo Console header.
-{% include "../administer/inviting-members.md" %}
+{% include "../user-management/users/inviting-members.md" %}
## Manage user permission
@@ -23,6 +23,7 @@ Choreo comes with predefined groups already configured with specific roles, as f
- **Admin** : A collection of users who have the Admin role.
- **Billing Admin** : A collection of users who have the Billing Admin role.
- **Choreo DevOps** : A collection of users who have the Choreo DevOps role.
+- **Choreo Platform Engineer** : A collection of users who have the Choreo Platform Engineer role.
- **Developer** : Users who develop, deploy, and manage cloud native applications at scale.
- **External API Subscriber**: A collection of users who have the External API Subscriber role.
@@ -32,14 +33,17 @@ When creating a new group to invite members, be sure to assign a role to the gro
Choreo roles are defined as follows:
-- **API Publisher**: An API publisher can discover, create, publish, delete, test, and manage an API.
-- **API Subscriber**: An API subscriber is a developer in a particular organization. An API subscriber can subscribe to an application, manage subscriptions, manage applications, generate API keys, and manage API keys.
-- **Admin**: An administrator is responsible for all administration tasks, including user management, customizing the Developer Portal, managing projects, enabling analytics, managing domains, etc.
-- **Billing Admin**: Is responsible for billing administration that includes viewing tiers, creating and viewing organizations, managing invoices, viewing and creating subscriptions, and viewing and creating payment methods.
-- **Choreo DevOps**: A Choreo DevOps user is a user with access to the Choreo DevOps portal, enabling them to actively manage, ensure dependable deployment, and monitor components.
-- **Developer** : A user who can develop, deploy, and manage cloud native applications at scale.
-- **External API subscriber**: External API subscribers are API consumers who have access only to the API Developer Portal. They can join an organization with the sole purpose of consuming APIs.
-- **Environment Manager (Deprecated)**: Manages deployment environments.
+- **Admin**: Performs all administrative tasks including user management, Developer Portal customization, project management, analytics configuration, and domain management.
+- **API Publisher**: Discovers, creates, publishes, deletes, tests, and manages APIs.
+- **API Subscriber**: Subscribes to APIs, manages subscriptions and applications, and generates and manages API keys.
+- **Billing Admin**: Handles billing administration including viewing tiers, managing organizations and invoices, and managing subscriptions and payment methods.
+- **Choreo DevOps**: Manages deployment, monitoring, and reliability of components in Choreo.
+- **Choreo Platform Engineer**: Performs infrastructure, governance, service mesh, and monitoring tasks.
+- **Developer**: Develops, deploys, and manages cloud-native applications at scale.
+- **External API Subscriber**: Consumes APIs with Developer Portal access and can join an organization exclusively for API usage.
+- **Environment Manager (Deprecated):** Previously responsible for managing deployment environments.
+
+_Note: The **Choreo DevOps** role has been replaced with the **Choreo Platform Engineer** role. However, organizations that previously had Choreo DevOps role will continue to see and use both roles with their existing functionality._
## Organization ID
@@ -47,9 +51,8 @@ The Organization ID serves as a unique identifier for each organization. To get
1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
2. Click on the **Organization** list on the header and select your organization.
-3. In the left navigation, click **Settings**.
-4. In the header, click the **Organization** list. This will open the organization level settings page.
-5. Under **Organization** click **Copy ID**.
+3. In the left navigation, click **User Management** and then click on **Users**.
+4. Click **Copy ID**.
## Organization Handle
@@ -57,5 +60,5 @@ The organization handle is a unique string that directly corresponds to your org
1. Go to [https://console.choreo.dev/](https://console.choreo.dev/) and sign in. This opens the project home page.
2. Click on the **Organization** list on the header and select your organization.
-3. In the left navigation, click **Settings**.
-4. Under **Organization** click **Copy Handle**.
+3. In the left navigation, click **User Management** and then click on **Users**.
+4. Click **Copy Handle**.
diff --git a/en/pe-docs/docs/choreo-concepts/project.md b/en/pe-docs/docs/choreo-concepts/project.md
new file mode 100644
index 0000000000..4f1f6cf9f0
--- /dev/null
+++ b/en/pe-docs/docs/choreo-concepts/project.md
@@ -0,0 +1,13 @@
+# Project
+
+A project in Choreo is a logical group of related components that typically represent a single cloud native application. A project consists of one or more components. All components within a project can ideally be (but is not restricted to) in a single GitHub repository under different paths. This is also known as the monorepo architecture.
+
+At deployment time, all components within a given project are deployed into a single namespace of the Kubernetes cluster. Components within a project can be exposed to the public internet, internally to the rest of the organization, or privately within the project only. A project in Choreo is represented as a cell with regard to the [Cell-based architecture](https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md). The following diagram illustrates a project and how the components within a project are laid out at runtime:
+
+{.cInlineImage-full}
+
+
+
+
+
+
diff --git a/en/pe-docs/docs/choreo-concepts/resource-hierarchy.md b/en/pe-docs/docs/choreo-concepts/resource-hierarchy.md
new file mode 100644
index 0000000000..b3b535a55e
--- /dev/null
+++ b/en/pe-docs/docs/choreo-concepts/resource-hierarchy.md
@@ -0,0 +1,25 @@
+# Resource Hierarchy
+
+
+The following diagram depicts the high-level resources and their relationships in Choreo.
+
+{.cInlineImage-full}
+
+## Organizations and data planes
+
+Data planes are connected to the organization and are available for all projects within the organization. When you create an environment in a project, the data plane connected to the organization is linked with an automatically generated Kubernetes namespace.
+
+## Environments and data planes
+
+Choreo allows multiple Kubernetes clusters to be associated with an environment. This enables you to build highly resilient and resource-efficient solutions that utilize multiple clusters. Choreo synchronizes your applications and workloads between associated clusters in an environment, allowing you to perform multi-cluster deployment with a single click.
+
+The following diagram illustrates how multiple clusters associate with different environments:
+
+{.cInlineImage-full}
+
+!!! info "Note"
+ It is not necessary to use a different cluster per environment. You can create multiple environments on the same cluster. The above diagram is an example of a specific solution. Your application architecture may require a different configuration than what is depicted.
+
+## Components and environments
+
+Components belong to a project in Choreo, and environments are provisioned per project. When a component is deployed, it is deployed as a container to the specified environment. Once deployed, you can promote the container image across the environments available in the project.
\ No newline at end of file
diff --git a/en/pe-docs/docs/db-and-services/databases/add-choreo-managed-databases-and-caches-to-the-marketplace.md b/en/pe-docs/docs/db-and-services/databases/add-choreo-managed-databases-and-caches-to-the-marketplace.md
new file mode 100644
index 0000000000..ae2bd02e2e
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/databases/add-choreo-managed-databases-and-caches-to-the-marketplace.md
@@ -0,0 +1,46 @@
+# Add Choreo-Managed Databases and Caches to the Marketplace
+
+When you create a Choreo-managed database or cache, you can add it to the Marketplace, making it available for consumption through a connection.
+
+!!! note
+ To add a Choreo-managed database or cache to the Marketplace, you must import at least one credential for it.
+
+## Step 1: Import credentials
+
+To import credentials, you can either use the default super admin credentials or the credentials you create using the super admin credentials. When you create a database or cache server, super admin credentials are generated by default. You can use these super admin credentials to create new user credentials. The steps to create new user credentials depend on the type of database or cache you are using.
+
+You can use the imported credentials to create a connection. During connection setup, you must select credentials for each database from the list of available credentials.
+
+To import credentials for a database, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. Go to the Choreo Console header and select your organization from the **Organization** list.
+3. In the left navigation menu, click **DB & Services** and then click **Databases**.
+4. Click on a required database to view its details.
+5. Click the **Databases** tab.
+6. Click to expand the database for which you want to import credentials, then click **Import Credentials**.
+7. In the **Import Credentials** dialog, do one of the following depending on your requirements:
+
+ - Select **Use Created Credentials** and specify the following:
+ - A display name for the credentials.
+ - The database credentials you created to use when setting up database connections in Choreo.
+ - The environment where you want to use the credentials.
+
+ The steps to create new user credentials depend on the type of database or cache you are using. In general, you must log in to your database server as the super admin using a command-line interface or a database management tool. Then, create new database users with the required permission levels.
+
+ - Select **Use Super Admin Credentials** and specify the following:
+ - A display name for the credentials.
+ - The environment where you want to use the credentials.
+
+8. Click **Save**.
+
+!!! tip
+ Choreo allows you to delete imported credentials to prevent their use when establishing new connections. However, deleting credentials will not affect any existing database connections that are already using them.
+
+## Step 2: Add the database or cache to the Marketplace
+
+- On the **Databases** tab, click **+Add to Marketplace** corresponding to the database you want to add.
+
+Once the database is added to the Marketplace, it can be consumed via a connection.
+!!! note
+ To remove a database or cache that you added to the Marketplace, click the corresponding **Remove from Marketplace**. This action prevents new connections to the removed database, but existing connections remain unaffected.
diff --git a/en/pe-docs/docs/db-and-services/databases/choreo-managed-caches.md b/en/pe-docs/docs/db-and-services/databases/choreo-managed-caches.md
new file mode 100644
index 0000000000..0772c1d203
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/databases/choreo-managed-caches.md
@@ -0,0 +1,128 @@
+# Choreo-Managed Cache
+
+Fully compatible with legacy Redis® OSS.
+
+Choreo-Managed Cache provides fully-managed in-memory NoSQL databases on AWS, Azure, GCP, and Digital Ocean and can be used as a cache, database, streaming engine, or message broker.
+
+## Create a Choreo-Managed Cache
+
+Follow the steps below to create a Choreo-Managed Cache:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then click **Databases**.
+4. Click **+ Create** and select **Choreo-Managed Cache** as the data store type. Provide a display name for this server and follow the instructions.
+5. Select a preferred cloud provider (AWS, Azure, GCP, or Digital Ocean).
+ - The cloud provider provisions the compute and storage infrastructure for your data store.
+ - The functionality remains the same across cloud providers, though service plans and costs may differ.
+6. Select a region for your data store.
+ - Available regions depend on the selected cloud provider. Choreo currently supports US and EU regions across all providers.
+7. Select a service plan.
+ - Service plans vary in terms of dedicated CPU, memory (RAM), and storage space allocated for your data store, as well as high-availability configurations for production use cases.
+8. Click **Create**.
+
+!!! Note -
+ Once the Choreo-Managed Cache is created, you can add it to the marketplace so developers can discover these and use them in their applications. For more details, see [Add Choreo-Managed Databases and Caches to the Marketplace.](../add-choreo-managed-databases-and-caches-to-the-marketplace)
+
+## Connect to your Choreo-Managed Cache
+
+To connect to your Choreo-Managed Cache, follow these guidelines:
+
+- Choreo-Managed Cache instances accept traffic from the internet by default. You can restrict access to specific IP addresses and CIDR blocks under **Advanced Settings**.
+- Use any legacy Redis® OSS compatible driver (in any programming language) to connect to your Choreo-Managed Cache.
+- You can find the connection parameters in the **Overview** section in the Choreo Console. Note that Choreo-Managed Cache enforces TLS.
+
+## High availability and automatic backups
+
+The high availability and the automatic backup retention periods for a Choreo-Managed Cache can vary as follows depending on the service plan you select.
+
+| Service plan | High availability | Backup features | Backup history |
+| ------------ | -------------------------------------------------------------------------------------------------------------------| ---------------------------------------- | -------------- |
+| Hobbyist | Single-node with limited availability. | Single backup only for disaster recovery | None |
+| Startup | Single-node with limited availability. | Single backup only for disaster recovery | 1 day |
+| Business | Two-node (primary + standby) with higher availability (automatic failover if the primary node fails). | Automatic backups | 3 days |
+| Premium | Three-node (primary + standby + standby) with highest availability (automatic failover if the primary node fails). | Automatic backups | 13 days |
+
+In general, service plans are recommended for production scenarios due to the following reasons:
+
+- Provides another physical copy of the data in case of hardware, software, or network failures.
+- Reduces the data loss window in disaster scenarios.
+- Ensures quicker restoration with controlled failover in case of failures, as the standby is already installed and running.
+
+### Automatic backups
+
+- Choreo runs full backups daily to automatically backup Choreo-Managed Caches and has write-ahead logs (WAL) copied at 5-minute intervals or for every new file generated.
+- Choreo encrypts all backups at rest.
+- Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the data store.
+
+### Failure recovery
+
+- **Minor failures**: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once it automatically restarts the crashed process or when it restores the network access.
+
+- **Severe failures**: Failures such as losing a node entirely in case of hardware or severe software problems, require more drastic recovery measures. The monitoring infrastructure automatically detects a failing node when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created.
+ - In the event of a data store failover, the service URI of your service remains the same; only the IP address will change to point to the new primary node.
+ - Hobbyist and Startup plans provide a single node, and in case of failure, a new node starts up, restores its state from the latest available backup, and resumes serving traffic.
+ - As there is just a single/primary node, the caching service becomes unavailable for the duration of the restoration operation. Therefore, all write operations made since the last backup will be lost.
+
+## Limitations
+
+### Connection limits
+
+The number of simultaneous connections in a Choreo-Managed Cache depends on the total available memory on the server instances.
+
+You can use the following to estimate:
+
+```
+max_number_of_connections = 4 x m
+```
+
+Here, `m` represents the memory in megabytes, where at least 10,000 connections are available, even on the smallest servers.
+For example, on a server with 4GB memory (4,096 MB), the simultaneous connections are:
+
+```
+4 x 4096 = 16384 // 16k connections
+```
+
+This number is estimated by the exact available memory so it can vary between different plans and cloud providers. To see the exact maximum connections allowed, use the \* redis-cli and info command as follows:
+
+```
+echo "info" | redis-cli -u REDIS_URI | grep maxclients
+```
+
+### Restricted commands
+
+To maintain the stability and security of a managed environment, Choreo restricts certain commands on Choreo-Managed Cache services.
+
+!!! note "Support for Lua scripts on Choreo-Managed Cache"
+ - Choreo-Managed Cache has built-in support for running Lua scripts to perform various actions directly on the server. Scripting is typically controlled using the `EVAL`, `EVALSHA`, and `SCRIPT LOAD` commands.
+ - For all newly-created cache instances, `EVAL`, `EVALSHA`, and `SCRIPT LOAD` commands are enabled by default.
+
+The following commands are disabled on Choreo:
+
+- `bgrewriteaof`: Initiates a background append-only file rewrite.
+- `cluster`: Manages Caching cluster commands.
+- `command`: Provides details about all Caching commands.
+- `debug`: Contains sub-commands for debugging Caching.
+- `failover`: Manages manual failover of a master to a replica.
+- `migrate`: Atomically transfers a key from one caching instance to another.
+- `role`: Returns the role of the instance in the context of replication.
+- `slaveof`: Makes the server a replica of another instance, or promotes it as master.
+- `acl`: Manages caching access control lists.
+- `bgsave`: Creates a snapshot of the data set into a dump file.
+- `config`: Alters the configuration of a running caching server.
+- `lastsave`: Returns the UNIX timestamp of the last successful save to disk.
+- `monitor`: Streams back every command processed by the Caching server.
+- `replicaof`: Makes the server a replica of another instance.
+- `save`: Synchronously saves the dataset to disk.
+- `shutdown`: Synchronously saves the dataset to disk and then shuts down the server.
+
+The following `eval` commands are also disabled:
+
+- `eval`: Executes a Lua script server-side.
+- `eval_ro`: Read-only variant of the eval command.
+- `evalsha`: Executes a script cached on the server side by its SHA1 digest.
+- `evalsha_ro`: Read-only variant of the evalsha command.
+- `fcall`: Calls a Caching function.
+- `fcall_ro`: Read-only variant of the fcall command.
+- `function`: Manages Caching functions.
+- `script`: Manages the script cache.
diff --git a/en/pe-docs/docs/db-and-services/databases/choreo-managed-databases-and-caches.md b/en/pe-docs/docs/db-and-services/databases/choreo-managed-databases-and-caches.md
new file mode 100644
index 0000000000..50369f335a
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/databases/choreo-managed-databases-and-caches.md
@@ -0,0 +1,33 @@
+# Choreo-Managed Databases, Vector Databases, and Caches
+
+Choreo allows you to create PostgreSQL and MySQL databases as well as Choreo-Managed Cache instances on all major cloud providers (AWS, Azure, GCP, and DigitalOcean) as fully Choreo-managed platform services.
+These databases and caches can be seamlessly provisioned to offer persistence and caching capabilities for all your Choreo components. Choreo provides various service plans for each type, ranging from smaller instances for development purposes to production-grade databases with automatic backups and high-availability multi-nodes.
+
+!!! info "Note"
+ - The capability to create Choreo-managed databases, vector databases, and cache services is available only for paid Choreo users.
+ - Billing for these services will be included in your Choreo subscription, with pricing varying based on the service plan of the resources you create. For more details, see [Choreo Platform Services Billing](../../references/choreo-platform-services-billing-and-upgrades.md#platform-service-billing-information).
+
+!!!Tip "Explore the free trial"
+ Choreo provides a 7-day free trial for all database types on the 'Hobbyist' service plan, available to free-tier users.
+
+## PostgreSQL on Choreo
+
+PostgreSQL (also known as Postgres), is an open-source object-relational database management system. You can create PostgreSQL databases on Choreo as fully Choreo-managed, flexible SQL databases that are ideal for both structured and unstructured data. If you want to perform an efficient vector similarity search, you can create a PostgreSQL vector database.
+
+- [Create a PostgreSQL database on Choreo](./choreo-managed-postgresql-databases.md)
+
+## MySQL on Choreo
+
+MySQL is a user-friendly, flexible, open-source relational database management system with a well-established history in the SQL database realm. Choreo allows you to swiftly create fully Choreo-managed MySQL databases, enabling rapid setup and utilization.
+
+- [Create a MySQL database on Choreo](./choreo-managed-mysql-databases.md)
+
+## Choreo-Managed Cache
+
+A fully-managed cache compatible with legacy Redis® OSS. A versatile, in-memory NoSQL database that serves as a cache, database, streaming engine, and message broker. Choreo-managed Cache allows you to have fully-managed instances that can be swiftly provisioned and integrated into your applications within minutes.
+
+- [Create a Choreo-managed Cache](./choreo-managed-caches.md)
+
+
+ PostgreSQL, MySQL, and Redis® are trademarks and property of their respective owners. All product and service names used in this documentation are for identification purposes only.
+
diff --git a/en/pe-docs/docs/db-and-services/databases/choreo-managed-mysql-databases.md b/en/pe-docs/docs/db-and-services/databases/choreo-managed-mysql-databases.md
new file mode 100644
index 0000000000..e18cc23a77
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/databases/choreo-managed-mysql-databases.md
@@ -0,0 +1,77 @@
+# Choreo-managed MySQL Databases
+
+MySQL on Choreo offers fully managed, flexible relational databases on AWS, Azure, GCP, and Digital Ocean.
+
+## Create a Choreo-managed MySQL database
+
+Follow the steps below to create a Choreo-managed MySQL database:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **DB & Services** and then **Databases**.
+4. Click **Create** and select **MySQL** as the database type. Provide a display name for this server and follow the instructions.
+5. Select your preferred cloud provider from AWS, Azure, GCP, and Digital Ocean.
+ - Choreo uses the cloud provider to provision the compute and storage infrastructure for your database.
+ - There is no functional difference between databases created on different cloud providers, apart from changes to service plans (and associated costs).
+6. Choose the region for your database.
+ - Available regions will depend on the selected cloud provider. Choreo currently supports US and EU regions across all providers.
+7. Select the service plan.
+ - Service plans vary in the dedicated CPU, memory (RAM), storage space allocated for your database, the backup retention periods, and high-availability configurations for production use cases.
+
+!!! Note -
+ Once the database is created, you can add it to the marketplace so developers can discover these databases and use them in their applications. For more details, see [Add Choreo-Managed Databases and Caches to the Marketplace.](../add-choreo-managed-databases-and-caches-to-the-marketplace)
+
+## Connect to your Choreo-managed MySQL database
+
+To connect to your Choreo-managed MySQL database, consider the following guidelines:
+
+- MySQL databases accept traffic from the internet by default. You can restrict access to specific IP addresses and CIDR blocks under **Advanced Settings**.
+
+- You can use any MySQL driver, ORM, or supported generic SQL library (may depend on the programming language) to connect to the database.
+- You can find the connection parameters in the **Overview** section in the Choreo Console under the relevant database.
+
+## High Availability and Automatic Backups
+
+The high availability characteristics and the automatic backup retention periods for Choreo-managed MySQL databases vary based on your service plan as explained below:
+
+| Service Plan | High Availability | Backup Retention Time |
+|--------------|--------------------------------------------------------------------|-----------------------|
+| Hobbyist | Single-node with limited availability | None |
+| Startup | Single-node with limited availability | 2 days |
+| Business | Two-node (primary + standby) with higher availability | 14 days |
+| Premium | Three-node (primary + standby + standby) with highest availability | 30 days |
+
+In general, we recommend service plans for production scenarios for multiple reasons:
+- Provides another physical copy of the data in case of hardware, software, or network failures.
+- Typically reduces the data loss window in disaster scenarios.
+- Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running.
+
+### Automatic Backups
+
+- Choreo runs full backups daily to automatically back up Choreo-managed MySQL databases and record binary logs continuously.
+Choreo encrypts all backups at rest.
+
+- Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database.
+
+## Connection Limits
+
+The maximum number of simultaneous connections to MySQL databases is fixed for each service plan and depends on how much RAM your service plan offers.
+
+!!! note
+ An `extra_connection` with a value of `1` is added for system processes for all MySQL databases, regardless of the service plan.
+
+### For plans under 4 GiB RAM
+
+For plans under 4 GiB of RAM, the number of allowed connections is `75` per GiB:
+
+```
+max_connections = 75 x RAM + extra_connection
+```
+
+### For plans with over 4 GiB RAM:
+
+For plans with 4 GiB or more RAM, the number of allowed connections is `100` per GiB:
+
+```
+max_connections = 100 x RAM + extra_connection
+```
diff --git a/en/pe-docs/docs/db-and-services/databases/choreo-managed-postgresql-databases.md b/en/pe-docs/docs/db-and-services/databases/choreo-managed-postgresql-databases.md
new file mode 100644
index 0000000000..fceb42c80f
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/databases/choreo-managed-postgresql-databases.md
@@ -0,0 +1,85 @@
+# Choreo-Managed PostgreSQL Databases and Vector Databases
+
+PostgreSQL on Choreo offers fully Choreo-managed, efficient object-relational databases on AWS, Azure, GCP, and Digital Ocean. Additionally, Choreo allows you to create fully-managed PostgreSQL vector databases if you want to perform efficient vector similarity search.
+
+## Create a Choreo-managed PostgreSQL database
+
+Follow the steps below to create a Choreo-managed PostgreSQL database:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev/).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then **Databases**.
+4. Click **Create** and select **PostgreSQL** as the database type. Provide a display name for this server and follow the instructions.
+5. Select your preferred cloud provider from AWS, Azure, GCP, or Digital Ocean.
+ - The cloud provider is used to provision the compute and storage infrastructure for your database.
+ - There is no functional difference between databases created on different cloud providers, apart from changes to service plans (and associated costs).
+6. Choose the region for your database.
+ - Available regions will depend on the selected cloud provider. Choreo currently supports US and EU regions across all providers.
+7. Select the service plan.
+ - Service plans vary in the dedicated CPU, memory (RAM), storage space allocated for your database, the backup retention periods, and high-availability configurations for production use cases.
+
+## Create a Choreo-managed PostgreSQL vector database
+
+Follow the steps below to create a Choreo-managed PostgreSQL vector database:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev/).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then **Vector Databases**.
+4. Follow steps 4 onwards in the [Create a Choreo-managed PostgreSQL database](#create-a-choreo-managed-postgresql-database) section.
+
+!!! Note -
+ Once the database is created, you can add it to the marketplace so developers can discover these databases and use them in their applications. For more details, see [Add Choreo-Managed Databases and Caches to the Marketplace.](../add-choreo-managed-databases-and-caches-to-the-marketplace)
+
+
+## Connecting to your Choreo-managed PostgreSQL database
+
+To connect to your Choreo-managed PostgreSQL database, consider the following guidelines:
+
+- PostgreSQL databases accept traffic from the internet by default. You can restrict access to specific IP addresses and CIDR blocks under **Advanced Settings**.
+- You can use any PostgreSQL driver, ORM, or supported generic SQL library (may depend on the programming language) to connect to the database.
+- The connection parameters can be found in the **Overview** section in the Choreo Console under the relevant database.
+
+
+## High Availability and Automatic Backups
+
+The high availability characteristics and the automatic backup retention periods for Choreo-managed PostgreSQL databases vary based on the selected service plan as shown below.
+
+| Service Plan | High Availability | Backup Retention Time |
+|--------------|--------------------------------------------------------------------|-----------------------|
+| Hobbyist | Single-node with limited availability | None |
+| Startup | Single-node with limited availability | 2 days |
+| Business | Two-node (primary + standby) with higher availability | 14 days |
+| Premium | Three-node (primary + standby + standby) with highest availability | 30 days |
+
+Service plans with standby nodes are generally recommended for production scenarios for multiple reasons:
+- Provides another physical copy of the data in case of hardware, software, or network failures.
+- Typically reduces the data loss window in disaster scenarios.
+- Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running.
+
+### Automatic Backups
+
+
+- Choreo runs full backups daily to automatically back up Choreo-managed PostgreSQL databases and copies the write-ahead logs (WAL) at 5-minute intervals or for every new file generated.
+Choreo encrypts all backups at rest.
+
+- Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database.
+
+### Failure Recovery
+
+- **Minor failures**: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once Choreo automatically restarts the crashed process or when Choreo restores the network access.
+
+- **Severe failures**: To handle severe failures such as losing a node entirely in case of hardware or severe software problems, requires more drastic recovery measures. The monitoring infrastructure automatically detects a failing node, both when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created.
+> - In the event of database failover, the Service URI of your service remains the same; only the IP address will change to point to the new primary node.
+> - Hobbyist and Startup plan provide a single node, and in case of failure, a new node starts up, restores its state from the latest available backup, and resumes serving traffic.
+In this plan, as there is just a single node providing the service, the service will become unavailable for the duration of the restoration. In addition, any write operations made since the backup of the latest WAL file will be lost. Typically, this time window is limited to either five minutes of time or one WAL file.
+
+## Connection limits
+
+The following connection limits apply to Choreo-managed PostgreSQL databases based on the selected service plan.
+
+| Service Plan | Max Connections |
+|----------------------------|-----------------|
+| Hobbyist | 25 |
+| Startup/Business/Premium-4 | 100 |
+| Business-16 | 400 |
+| Premium-8 | 200 |
diff --git a/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-gen-ai-services.md b/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-gen-ai-services.md
new file mode 100644
index 0000000000..346148b07f
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-gen-ai-services.md
@@ -0,0 +1,91 @@
+# Integrate and Manage Generative AI Services
+
+Generative AI (GenAI) services leverage advanced machine learning models to create original content such as text, images, music, or code, by identifying and learning patterns from existing data. Powered by deep neural networks and other machine learning models, these services can generate human-like outputs in various formats. This versatility makes GenAI ideal for tasks such as content creation, image generation, conversation automation, etc.
+
+Choreo enables seamless integration with GenAI services, allowing the developers to incorporate these capabilities within their applications.
+
+## Register a GenAI service
+
+To seamlessly integrate a GenAI service into an application deployed in Choreo, you need to register it. Once registered, the service becomes available in the Internal Marketplace, allowing developers to consume it via a Connection.
+
+You can register a GenAI service at two levels:
+
+ - Organization level: This makes the service accessible from any project within the organization.
+ - Project level: This restricts the service to a specific project.
+
+### Prerequisites
+
+Before registering a GenAI service, obtain the following details from the service provider:
+ - API key.
+ - Service URL.
+ - Other necessary parameters. For example, client credentials.
+
+To register a GenAI service, follow these steps:
+
+!!! note
+ Ensure that you register the service at the appropriate level depending on the usage. If the service must be shared among multiple projects, register it at the organization level. Otherwise, register it at the project level.
+
+### Step 1: Select a service provider
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. Follow one of these steps depending on your requirements:
+ - To register a GenAI service at the organization level, go to the Choreo Console header and select your organization from the **Organization** list.
+ - To register a GenAI service at the project level, go to the Choreo Console header and select your project from the **Project** list.
+3. In the left navigation menu, click **DB & Services** and then click **GenAI Services**.
+4. Click **+ Register**.
+5. Select a service provider.
+6. Click **Next**.
+
+### Step 2: Provide service details
+
+1. Under **Register Service**, enter the following details for the service:
+ - A **Name** and **Version**.
+ - The **Service URL**.
+
+2. Click **Next**.
+
+### Step 3: Add configurations
+
+1. Under **Add Configurations**, enter details for the service.
+
+ !!! note
+ - The configuration details to enter vary depending on the selected service provider.
+ - To successfully register a service, ensure you provide all the required configurations.
+
+2. Click **Register**.
+
+Once registered, the GenAI service is automatically listed in the Internal Marketplace.
+
+If you want to remove the service from the Internal Marketplace, see [Remove a GenAI service from the Internal Marketplace](#remove-a-genai-service-from-the-internal-marketplace).
+
+
+## Manage GenAI services
+
+When you create a GenAI service, it gets listed in the **GenAI Services** list.
+
+### View or update GenAI service details
+
+To view or update a GenAI service, follow these steps.
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the left navigation menu, click **DB & Services** and then click **GenAI Services**. This lists all the GenAI services you have created.
+3. Click on a service to view or update its details.
+ - **General Details**: Displays service metadata. For example, the service name, overview, labels, etc.
+ - **Service Definition**: Displays the service definition. To update the definition, click **Upload** and select the new definition file.
+
+### Add a GenAI service to the Internal Marketplace
+
+!!! info
+ To add a GenAI service to the Internal Marketplace, you must provide all the required configurations.
+
+1. In the Choreo Console left navigation menu, click **DB & Services** and then click **GenAI Services**.
+2. Click on the service you want to add to the Internal Marketplace.
+3. Click **Add to Marketplace**.
+
+### Remove a GenAI service from the Internal Marketplace
+
+1. In the Choreo Console left navigation menu, click **DB & Services** and then click **GenAI Services**.
+2. Click on the service you want to remove from the Internal Marketplace.
+3. Click **Remove from Marketplace**.
+
+This removes the service from the Internal Marketplace. Therefore, the service will not be available to consume via a Connection. However, the connections created before removal will continue to work as expected.
diff --git a/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-third-party-services.md b/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-third-party-services.md
new file mode 100644
index 0000000000..f05e1348b9
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/external-services/integrate-and-manage-third-party-services.md
@@ -0,0 +1,118 @@
+# Integrate and Manage Third-Party Services
+
+Third-party services are external applications, platforms, or APIs you can integrate with your system to enhance its functionality, extend capabilities, or provide specialized features. These services are developed and maintained by external entities, providing expertise in specific domains outside your application's core focus. Once the third party services are registered, the developers can discover these third party APIs and use them in their applications.
+
+The following topics walk you through the steps to seamlessly register, manage, and consume third-party services, adhering to API-first principles.
+
+## Register a third-party service in Choreo
+
+To use a third-party service in Choreo, you need to register it. Once registered, the service becomes available in the Internal Marketplace, allowing developers to consume it via a Connection.
+
+You can register a third-party service at two levels:
+
+ - Organization level: This makes the service accessible from any project within the organization.
+ - Project level: This restricts the service to a specific project.
+
+Choreo allows you to register the following third-party service types:
+
+ - REST APIs
+ - GraphQL APIs
+ - Asynchronous APIs
+ - SOAP
+ - gRPC
+
+### Prerequisites
+
+Before registering a third-party service, obtain the following details from the service provider:
+
+ - API specification. For example, OpenAPI or GraphQL schema.
+ - Service URL.
+ - Other necessary parameters. For example, client credentials, API keys, etc.
+
+To register a third-party service, follow these steps:
+
+!!! note
+ Ensure you register the service at an appropriate level depending on the service usage. If the service must be shared among multiple projects, register it at the organization level. Otherwise, register it at the project level.
+
+### Step 1: Provide basic details
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. Follow one of these steps depending on your requirement:
+ - To register a third-party service at the organization level, go to the Choreo Console header and select your organization from the **Organization** list.
+ - To register a third-party service at the project level, go to the Choreo Console header and select your project from the **Project** list.
+3. In the left navigation menu, click **DB & Services** and then click **Third-Party Services**.
+4. Click **+ Register**.
+5. Provide details for the service:
+ - Enter a **Name** and **Version**.
+ - Upload the service definition file. This automatically detects the service type.
+ - Verify the **Service Type**.
+6. Click **Define Endpoints**.
+
+Now you are ready to define endpoints for the service.
+
+### Step 2: Define service endpoints
+
+An endpoint is a set of parameters required to connect to a service. The required parameters are service URL, API key header, etc.
+These parameters provide the necessary information for a client application to interact with the service.
+
+To define service endpoints, follow these steps:
+
+1. Under **Define New Endpoint**,
+ - Enter a **Name** for the endpoint.
+ - Enter the **Endpoint URL**.
+
+2. Under **Additional Parameters**, add any other parameters required to connect to the service.
+ For example, API key, authorization token, etc.
+
+ !!! note
+ - If you want to keep a parameter confidential, select the **Secret** checkbox.
+ - If there are multiple endpoints, the parameter names will be the same for all the endpoints.
+
+3. Select the environments where the endpoint should be accessible.
+
+ !!! note
+ Service consumers can create connections to the endpoint only from the selected environments.
+
+4. Click **OK**.
+
+5. If you want to add more endpoints, click **+ New Endpoint** and repeat steps 1 to 4.
+
+6. Click **Register**.
+
+When you define all required parameter values for at least one endpoint, the service will be automatically listed in the Internal Marketplace. Otherwise, you must [add the service to the Internal Marketplace](#add-a-third-party-service-to-the-internal-marketplace) after providing the endpoint values.
+
+If you want to remove a third-party service from the Internal Marketplace, see [Remove a third-party service from the Internal Marketplace](#remove-a-third-party-service-from-the-internal-marketplace).
+
+For details on managing third-party services, see [Manage third-party service](#manage-third-party-services).
+
+## Manage third-party services
+
+When you create a third-party service, it gets listed in the **Third-Party Services** list.
+
+### View or update third-party service details
+
+To view or update a third-party service, follow these steps.
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the left navigation menu, click **DB & Services** and then click **Third-Party Services**. This lists all the third-party services you have created.
+3. Click on a service to view or update its details.
+ - **General Details**: Displays service metadata. For example, the service name, overview, labels, etc.
+ - **Service Definition**: Displays the service definition. To update the definition, click **Upload** and select the new definition file.
+ - **Endpoints**: Displays service endpoint details. You can add, modify, or delete service endpoints.
+
+### Add a third-party service to the Internal Marketplace
+
+!!! info
+ To add a third-party service to the Internal Marketplace, you must provide all required parameters for at least one endpoint.
+
+1. In the Choreo Console left navigation menu, click **DB & Services** and then click **Third-Party Services**.
+2. Click on the service you want to add to the Internal Marketplace.
+3. Click **Add to Marketplace**.
+
+### Remove a third-party service from the Internal Marketplace
+
+1. In the Choreo Console left navigation menu, click **DB & Services** and then click **Third-Party Services**.
+2. Click on the service you want to remove from the Internal Marketplace.
+3. Click **Remove from Marketplace**.
+
+This removes the service from the Internal Marketplace. Therefore, the service will not be available to consume via a Connection. However, the connections created before removal will continue to work as expected.
diff --git a/en/pe-docs/docs/db-and-services/message-brokers/choreo-managed-message-brokers.md b/en/pe-docs/docs/db-and-services/message-brokers/choreo-managed-message-brokers.md
new file mode 100644
index 0000000000..49db0d3d81
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/message-brokers/choreo-managed-message-brokers.md
@@ -0,0 +1,13 @@
+# Choreo Managed Message Brokers
+
+Choreo allows you to create Apache Kafka services across major cloud providers (AWS, Azure, GCP, and DigitalOcean) as Choreo-managed platform services for your message brokering needs. These fully managed Kafka instances can seamlessly integrate with Choreo components, providing scalable messaging for real-time data pipelines and event-driven applications. Choreo offers multiple Kafka service plans, ranging from lightweight instances for development purposes to production-grade clusters with automatic backups, high-availability multi-nodes, and partitioning.
+
+!!! info "Note"
+ - Kafka service creation is available only for paid Choreo organizations.
+ - Kafka service billing will be included in your Choreo subscription, with pricing varying based on the service plan of the resources you create. For more details, see [Choreo Platform Services Billing](../../references/choreo-platform-services-billing-and-upgrades.md#platform-service-billing-information).
+
+## Apache Kafka on Choreo
+
+Apache Kafka is an open-source platform for real-time event streaming and handling large-scale, event-driven data. You can create Kafka services on Choreo as fully-managed, scalable, message brokers, ideal for handling large volumes of event-driven data.
+
+- [Create a Choreo-managed Kafka service](./create-choreo-managed-kafka-services.md)
diff --git a/en/pe-docs/docs/db-and-services/message-brokers/configure-a-kafka-service.md b/en/pe-docs/docs/db-and-services/message-brokers/configure-a-kafka-service.md
new file mode 100644
index 0000000000..b556bdaeb1
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/message-brokers/configure-a-kafka-service.md
@@ -0,0 +1,75 @@
+# Configure a Kafka Service
+
+After creating a Kafka service, you can create topics, configure advanced settings, and manage access to ensure secure and efficient message processing.
+
+## Create a Kafka topic
+
+Kafka topics are logical channels used to organize and transfer messages between producers and consumers. They form the core of Kafka's architecture, enabling data streams to be written and read. Kafka topics can also be partitioned to improve scalability and fault tolerance.
+
+To create a Kafka topic, follow these steps:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then click **Message Brokers**.
+4. In the **Message Brokers** list, click the Kafka service for which you want to create a topic.
+5. Click the **Topics** tab.
+6. Click **+ Create**.
+7. In the **Create Topic** dialog that opens,
+ 1. Enter a name for the topic.
+ 2. To configure advanced settings, click to expand **Advanced Configurations** and apply the required settings. For details, see [Advanced topic configurations](#advanced-topic-configurations).
+8. Click **Create**.
+
+### Advanced topic configurations
+
+Choreo allows you to customize settings for Kafka topics, including the number of partitions, replication factor, cleanup policy, retention size (bytes), retention duration (hours), and the minimum number of in-sync replicas.
+
+**Cleanup Policy:** Determines how messages that reach their retention limit are handled. There are three options:
+
+- Delete (default): Messages are removed when the retention limit is exceeded.
+- Compact: Retains only the latest record for each unique key, ensuring only the most recent data is kept.
+- Compact and Delete: Combines both approaches, where old records are deleted based on retention limits, but the latest record for each key is retained.
+
+**Replication:** Sets the number of partition copies to ensure data durability. The default is 3.
+
+**Partitions:** Defines the number of segments the topic should be divided into for parallel processing. The default is 1 partition.
+
+**Retention Bytes:** Sets the maximum size of retained messages. Older messages are discarded on reaching this limit. The default is unlimited (-1).
+
+**Retention Hours:** Defines the retention period for messages before deletion. The default is 168 hours (7 days).
+
+**Min In-Sync Replicas:** Specifies the minimum number of replicas that must acknowledge a write for it to be considered successful. The default is 2.
+
+## Manage service users and access control lists
+
+Choreo-managed Kafka services use access control lists (ACLs) and user definitions to control access to topics. You can manage users and ACL entries from the corresponding tabs on the Kafka service details page.
+
+### Manage users
+
+To manage users for a Choreo-managed Kafka service, follow these steps:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then click **Message Brokers**.
+4. In the **Message Brokers** list, click the Kafka service for which you want to manage users.
+5. Click the **Users** tab.
+6. Click **+ Add User**, specify a username, and then click **Add**.
+
+By default, new users do not have any permissions. You can grant necessary permissions to users through access control lists (ACLs).
+
+### Configure access control lists (ACLs)
+
+An ACL entry defines access permission for a user. Each entry includes:
+
+ - Username: The username.
+ - Topic: The associated Kafka topic to grant access to the user.
+ - Permission: The permission to grant the user.
+
+To add an ACL entry, follow these steps:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then click **Message Brokers**.
+4. In the **Message Brokers** list, click the Kafka service for which you want to add an ACL entry.
+5. Click the **Access Control List** tab.
+6. Click **+ Add Entry**, select a username, topic, and permission.
+7. Click **Add**.
diff --git a/en/pe-docs/docs/db-and-services/message-brokers/create-choreo-managed-kafka-services.md b/en/pe-docs/docs/db-and-services/message-brokers/create-choreo-managed-kafka-services.md
new file mode 100644
index 0000000000..8bbbd149b2
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/message-brokers/create-choreo-managed-kafka-services.md
@@ -0,0 +1,33 @@
+# Create Choreo-Managed Kafka Services
+
+Kafka on Choreo offers fully managed, distributed message broker services across AWS, Azure, GCP, and DigitalOcean. These services are designed to handle high-throughput, fault-tolerant data streaming use cases such as real-time analytics, event sourcing, and log aggregation.
+
+!!! info "Note"
+ - Kafka service creation is available only for paid Choreo organizations.
+ - Kafka service billing will be included in your Choreo subscription, with pricing varying based on the service plan of the resources you create. For more details, see [Choreo Platform Services Billing](../../references/choreo-platform-services-billing-and-upgrades.md#platform-service-billing-information).
+
+## Create a Choreo-managed Kafka service
+
+Follow the steps below to create a Choreo-managed Kafka service:
+
+1. Sign in to the Choreo Console at [https://console.choreo.dev/](https://console.choreo.dev).
+2. In the header, click the **Organization** list. This opens the organization home page.
+3. In the left navigation menu, click **DB & Services** and then click **Message Brokers**.
+4. Click **+ Create**.
+5. Specify a display name for the Kafka service and click **Next**.
+6. Select your preferred cloud provider from AWS, Azure, GCP, or Digital Ocean.
+ - The cloud provider provisions the computing and storage infrastructure for your Kafka service.
+ - There is no functional difference between Kafka services across providers except for variations in service plans and associated costs.
+7. Select a region for your Kafka service.
+ - Available regions depend on the selected cloud provider. Choreo currently supports US, EU, and AU regions across all providers.
+8. Select a service plan.
+ - Service plans differ based on the allocation of CPU, memory (RAM), and storage for your Kafka server, as well as backup retention periods and high-availability options suited for production environments.
+9. Click **Create**. This creates the Kafka service and takes you to the **Overview** tab on the service details page.
+
+## Connect to your Choreo-managed Kafka service
+
+- By default, Kafka services accept traffic from the internet. However, if you want to restrict access to specific IP addresses or CIDR blocks, you can configure the necessary advanced settings.
+
+- Choreo secures Kafka connections via client certificate authentication.
+
+- To connect to your Choreo-managed Kafka service, use the connection parameters from the **Overview** tab on the service details page.
diff --git a/en/pe-docs/docs/db-and-services/message-brokers/monitor-a-kafka-service.md b/en/pe-docs/docs/db-and-services/message-brokers/monitor-a-kafka-service.md
new file mode 100644
index 0000000000..21238255f5
--- /dev/null
+++ b/en/pe-docs/docs/db-and-services/message-brokers/monitor-a-kafka-service.md
@@ -0,0 +1,31 @@
+# Monitor a Kafka Service
+
+You can monitor the health and performance of your Kafka services via the service metrics and service logs.
+
+## Service metrics
+
+Service metrics provide real-time insights into the performance of your Kafka service.
+
+To view service metrics for a Kafka service, follow the steps given below:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. On the left navigation menu, click **DB & Services** and then click on **Message Brokers**.
+4. Click on the required message broker and go to the **Metrics** tab on the service details page.
+
+The service metrics include the following:
+
+- **CPU Usage %**: Displays the percentage of CPU resources consumed by the service.
+- **Disk Usage %**: Represents the percentage of disk space utilized by the service.
+- **Disk IO Reads**: Displays the input/output operations per second (IOPS) for disk reads.
+- **Disk IO Writes**: Displays the input/output operations per second (IOPS) for disk writes.
+- **Load Average**: Displays the 5-minute average CPU load, indicating the system's computational load.
+- **Memory Available %**: Represents the percentage of memory resources utilized by the service.
+- **Network Received**: Indicates the volume of network traffic received by the service in bytes per second.
+- **Network Sent**: Indicates the amount of network traffic transmitted by the service in bytes per second.
+
+## Service logs
+
+Service logs provide a detailed record of Kafka service activity, such as producer and consumer operations, connection statuses, and error reports. These logs are essential for troubleshooting issues and analyzing message flow. Logs are retained for up to 4 days.
+
+To view Choreo-managed Kafka service logs, go to the **Logs** tab on the service details page.
diff --git a/en/pe-docs/docs/devops/cd-pipelines/deploying-application-using-choreo-cd-pipeline.md b/en/pe-docs/docs/devops/cd-pipelines/deploying-application-using-choreo-cd-pipeline.md
new file mode 100644
index 0000000000..79927eaaaf
--- /dev/null
+++ b/en/pe-docs/docs/devops/cd-pipelines/deploying-application-using-choreo-cd-pipeline.md
@@ -0,0 +1,66 @@
+# Deploy Applications using Choreo CD Pipeline
+
+Using Choreo, you can easily deploy applications written in different language frameworks (such as Java, Go, NodeJS, Python, etc.) on shared or private data planes.
+
+After building your application, you can deploy it from the **CD Pipelines** page. On this page, you can access the CD pipeline of the selected component.
+
+## Trigger a deployment
+
+Follow below steps to deploy a component,
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. From the left navigation, Click **DevOps** and then click **CD Pipelines**
+4. The setup card will contain the latest built image
+
+ !!! Tip -
+ Click on the image in the **Setup** card to select a different image instead of the latest build.
+
+5. To deploy your application, you can use one of the following options :
+
+ 1. **Configure & Deploy**: This option allows you to set up specific configurations for your component before deploying it. In the subsequent steps after clicking **Configure & Deploy**, you can set environment variables, configure file mounts, and adjust endpoint settings.
+
+ - Environment variables : Apply environment-specific variables via the **Environment Configurations** pane
+ - File mounts : Apply a file mount via the **File Mount** pane
+ - Endpoint settings: Configure endpoint settings via the **Endpoint Details** pane.
+
+ 2. **Deploy**: This option initiates the deployment process using the existing configurations without making any changes.
+
+## Auto Deploy on Build
+
+When **Auto Deploy on Build** is enabled, it triggers an automatic deployment of your application to the first environment upon the completion of each successful build.
+
+!!! Note -
+ The **Auto Deploy on Build** feature, is disabled by default. To enable this feature, toggle on the Auto Deploy on Build option in the **Setup** card.
+
+## Promoting a component to a higher environment
+
+You can go to the CD Pipelines page of a component and manually promote it across environments.
+
+Follow below steps to promote a component to a higher level environment:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. From the left navigation, Click **DevOps** and then click **CD Pipelines**
+4. Click the **Promote** button on the required environment card from which the promotion is initiated.
+
+!!! Note -
+ You may see **Request To Promote** instead of **Promote** if the workflow approvals are enabled and the target environment is a critical environment. See [Submit and Manage Workflow Approval Requests](./submit-and-manage-workflow-approval-requests.md) for more information.
+
+5. In the **Configuration Types** pane, you can either provide new values for the configurations or use the **Development configuration**.
+
+!!! Note -
+ If you have configured any default values for the configurable variables, selecting Use default configuration values allows you to proceed with those values. If not, specify values for the configurable variables.
+
+6. When promoting the component, you can modify environment-specific configurations (environment variables, file mount etc) in the subsequent steps of the promotion flow.
+
+7. Click **Promote**.
+
+## Configurations
+
+### Environment-Independent Configurations
+
+These configurations apply to all environments. To change environment-independent configurations, make the necessary configuration changes via the **Setup** card, and then trigger a new deployment to the initial environment. Once deployed, you can promote the component to higher environments. **Endpoint configurations** can be managed from the **Setup** card.
+
+### Environment-specific configurations
+These configurations apply to a particular environment. To change environment-specific configurations, make the necessary configuration changes via the specific environment card, and trigger a new deployment. From the environment card, you can manage **Configs & Secret** and **Scaling** options.
diff --git a/en/pe-docs/docs/devops/cd-pipelines/manage-continuous-deployment-pipelines.md b/en/pe-docs/docs/devops/cd-pipelines/manage-continuous-deployment-pipelines.md
new file mode 100644
index 0000000000..b6f2dd03d1
--- /dev/null
+++ b/en/pe-docs/docs/devops/cd-pipelines/manage-continuous-deployment-pipelines.md
@@ -0,0 +1,127 @@
+# Manage Continuous Deployment Pipelines
+
+By default, all the organizations in Choreo are provisioned with a default continuous deployment pipeline.
+
+Environments within an organization are applied to projects in the order specified by the continuous deployment pipeline. The organization's default continuous deployment pipeline is applied to all the projects. You can create additional pipelines and customize the sequence in which environments are applied in projects.
+
+## Create a new continuous deployment pipeline
+
+### Prerequisites
+
+- To create a new continuous deployment pipeline in an organization, you must have the `ENVIRONMENT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles.
+
+To create a new pipeline, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+4. On the **CD Pipelines** page, click **+ Create Pipeline** and specify the following details required to create a new pipeline:
+
+ - **Name**: A display name for the new pipeline.
+ - **Mark as Default**: Select if you want to assign this new pipeline as the default pipeline for all new projects.
+5. Click **+ Add Environment** and add required environments for the pipeline according to the preferred environment sequence.
+6. Click **Create**.
+
+## Edit a continuous deployment pipeline
+
+### Prerequisites
+
+- To edit a continuous deployment pipeline in an organization, you must have the `ENVIRONMENT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles.
+
+To edit a pipeline, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+4. Click the edit icon corresponding to the pipeline you want to edit.
+5. Update the pipeline name, mark the pipeline as default, and change the sequence of environments.
+6. Click **Update**.
+
+
+## Delete a continuous deployment pipeline
+
+To delete a pipeline, follow the steps given below:
+
+!!! warning
+ Continuous deployment pipeline deletion is a permanent, non-reversible operation.
+
+!!! info "Note"
+ The **default** continuous deployment pipeline of the organization cannot be deleted.
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+4. Click the delete icon corresponding to the pipeline you want to delete. This displays a confirmation dialog with details on the impact of deletion.
+
+ !!! info "Note"
+ If the pipeline is utilized by one or more projects, deletion will not be permitted. To proceed with deleting such a pipeline, you must first remove it from every project that is currently using it.
+
+5. Review the details, then type the pipeline name to confirm the deletion.
+6. Click **Delete**.
+
+
+## Add a continuous deployment pipeline to a project
+
+### Prerequisites
+
+- To add a continuous deployment pipeline to a project, you must have the `ENVIRONMENT-MANAGEMENT` or `PROJECT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles and `PROJECT-MANAGEMENT` permission is granted to Admin, Choreo DevOps, and Project Admin roles.
+
+To add a pipeline to a project, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. Click the project you want to add the pipeline.
+4. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+5. Click **+ Add** and select the pipelines you want to add to the project.
+6. Click **Add**.
+
+
+## Remove a continuous deployment pipeline from a project
+
+### Prerequisites
+
+- To remove a continuous deployment pipeline from a project, you must have the `ENVIRONMENT-MANAGEMENT` or `PROJECT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles and `PROJECT-MANAGEMENT` permission is granted to Admin, Choreo DevOps, and Project Admin roles.
+
+To remove a pipeline from a project, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. Click the project you want to remove the pipeline.
+4. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+5. Click **Remove** corresponding to the pipeline you want to remove from the project. This displays a confirmation dialog with details on the impact of deletion.
+6. Review the details, then type the pipeline name to confirm the deletion.
+7. Click **Remove**.
+
+## Change default continuous deployment pipeline of a project
+
+### Prerequisites
+
+- To change the default continuous deployment pipeline of a project, you must have the `ENVIRONMENT-MANAGEMENT` or `PROJECT-MANAGEMENT` permission. By default, `ENVIRONMENT-MANAGEMENT` permission is granted to Admin, Choreo Platform Engineer and Choreo DevOps roles and `PROJECT-MANAGEMENT` permission is granted to Admin, Choreo DevOps, and Project Admin roles.
+
+To change the default pipeline of a project, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. Click the project you want to change the default pipeline.
+4. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+5. Click **Set as Default** corresponding to the pipeline you want to set as the default pipeline for the project. This displays a confirmation dialog that details the impact of setting the new pipeline as the project default.
+6. Click **Confirm**.
+
+ !!! info "Note"
+ The **default** continuous deployment pipeline is configured separately at both the organization and project levels. When a project is created, it inherits the organization's **default** pipeline. The project's **default** pipeline then defines the default promotion order for its components on the Deploy page.
+
+## Use multiple continuous deployment pipelines within a component
+
+### Prerequisites
+
+- To use multiple continuous deployment pipelines on a component's deploy page, the component's project must have more than one continuous deployment pipeline assigned.
+
+To use multiple continuous deployment pipelines in a component, follow the steps given below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the Organization, then the Project and finally the Component where you want to use multiple continuous deployment pipelines.
+3. In the left navigation menu, click **DevOps** and then click **CD Pipelines**.
+6. At the top of the page, click on the dropdown next to the Deployment Track/Version dropdown and choose the continuous deployment pipeline you want to use to deploy the component.
+
+ !!! info "Note"
+ The user will be able to view all continuous deployment pipelines assigned to the project and select one to deploy the component. Existing permissions will continue to control deployment and promotion access for specific environments.
diff --git a/en/pe-docs/docs/devops/cd-pipelines/submit-and-manage-environment-promotion-approval-requests.md b/en/pe-docs/docs/devops/cd-pipelines/submit-and-manage-environment-promotion-approval-requests.md
new file mode 100644
index 0000000000..8bde0f887a
--- /dev/null
+++ b/en/pe-docs/docs/devops/cd-pipelines/submit-and-manage-environment-promotion-approval-requests.md
@@ -0,0 +1,34 @@
+# Submit and Manage Environment Promotion Approval Requests
+
+If environment promotion workflows are configured for your organization as mentioned in the [guide](../../governance/workflows/configure-approvals-for-choreo-workflows.md), you must request and receive approval before deploying to a critical environment.
+
+When you submit a promotion approval request, Choreo notifies all authorized reviewers via email. Once an authorized reviewer approves or rejects the request, you will receive an email with the decision details. See [Review Workflow Approval Requests](../../governance/approvals/review-workflow-approval-requests.md) for more information on workflow approval request reviews.
+
+
+## Request approval for environment promotion
+
+### Prerequisites
+
+- Ensure you have a component created, built, and deployed to the first environment of your [CD pipeline](./manage-continuous-deployment-pipelines.md).
+- Ensure that an approval workflow is configured for environment promotion.
+- Ensure you are promoting to a critical environment, such as production.
+- Ensure you have the required permissions to either promote the component or create approval requests. Approval request creation requires **Create Approval Requests** permission under **WORKFLOW-MANAGEMENT**.
+
+To request approval to promote a component from one environment to another critical environment, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. From the left navigation, Click **DevOps** and then click **CD Pipelines**
+4. Go to the **Development** card and click **Request to Promote**.
+5. In the **Request Approval** pane, enter your request details and click **Submit**. This creates a request and notifies all authorized assignees via email about the request.
+
+ !!! note
+ When an environment promotion request for a specific component is pending review, Choreo restricts other developers from making the same request until the pending request is either approved or rejected.
+
+When an authorized assignee approves the request, you will receive a confirmation email and can proceed to promote the component to production.
+
+## Cancel an environment promotion approval request
+
+If you want to cancel an environment promotion approval request that is already submitted, you can do so before the request is approved or rejected.
+
+When you submit a workflow approval request, the **Request to Promote** button changes to **Cancel Request**. To cancel an approval request, click **Cancel Request**. Upon confirming the cancellation, all configured approvers are notified immediately, and the request will no longer be pending.
diff --git a/en/pe-docs/docs/devops/ci-pipelines/ci-pipeline-logs.md b/en/pe-docs/docs/devops/ci-pipelines/ci-pipeline-logs.md
new file mode 100644
index 0000000000..32171677c1
--- /dev/null
+++ b/en/pe-docs/docs/devops/ci-pipelines/ci-pipeline-logs.md
@@ -0,0 +1,26 @@
+# CI Pipeline Logs
+
+The CI pipeline logs in Choreo offer detailed insights into the build process of your components. These logs are divided into three main sections:
+
+1. **Initialization**
+
+This section captures logs related to setting up the environment for the build process. During this stage, the [component.yaml](https://wso2.com/choreo/docs/develop-components/manage-component-source-configurations/#overview-of-the-componentyaml-file) file is validated to ensure it meets the necessary requirements.
+
+2. **Build**
+
+This step involves the actual build process. Here, you can view logs specific to your component's build. Additionally, a Trivy vulnerability scan is performed to identify any potential vulnerabilities in the built image.
+
+3. **Finalization**
+
+This section includes logs related to the final steps of the build process. It involves cleaning up the build environment, marking the completion of the build.
+
+To view the build pipeline logs, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console, select the appropriate **Organization**, **Project**, and **Component** from the top navigation menu.
+
+!!! info "Note"
+ Build pipeline logs are accessible only at the component level.
+
+3. In the left navigation menu, click on **DevOps** and then click on **CI Pipelines** to view a list of builds for the selected component.
+4. Click on the **View Details** button corresponding to the build you wish to inspect. This will display the detailed logs for that specific build.
diff --git a/en/pe-docs/docs/devops/ci-pipelines/configure-ci-pipeline.md b/en/pe-docs/docs/devops/ci-pipelines/configure-ci-pipeline.md
new file mode 100644
index 0000000000..0c1e0bfd90
--- /dev/null
+++ b/en/pe-docs/docs/devops/ci-pipelines/configure-ci-pipeline.md
@@ -0,0 +1,64 @@
+# Configure CI Pipeline
+
+Choreo has built in CI pipeline so that the developers and platform engineers do not need to worry about creating docker images and saving in a container registry on their own. The developers could visit the build page from their component view and then build the component so that it would be ready for the deployment. As a platform engineer you may need to enforce configurations on this build pipeline. Each component would have its own build page, and you configure them separately.
+
+More Information can be found in [CI-CD concept](../../choreo-concepts/ci-cd.md) document.
+
+## Trigger a Build
+
+You can trigger a build from past commit or the latest commit.
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+2. In the left navigation menu, click **DevOps** and then click **CI Pipelines**.
+3. On the **CI Pipelines** page, click **Build Latest**.
+
+ !!! note
+ The build process may take some time. You can track progress in the **Build Details** pane. Once complete, the build status changes to **Success**.
+
+
+Alternatively, you can pick a specific commit and trigger a build too. Click on **Show Commits**. Select the commit you want to build and Click **Build**.
+
+Another option you have is to build from a tag. Click on the down arrow next to **Show Commits** button. Then from the dropdown menu, select **Show Tags**. Click on **Show Tags** button.Finally, select the tag you want to pick and Click **Build**.
+
+!!! note
+ Users can trigger builds using specific tags from the connected Git repository. However, this action bypasses the standard branch-based deployment process and should only be used for critical, time-sensitive scenarios, as it can disrupt deployment track integrity.
+
+To configure build pipeline, click **Build Configurations**. The configurations would be specific to the type of component. For certain components, you can configure build time environment variables too.
+
+
+### Repeatable builds
+
+Choreo can replicate builds from an identical code version (Git commit). This means that multiple builds initiated from the same Git commit will generate Docker images with the same behavior.
+
+## Build logs
+
+To view Build Logs for a component,
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+2. In the left navigation menu, click **DevOps** and then click **CI Pipelines**.
+3. You can view build logs for specific builds on the **CI Pipelines** page.
+4. To view details of a specific build, click **View Details** corresponding to the build.
+
+
+## Auto Build on Commit
+
+With Auto Build on Commit, you can configure the build pipeline to be triggered once a new commit is available in the repository's selected branch.
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** list and finally the relevant **Component**.
+2. In the left navigation menu, click **DevOps** and then click **CI Pipelines**.
+3. On the **CI Pipelines** page, toggle **Auto Build on Commit** radio button.
+
+ !!! info
+ If the developer created a component by providing an opensource repository without authorizing Github, you would see a button **Configure Auto Build** instead of **Auto Build on Commit** radio button. Click **Configure Auto Build**. Then it would redirect to github login page and ask to authorize **WSO2 Cloud App**. Once you authorize, you would be redirected back to same page. Now you would see a button **Add Repository** instead of **Configure Auto Build**. Click on **Add Repository**. It would redirect to github again asking to install and authorize WSO2 Cloud App for provided set of repositories. You can pick the repositories you would like to authorize and finally click **Install and Authorize**. After that, **Auto Build on Commit** radio button would appear.
+
+
+
+
+## Configure CI Pipeline Variables and Secrets.
+
+Choreo supports adding and updating configurations like environment variables and secrets related to your CI Pipeline. To apply such configurations to the CI pipeline of a component,
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+2. In the left navigation menu, click **DevOps** and then click **CI Pipelines**.
+3. On the **CI Pipelines** page, click **Build Variables and Secrets**.
+4. In the slide-in window appears in right, you can add or edit environment variables.
diff --git a/en/pe-docs/docs/devops/ci-pipelines/integrate-unit-tests-into-the-build-pipeline.md b/en/pe-docs/docs/devops/ci-pipelines/integrate-unit-tests-into-the-build-pipeline.md
new file mode 100644
index 0000000000..4fb0c717c6
--- /dev/null
+++ b/en/pe-docs/docs/devops/ci-pipelines/integrate-unit-tests-into-the-build-pipeline.md
@@ -0,0 +1,35 @@
+# Integrate Unit Tests into the Choreo CI Pipeline
+
+Choreo allows you to integrate unit tests into the CI pipeline, enabling code validation before deployment. This ensures early testing of code changes, reducing the risk of defects in production.
+
+!!! note
+ Currently, Choreo supports unit tests only for the `WSO2 MI` buildpack.
+
+## How it works
+
+### Step 1: Write tests
+
+You can create unit tests in your source code using standard testing libraries. For step-by-step instructions on creating unit tests for WSO2 Micro Integrator projects, see [Creating a Unit Test Suite](https://mi.docs.wso2.com/en/latest/develop/creating-unit-test-suite/).
+
+### Step 2: Enable unit tests
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. In the left navigation menu, click **DevOps** and then click **CI Pipelines**.
+4. Click on **Build Configurations** to edit the build configurations.
+5. Turn on the **Unit Test** toggle.
+6. Click **Save**.
+
+### Step 3: Trigger a new build
+
+- On the **CI Pipelines** page, click **Build Latest**.
+
+This starts a new build with unit tests enabled. You can monitor its progress in the **Build Details** pane.
+
+## View failed unit tests
+
+If a unit test fails during the build, you can view its detailed logs for troubleshooting. Click **View Details** corresponding to the failed build, then expand the failed unit test step to view the logs.
+
+## Explore a sample
+
+To see unit tests in action within the build pipeline, try out the [WSO2 MI helloworld](https://github.com/wso2/choreo-samples/tree/main/hello-world-mi) sample.
diff --git a/en/pe-docs/docs/devops/manage-configuration-groups.md b/en/pe-docs/docs/devops/manage-configuration-groups.md
new file mode 100644
index 0000000000..c4e9badf76
--- /dev/null
+++ b/en/pe-docs/docs/devops/manage-configuration-groups.md
@@ -0,0 +1,112 @@
+
+# Manage Configuration Groups
+
+Choreo allows you to create Configuration Groups to efficiently manage reusable configurations across components within your organization. A Configuration Group is a collection of key-value pairs, where values can be defined for multiple environments. This feature ensures consistency and simplifies the management of configurations across environments.
+
+Configuration groups can be defined at organization level and link to components at deployment time. Once linked, Choreo automatically resolves and mounts the configurations to the respective environments on deployment. You can either link a configuration group to inject the configurations as environment variables or file mounts.
+
+!!!important
+ - All configuration group values are encrypted and stored in environment-specific key vaults.
+ - Management of configuration groups is restricted to users with Choreo Admin, DevOps, and Platform Engineer roles.
+ - Developers can discover configuration groups available within the organization via the **Choreo Internal Marketplace**.
+ - This feature is currently not supported for WSO2 MI and Ballerina buildpacks, or for Web Application and Test Runner components.
+
+## Create a configuration group
+
+To create a new configuration group, follow the steps given below:
+
+1. In the [Choreo Console](https://console.choreo.dev/), go to the top navigation menu. Click **Organization** and select your organization.
+2. In the left navigation menu, click **DevOps** and then click **Configuration Groups**.
+3. On the **Configuration Groups** page, click **Create** and specify the following details to create a new configuration group:
+
+ - **Name**: A name for the configuration group (Unique within the organization).
+ - **Description**: A description for the configuration group (Optional).
+ - **Define Keys**: Define the keys for the configuration group.
+
+ - Configuration keys uniquely identify values in a configuration group. You can map these keys to environment variables or file mounts during deployment. Each key must be unique within the group.
+
+ - **Assign Values**: Define values by environment for the keys defined.
+
+ - By default, all the environments are grouped together allowing you to manage configuration smoothly. You can separate and manage configuration values for each environment as needed.
+
+ - **Create**: Click **Create** to create the configuration group.
+
+4. Now you can link this configuration group to any component within the organization.
+
+!!!note
+ - Configuration groups created will be listed in the **Choreo Internal Marketplace**, improving visibility and discoverability for developers.
+ - All configuration groups will also be listed in the component deployment drawers, allowing developers to easily link them during deployment.
+
+## Link and use configuration groups
+
+The configuration groups created at organization level can be linked to any component within the organization. A configuration group can be linked as **Environment Variables** or **File Mounts** at deployment time.
+
+Linking a configuration group will inject the values defined in the group during deployment. The values are mapped to environment variable names or file names based on the keys defined in the configuration group. If needed, you can customize the environment variable name or file name by updating the mapping at deployment.
+
+To link a configuration group to a component, follow the steps given below:
+
+1. Navigate to the component you want to link the configuration group using top navigation menu.
+2. On the left navigation menu, click **DevOps** and click **CD Pipelines**.
+3. Click **Configure & Deploy**, this will open the configuration and deployment wizard.
+3. In the wizard, link the configuration groups as **Environment Variables** or **File Mounts**, based on your requirements.
+
+ === "Environment Variables"
+
+ - Choose the configuration group you want to link to the component.
+ - Click **Link** to link the configuration group to the component.
+
+ === "File Mounts"
+
+ - Choose the configuration group you want to link to the component.
+ - Specify the **Mount Path** to mount the configuration files.
+
+ !!!note
+ All configurations within the selected configuration group will be mounted as individual files to the specified mount path/directory.
+
+ - Click **Link** to link the configuration group to the component.
+
+4. Complete the deployment wizard by providing the required details and click **Deploy** to deploy the component with the updated configurations.
+
+## View & edit a configuration group
+
+To view & edit a configuration group, follow the steps given below:
+
+1. In the [Choreo Console](https://console.choreo.dev/), go to the top navigation menu. Click **Organization** and select your organization.
+2. In the left navigation menu, click **DevOps** and then click **Configuration Groups**.
+3. In the **Configuration Groups** list, select the desired configuration group to view.
+
+ !!!note
+ - Only non-sensitive configuration values are displayed in the view mode.
+ - Updating the configuration group will not affect the current deployment; changes will be applied when the component is redeployed.
+
+### Edit the configuration group
+
+Configuration keys and values within a configuration group can be modified, and these changes will take effect when the components using the configuration group are redeployed.
+
+To edit the configuration group definition, click **Edit the Configuration Group** and make the necessary updates:
+
+- Add or remove configuration keys.
+- Update the configuration group's display name and description.
+
+To edit the configuration values, click the edit icon in the corresponding set of environments and modify the required details:
+
+- Update configuration values.
+- Add a new set of configuration values.
+- Add or remove environments from an existing set.
+
+!!! warning
+ - **Adding a new environment:** Non-sensitive configuration values will be copied to the new environment, but sensitive values will not be. As a result, sensitive values will be cleared across all environments in the set. **New values must be provided for sensitive configurations.**
+ - **Removing an environment:** All configuration values for the removed environment will be deleted.
+
+## Delete a configuration group
+
+To delete a configuration group, follow the steps given below:
+
+!!! warning
+ Deleting a configuration group is a permanent, non-reversible action. Ensure that the configuration group is not linked to any component before deleting it.
+
+1. In the [Choreo Console](https://console.choreo.dev/), go to the top navigation menu. Click **Organization** and select your organization.
+2. In the left navigation menu, click **DevOps** and then click **Configuration Groups**.
+3. In the **Configuration Groups** list, click the delete icon next to the configuration group you want to delete. This will display a confirmation dialog with details about the impact of the deletion.
+4. Review the details, then type the configuration group name to confirm the deletion.
+5. Click **Delete**.
diff --git a/en/pe-docs/docs/governance/approvals/review-workflow-approval-requests.md b/en/pe-docs/docs/governance/approvals/review-workflow-approval-requests.md
new file mode 100644
index 0000000000..352cced292
--- /dev/null
+++ b/en/pe-docs/docs/governance/approvals/review-workflow-approval-requests.md
@@ -0,0 +1,36 @@
+# Review Workflow Approval Requests
+
+In Choreo, Platform Engineers can [configure approvals for workflows](../workflows/configure-approvals-for-choreo-workflows.md) and assign specific users as approvers.
+
+!!! note
+ - You must have **Approve Component Promotion Requests** permission under **WORKFLOW-MANAGEMENT** permission group to approve component promotion requests.
+ - You must have **Approve API Subscriptions** permission under **WORKFLOW-MANAGEMENT** Permission group to approve subscription requests.
+
+If you are assigned as an authorized reviewer for a particular workflow approval request, you will receive an email notification when a request is submitted for approval. The email includes a summary of the request and a link to the **Approvals** page in the Choreo Console, where you can review the details and either approve or reject the request.
+
+!!! note
+ - Workflow approvals are managed at the project level. If a role with the necessary permissions is assigned in a project context, only members of the user group bound to that role within the specific project will receive notifications for requests made in that project. For example, if you are assigned the Project Admin role (which includes the necessary permissions) for project A, you will only be notified of workflow requests within project A.
+ - Users with organization-level permissions will receive notifications for all workflow requests across any project in the organization.
+
+Other approvers within your organization will also receive notifications for workflow requests and may review a request before you. If a request has already been reviewed, it will appear under the **Past** tab on the **Approvals** page.
+
+Approval requests are submitted on behalf of the team. Once approved, any authorized team member can execute the task. For certain tasks, execution may occur automatically upon approval.
+
+## View workflow approval requests
+
+To view workflow approval requests assigned to you, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **Governance** and then click **Approvals**.
+4. This opens the **Approvals** page where you can see all approval requests assigned to you. The **Pending** tab lists requests that are yet to be reviewed. The **Past** tab displays requests already reviewed by you or other approvers, as well as requests canceled by the requester.
+4. To view details of a specific request, click **Review** corresponding to it.
+
+## Approve or reject an approval request
+
+To approve or reject a request, follow these steps:
+
+1. Follow the instructions in the [View workflow approval requests](#view-workflow-approval-requests) section above to see details of the workflow you want to review.
+ Alternatively, click the Choreo Console link in the approval request email notification you received. This takes you to the request details in the Choreo Console.
+2. Review the request and click **Approve** or **Reject** based on your decision.
+
diff --git a/en/pe-docs/docs/governance/egress-control/control-egress-traffic-for-your-organization.md b/en/pe-docs/docs/governance/egress-control/control-egress-traffic-for-your-organization.md
new file mode 100644
index 0000000000..91086fed10
--- /dev/null
+++ b/en/pe-docs/docs/governance/egress-control/control-egress-traffic-for-your-organization.md
@@ -0,0 +1,41 @@
+# Control Egress Traffic for Your Organization
+
+In Choreo, you can manage egress traffic originating from your applications by setting up an allow list or deny list. By default, egress traffic is allowed to any destination unless specifically restricted.
+
+## Configure an egress policy at the organization level
+
+To configure an egress policy at the organization level, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **Governance**, then click **Egress Control**.
+4. Click **+ Create** to add a new egress policy
+5. Select the type of egress control to apply and add the required rules:
+
+ - **Allow All**: Allows all egress traffic by default. You can selectively block traffic to specific IP ranges.
+ - **Deny All**: Blocks all egress traffic by default. You can selectively allow traffic to specific IP ranges or domains.
+
+ !!! note
+
+ - Once you select an egress control type and create a rule, you cannot change the type. To change the type, you must delete existing rules.
+ - Egress rules you add can disrupt your application if they block traffic to required destinations. Ensure you add rules appropriately to prevent such disruptions.
+ - If you use the **Deny All** type, be sure to add Choreo-managed database hosts to the allowed list.
+ - Egress policies apply across all environments in an organization.
+ - Egress policies do not apply to API proxies.
+
+
+## Override the organization-level egress policy at the project level
+
+An egress policy set at the project level can override the organization-level policy, depending on the egress control type you select.
+
+To override the organization-level egress policy at the project level, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Project** list and select your project.
+3. In the left navigation menu, click **Governance**, then click **Egress Control**.
+4. You will see that the organization-level egress policy is enforced by default.
+5. Add required project-level rules to further restrict egress traffic.
+
+ - If the **Allow All** egress control type is selected at the organization level, you can add project-level deny rules to further restrict traffic.
+ - If the **Deny All** egress control type is selected at the organization level, you can remove allow rules inherited from the organization level to further restrict traffic.
+
diff --git a/en/pe-docs/docs/governance/workflows/configure-approvals-for-choreo-workflows.md b/en/pe-docs/docs/governance/workflows/configure-approvals-for-choreo-workflows.md
new file mode 100644
index 0000000000..b316bb569f
--- /dev/null
+++ b/en/pe-docs/docs/governance/workflows/configure-approvals-for-choreo-workflows.md
@@ -0,0 +1,76 @@
+# Configure Approvals for Choreo Workflows
+
+Choreo allows you to configure approval processes for specific workflows within the platform. An approval process for a workflow ensures that critical or sensitive changes are properly managed and controlled.
+
+Choreo currently allows you to configure approvals for environment promotion, API subscription and URL customization workflows.
+
+Configuring approvals for environment promotion allows authorized users to control components being promoted to a critical/production environment.
+
+Configuring approvals for the API subscription workflow allows you to create subscription plans that require approval before being activated. This feature allows you to control access to APIs by requiring administrative review and authorization of subscriptions before they become active.
+
+Configuring approvals for URL customization workflows allows you to control custom URL mappings by requiring review and approval before the customization is applied.
+
+## Permissions to review and respond to approval requests
+
+Click the respective tab for details on permissions depending on the workflow for which you want to configure approvals:
+
+=== "Environment promotion"
+
+ To review and respond to environment promotion approval requests, a user must have the following permissions. Platform engineers must ensure that users designated to review and respond to approval requests have these permissions:
+
+ - **WORKFLOW-MANAGEMENT**:
+ - Approve component promotion requests: Grants access to review and approve the promotion of components to critical environments.
+ - **PROJECT-MANAGEMENT**: Grants access to view and approve workflow requests. This is the same permission used to update or delete projects.
+
+=== "API subscription"
+
+ To review and respond to API subscription approval requests, a user must have the following permissions. Platform engineers must ensure that users designated to review and respond to approval requests have these permissions:
+
+ - **WORKFLOW-MANAGEMENT**:
+ - Approve API subscriptions: Grants access to review and approve API subscription workflow requests.
+ - **PROJECT-MANAGEMENT**:
+ Grants access to view and approve workflow requests. This is the same permission used to update or delete projects.
+
+=== "URL customization"
+
+ To review and respond to URL customization approval requests, a user must have the following permissions. Administrators must ensure that users designated to review and respond to approval requests have these permissions:
+
+ - **WORKFLOW-MANAGEMENT**:
+ - Approve custom URL mapping requests: Grants access to review and approve custom URL mapping requests.
+ - **URL-MANAGEMENT**:
+ - Manage Custom Domains: Grants access to manage custom domains for the organization.
+
+## Set up an approval process for a workflow
+
+To set up an approval process for a workflow, follow these steps:
+
+!!! note
+ - Platform engineers can designate specific roles and assignees to review and respond to requests associated with each workflow.
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **Governance** and then click **Workflows**.
+4. Click the edit icon corresponding to the workflow for which you want to configure an approval.
+5. In the **Configure Workflow** dialog that opens, select roles and assignees to review and respond to workflow approval requests.
+
+ - In the **Roles** field, select one or more roles depending on your preference. Any user assigned to these roles can review and respond to requests.
+ - In the **Assignees** field, select specific users who can review and approve workflow requests. Assignees can be any Choreo user, even if they are not assigned to a selected role.
+
+ !!! info "Important"
+ Currently, there is no validation to ensure that the specified roles and assignees have the necessary permissions to review and respond to requests. If the [required permissions](#permissions-to-review-and-respond-to-approval-requests) are not correctly configured, some users may receive email notifications but will be unable to review the requests.
+
+6. Click **Save**. This configures and enables the approval process for the workflow.
+
+Once you enable the approval process for a workflow, see the following details on how to submit a request for approval and the approval process. Click the respective tab depending on the workflow for which you enabled the approval process:
+
+=== "Environment promotion"
+
+ Once you configure an approval process for environment promotion, developers must submit a request for approval to use the workflow. An authorized assignee must then [review and approve the request](../approvals/review-workflow-approval-requests.md) for a developer to proceed with the task related to the workflow.
+
+=== "API subscription"
+
+ Once you configure an approval process for API subscription, platform engineers can select the **Approval required** checkbox to create or update subscription plans to require approval. API consumers using these plans must request approval to proceed. An authorized approver must then [review and approve the request](../approvals/review-workflow-approval-requests.md) before the subscription is granted.
+
+=== "URL customization"
+
+ Once you configure an approval process for URL customization, developers must submit a request for approval to configure a custom URL for a component. Instead of being automatically deployed, the URL mapping will go into a pending state. An authorized approver must then [review and approve the request](../approvals/review-workflow-approval-requests.md) before the custom URL is activated for the respective component.
diff --git a/en/pe-docs/docs/index.md b/en/pe-docs/docs/index.md
new file mode 100755
index 0000000000..8f701267b6
--- /dev/null
+++ b/en/pe-docs/docs/index.md
@@ -0,0 +1,3 @@
+---
+template: templates/pe-home-page.html
+---
diff --git a/en/pe-docs/docs/infrastructure/configure-vpns-on-the-choreo-cloud-data-plane.md b/en/pe-docs/docs/infrastructure/configure-vpns-on-the-choreo-cloud-data-plane.md
new file mode 100644
index 0000000000..a1c284689b
--- /dev/null
+++ b/en/pe-docs/docs/infrastructure/configure-vpns-on-the-choreo-cloud-data-plane.md
@@ -0,0 +1,193 @@
+# Configure VPNs on the Choreo Cloud Data Plane
+
+Secure access to private networks from the Choreo cloud data plane is an essential use case for cloud data plane users.
+
+Choreo allows this secure connection using [Tailscale](https://tailscale.com/). For this, Choreo provides a prebuilt Tailscale image component that can act as a forward proxy, which you can deploy in your Choreo project as a service. This service allows you to forward traffic to your external networks via Tailscale’s peer-to-peer [WireGuard](https://tailscale.com/kb/1035/wireguard) network.
+
+The following diagram illustrates the high-level deployment architecture of the Tailscale pre-installed forward proxy:
+
+
+
+Let's take a look at the specifics of each part to understand the deployment architecture.
+
+- **Choreo project**
+
+ In Choreo, a project groups various components. For more information on what a project in Choreo is, see the documentation on [Project](../choreo-concepts/project.md).
+
+- **Tailscale proxy**
+
+ This acts as the Tailscale pre-installed forward proxy, facilitating secure peer-to-peer WireGuard connections from the Choreo cloud data plane to private networks. It includes a [Tailscale Daemon](https://tailscale.com/kb/1278/tailscaled), [SOCKS5 proxy](https://tailscale.com/kb/1112/userspace-networking#socks5-vs-http), and a configurable TCP forwarder.
+
+ - **Tailscale daemon**
+
+ This is the core component of Tailscale. It is a software service that provides secure network connectivity and private networking solutions. For more details see the [Tailscale documentation](https://tailscale.com/kb/1278/tailscaled).
+
+ - **SOCKS5 proxy**
+
+ This uses Tailscale’s [userspace networking](https://tailscale.com/kb/1112/userspace-networking) mode, rather than the kernel mode. Therefore, the inbuilt SOCKS5 proxy handles the forwarded traffic and directs it through the Tailscale network.
+
+ - **TCP forwarder**
+
+ Forwards inbound TCP (transmission control protocol) traffic from the Tailscale proxy container’s network interface to the SOCKS5 proxy, ensuring it reaches its destination via the secured WireGuard tunnel.
+
+- **User applications and the Choreo API gateway**
+
+ User applications within the same namespace (project) can use the Kubernetes service created to front the Tailscale proxy, for connecting to the corresponding private endpoints. You can either expose this service within the organization via the internal API gateway or expose it to the public via the external API gateway.
+
+
+
+
+
+Data plane component
+Endpoint
+Direction
+Protocol
+
+
+Choreo PDP agent
+Choreo control plane (CP) (mizzen server)
+Outbound
+WSS
+
+
+Kubernetes API server
+Outbound (cluster internal)
+HTTPS, WS
+
+
+APIM/local adaptor
+Global adaptor
+Outbound
+HTTPS
+
+
+Azure Service Bus (CP)
+Outbound
+AMQP or WS
+
+
+APIM/Enforcer
+Event hub (CP)
+Outbound
+AMQP
+
+
+Choreo secret resolver
+Cloud secret store
+Outbound (VPC internal)
+HTTPS
+
+
+Container registry
+Container registry (public)
+Inbound
+HTTPS
+
+
+Container registry
+Outbound (VPC internal)
+HTTPS
+
+
+Certificate manager
+Azure DNS service
+Outbound
+HTTPS
+
+
+LetsEncrypt
+Outbound
+HTTPS
+
+
+Flux source controller
+GitHub
+Outbound
+HTTPS
+
+
+
+Flux Helm controller
+Choreo container registry
+Outbound
+HTTPS
+
+
+Now that you understand the deployment architecture, let’s explore how you can use Tailscale to secure connections to your private networks.
+
+## Configure and use Tailscale to access private network endpoints
+
+This section walks you through the steps to create, configure, deploy, and use the Tailscale proxy component.
+
+
+
+Let's get started.
+
+### Prerequisites
+
+- Understand the basics of [how Tailscale works](https://tailscale.com/blog/how-tailscale-works).
+- Have a Tailscale account (Tailnet). There are multiple plans available for you to set up your Tailscale network. For details, see [Tailscale plans](https://tailscale.com/pricing).
+- Install Tailscale and connect your private data center or server to it, so that your private services are accessible via your Tailscale network. To quickly get started with Tailscale, see the [Tailscale quickstart](https://tailscale.com/kb/1017/install).
+
+### Step 1: Create the Tailscale proxy component
+
+!!! Note -
+ Component creation is not available for the **Platform Engineer** role. Switch to the **Developer** perspective to create a component.
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, and then the **Project**.
+3. On the project home page, click **+ Create**, and select the **Service** card to create a service component.
+4. Click the **Container Registry** from the **Connect a Docker Image** section
+5. In the **Container Registry** list, select **Choreo Samples Registry**.
+6. Click the **Tailscale Proxy** card.
+7. Enter a display name, component name, and a description for the service. For this guide, let's enter the following values:
+
+ |Field | Value |
+ |----------------------|--------------------------|
+ |Component Display Name| Tailscale proxy |
+ |Component Name | tailscale-proxy |
+ |Description | Tailscale proxy component|
+
+8. Click **Create**.
+
+Now you have successfully created the Tailscale proxy. You can proceed to configure and deploy it.
+
+### Step 2: Configure and deploy the Tailscale proxy
+
+Here, you will add the required volume mounts, set the Tailscale authentication key, configure the TCP forwarder, configure endpoints, and deploy the Tailscale proxy. Follow the steps given below:
+
+#### Step 2.1: Add required volume mounts
+
+Tailscale requires the following volume mounts for its operations:
+
+ - `/var/run/tailscale`
+ - `/.local`
+
+To create the volume mounts, follow the step-by-step instructions in [Configure Storage](../k8s-operations/storage/configure-storage.md).
+
+#### Step 2.2: Configure and deploy the component
+
+To configure and deploy the component, follow the steps given below:
+
+1. In the left navigation menu, click **CI Pipelines**.
+2. On the **Setup** card, click **Configure & Deploy**.
+3. In the **Environment Configurations** pane that opens, click **+ Add** and add the `TS_AUTH_KEY` environment variable as a secret. To add the environment variable, you must obtain an authentication key from your Tailscale network. For details on how to obtain an authentication key from your Tailscale network, see [Auth keys](https://tailscale.com/kb/1085/auth-keys) in the Tailscale documentation.
+
+ !!! info "Note"
+ The authentication keys obtained from your Tailscale network have an expiration date and require periodic rotation. To avoid manual rotation, you can generate non-expiring authentication keys using OAuth clients. For details, see [Generating long-lived auth keys](https://tailscale.com/kb/1215/oauth-clients#generating-long-lived-auth-keys) in the Tailscale documentation.
+
+ Follow these steps if you want to add an OAuth client secret to the Tailscale proxy component instead of the `TS_AUTH_KEY` environment variable as a secret:
+
+ 1. Define a tag named `choreo-vpn` in your Tailscale ACLs. For details, see [Define a tag](https://tailscale.com/kb/1068/tags#define-a-tag) in the Tailscale documentation.
+ 2. Create an [OAuth client](https://tailscale.com/kb/1215/oauth-clients) with the following scope, ensuring it is assigned to the `choreo-vpn` tag:
+ - Keys → Auth Keys → write
+ 3. Generate the OAuth client and copy the client secret.
+ 4. Set the client secret as an environment variable named `OAUTH_CLIENT_SECRET`.
+
+4. Click **Next**.
+5. In the **File Mount** pane that opens, click **+ Add**.
+6. To mount a configuration file to the Tailscale proxy component and specify the port mapping for the TCP forward proxy running there, do the following:
+ 1. Specify `/config.yaml` as the **Mount Path**.
+ 2. Specify the following in the sample configuration file:
+ ```
+ portMappings:
+ 8080: "100.108.78.93:8090"
+ 8081: "100.108.78.93:1433"
+ ```
+ !!! note
+ In this sample configuration, the TCP traffic arriving at port 8080 on your Tailscale proxy will be forwarded to port 8090 on the node with IP address 100.108.78.93 in your Tailscale network. Similarly, port 8081 will map to the corresponding address. You can find the IP addresses of your nodes on the [Tailscale machines](https://login.tailscale.com/admin/machines) page in your Tailscale network's admin console or via the Tailscale clients running on your machine.
+7. Click **Next**.
+8. In the **Endpoints** pane that opens, click **+ Add** and edit the `endpoints.yaml` configuration to expose your Tailscale proxy as a service. The following is a sample `endpoints.yaml` configuration you can use:
+
+!!! note
+ The sample `endpoints.yaml` file given below defines two project-level endpoints. These endpoints can be used by other components within the same project to access the services. If you want to directly expose your private endpoint via the Choreo gateway either with the **Public** or **Organization** visibility, you can set the `networkVisibility` property of the endpoint to `Public` or `Organization`.
+ ``` yaml
+ version: 0.1
+ endpoints:
+ - name: Private HTTP service
+ port: 8080
+ type: REST
+ networkVisibility: Project
+ context: /
+ - name: Private DB service
+ port: 8081
+ type: TCP
+ networkVisibility: Project
+ context: /
+ ```
+9. Click **Save**.
+10. Click **Next** and then click **Deploy**.
+
+!!! note
+ Deploying the component may take a while. You can track the progress by observing the logs. Once the deployment is complete, the build status changes to **Active** on the **Development** environment card.
+When the component is deployed, you can observe a new node connected to your Tailscale network. To view this, go to the [Tailscale machines](https://login.tailscale.com/admin/machines) page of your Tailscale coordination server.
+
+### Step 3: Access private network endpoints with the Tailscale proxy
+Now you have successfully deployed the Tailscale proxy in your project and it is connected to your Tailnet. You can proceed to use the Tailscale proxy to provision access for other components to securely access private network endpoints.
+You can [configure endpoints](https://wso2.com/choreo/docs/develop-components/configure-endpoints/#learn-the-endpointsyaml-file) of the Tailscale proxy to use it for various aspects within Choreo.
+
+## Post-deployment actions
+
+### Handle node key expiry
+
+Tailscale nodes have a default [node key](https://tailscale.com/kb/1010/node-keys) expiry time of 180 days. Nodes require re-authentication after key expiry to avoid connection losses and application downtime. There is an option to disable node key expiry if necessary. For more details, see [Node key expiry documentation](https://tailscale.com/kb/1028/key-expiry).
+
+### Handle auth key expiry
+
+[Auth keys](https://tailscale.com/kb/1085/auth-keys) are used to register new nodes into your Tailscale network. The default [expiry time for auth keys](https://tailscale.com/kb/1085/auth-keys#key-expiry) is 90 days, but nodes remain connected even after auth key expiry. This becomes an issue only if the Tailscale Proxy component is redeployed or restarted.
+
+### Update port mapping configurations
+
+If you want to add a new private endpoint to your network and access it via the same Tailscale proxy within Choreo, you must add a new port mapping entry in the port mapping configuration of your Tailscale proxy deployment.
+
+## Best practices
+
+### Configure health checks
+
+Since the Tailscale proxy acts as a forward proxy, it is important to configure health checks. You can use one of the open ports of the TCP forwarder as a health endpoint. For details on how to set up health probes in Choreo, see [Set up health checks](../k8s-operations/set-up-health-checks.md).
+
+### Use Tailscale ACLs
+
+You can use [Tailscale ACLs](https://tailscale.com/kb/1018/acls) to precisely manage permission for users and devices on your Tailnet.
+
+### Disable scale-to-zero for the Tailscale proxy
+
+It is recommended to disable [Scale-to-Zero](../k8s-operations/scaling/autoscale-components-with-scale-to-zero.md) for the Tailscale proxy because it acts as a forward proxy and should always be up and running to make consistent connections with the Tailscale VPN mesh.
+If you enable Scale-to-Zero, you may experience service downtime.
+
+### Run multiple replicas with HPA (horizontal pod autoscaler)
+
+To achieve high availability and resiliency for the Tailscale proxy, you must run multiple replicas with HPA. To configure multiple replicas for the Tailscale proxy component, go to the **Scaling** page under **DevOps**. For more details, see [Autoscale component replicas](../k8s-operations/scaling/autoscale-component-replicas.md)
+
+## Security best practices
+
+Before deploying the Tailscale proxy in production environments, it is recommended to follow the Tailscale [production best practices](https://tailscale.com/kb/1300/production-best-practices) and [security best practices](https://tailscale.com/kb/1196/security-hardening).
+!!! Note
+ Choreo blocks incoming connections from other nodes in your Tailnet to the Tailscale proxy to prevent access to your project’s namespace in the Choreo cloud data plane.
+
+## Troubleshoot issues
+
+For assistance in resolving common Tailscale proxy issues, see [Troubleshoot Tailscale proxy issues](../references/troubleshoot-choreo.md#troubleshoot-tailscale-proxy-issues).
\ No newline at end of file
diff --git a/en/pe-docs/docs/infrastructure/credentials/set-up-git-provider-authentication-for-choreo-deployments.md b/en/pe-docs/docs/infrastructure/credentials/set-up-git-provider-authentication-for-choreo-deployments.md
new file mode 100644
index 0000000000..06e65256b0
--- /dev/null
+++ b/en/pe-docs/docs/infrastructure/credentials/set-up-git-provider-authentication-for-choreo-deployments.md
@@ -0,0 +1,51 @@
+# Set Up Git Provider Authentication for Choreo Deployments
+
+Choreo enables you to develop components by connecting your GitHub, Bitbucket, or GitLab repository. You have the flexibility to either connect an existing repository or start with an empty repository and commit the source code later. By integrating your repositories with Choreo, you can automate tasks and optimize workflows across multiple systems, all within the Choreo platform. Choreo currently supports GitHub, Bitbucket, and GitLab as Git providers.
+
+!!! tip
+ Choreo supports both Bitbucket Server and Bitbucket Cloud. The currently supported Bitbucket Server version is 8.9.2.
+
+In Choreo, you can connect a Git repository that contains some source code or a Docker project. Once you connect your Git repository to Choreo, you can build, deploy, and manage your application easily with choreo-console.
+
+## Connect a Git repository to Choreo
+
+You can connect Bitbucket, Gitlab repositories to choreo organization using a Personal Access Token(PAT). For github, the developers can install [WSO2 Cloud App](https://github.com/marketplace/choreo-apps) during component creation and get necessary permissions via Github itself.
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **Infrastructure** and then click **Credentials**.
+5. Under **Git Credentials** tab, click **+Import Credentials** to configure the Git repository connection.
+6. Enter a **Credential Name**, select the Git provider, and enter the **Personal Access Token** you obtained from the Git provider.
+7. Click **Save**.
+
+## Authorize GitHub with Choreo
+
+Authorizing Choreo as a GitHub application grants Choreo the following permissions to perform the respective actions on your behalf within the repository:
+
+|Permission | Read| Write| Description |
+|-------------|-----|------|-----------------------------------------------------------------------|
+|Issues | Y | N | Read component ID label to filter the pull requests |
+|Metadata | Y | N | List repositories |
+|Contents | Y | Y | List branches and create a branch to commit sample code |
+|Pull Request | Y | Y | Create a pull request if you start with a Choreo sample |
+|Webhooks | Y | Y | Trigger automatic deployment and configuration generation |
+
+
+## Authorize Bitbucket with Choreo
+
+Authorizing using a personal access token (PAT) from Bitbucket grants Choreo the following permissions to perform the respective actions on your behalf within the repository.
+
+|Permission | Read| Write| Description |
+|--------------|-----|------|--------------------------------------------------------------------|
+|Account | Y | N | Get user information and workspace details |
+|Repositories | Y | Y | List branches and create a branch to commit sample code |
+|Pull Requests | Y | Y | Create a pull request if you start with a Choreo sample |
+|Webhooks | Y | Y | Trigger automatic deployment and configuration generation |
+
+## Authorize self-managed GitLab with Choreo
+
+Authorizing using a personal access token (PAT) obtained from your GitLab self-managed server grants Choreo the following permissions to perform the respective actions on your behalf within the repository.
+
+|Permission | Description |
+|--------------|-------------------------------------------------------------------------------------|
+|API | Grants full read/write access to the API, covering all groups and projects, as well as read/write access to the repository.|
diff --git a/en/pe-docs/docs/infrastructure/credentials/use-your-own-container-registry.md b/en/pe-docs/docs/infrastructure/credentials/use-your-own-container-registry.md
new file mode 100644
index 0000000000..8a6817ae38
--- /dev/null
+++ b/en/pe-docs/docs/infrastructure/credentials/use-your-own-container-registry.md
@@ -0,0 +1,160 @@
+# Use Your Own Container Registry
+
+Choreo allows you to deploy and manage prebuilt container images from external container registries as Choreo components. This enables you to deploy and effectively manage your container images within the Choreo environment.
+
+!!! info
+ This feature is currently only available on [private data planes (PDPs)](../../choreo-concepts/data-planes.md#private-data-planes) for the following component types:
+
+ - Service
+ - Web Application
+ - Scheduled Task
+ - Manual Task
+
+## Prerequisites
+
+Before you try out this guide, ensure you have the following:
+
+- **A container registry**: Ensure you have a container registry containing the images you want to deploy. Choreo is compatible with various container registries, including but not limited to GCR (Google Container Registry), ACR (Azure Container Registry), GitHub Container Registry, and Docker Hub.
+
+- **(Optional) An external build/CI pipeline**: This is to initiate automatic deployments during the build process outside of Choreo.
+
+When using a container registry to deploy a component, Choreo cannot create an image from the source code (Git) or initiate a new deployment when a new image is ready. However, you can use your existing build process to trigger a deployment on Choreo by sending an HTTP POST request to a webhook with the new image details.
+
+This feature is currently only available on private data planes (PDPs).
+
+## Register a container registry
+
+To get started, establish a connection between your container registry and Choreo.
+
+!!! info
+ When you use your Choreo credentials, Choreo does not _pull_ your images into its control plane. Instead, it functions as an orchestrator, facilitating your data plane's ability to retrieve images from an external container registry. Choreo passes on these credentials to the data plane for authentication and access.
+
+To register your container registry, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console header, go to the **Organization** list and select your organization.
+3. In the left navigation menu, click **Infrastructure** and then click **Credentials**.
+4. Click the **Container Registries** tab.
+5. Click **+Add Registry** to configure the Git repository connection.
+6. Specify a **Registry Display Name**.
+7. Select the **Authentication Type**. Fill in the required information depending on your authentication type. For details on each authentication type, see [Authentication types](#authentication-types).
+8. Click **Save**.
+
+### Authentication types
+
+Choreo provides the following authentication options:
+
+#### Public (anonymous) access
+
+You can use this option to establish a connection with a container registry that permits unrestricted public or anonymous access (for example, Public Docker Hub). In this case, only the registry host information is necessary.
+
+For example, the following are the Docker Hub registry hosts for reference:
+
+| Vendor | Registry host |
+| --------------------------------- | ------------------------- |
+| Docker Hub (public repositories) | `registry.hub.docker.com` |
+| Docker Hub (private repositories) | `registry.docker.com` |
+
+\* If necessary, you can use other mirrors instead of the above.
+
+#### Basic authentication
+
+To use basic authentication to authenticate to the container registry, you must provide the username and password.
+
+#### Docker config
+
+You can provide a Docker config in JSON format to authenticate to the container registry. This option only allows you to register one container registry. That is, it **only allows a single registry under `auths`**.
+
+You must provide the credentials directly within the configuration. Choreo cannot utilize references to executable authentication plugins.
+
+Sample Docker config format:
+
+```json
+{
+ "auths": {
+ "index.docker.io/v1/": {
+ "auth": "c3R...zE2"
+ }
+ }
+}
+```
+
+#### Vendor-specific authentication
+
+This option is specifically for private data planes, where your cloud provider manages authentication at the Kubernetes level. Choreo requires knowledge of the registry host because the data plane already possesses implicit (preconfigured) access to the registry.
+
+Follow the guidelines below based on your container registry:
+
+=== "ACR"
+**Azure Container Registry**
+
+ Recommended authentication options:
+
+ * [**Service principal-based basic authentication**](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal)
+
+ * **Vendor-specific authentication on Azure private data planes**
+
+ Contact Choreo support to enable infrastructure-level private access to your registry from your Azure private data plane on AKS. If you are on a self-managed PDP on Azure, follow [this guide](https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration?toc=%2Fazure%2Fcontainer-registry%2Ftoc.json&bc=%2Fazure%2Fcontainer-registry%2Fbreadcrumb%2Ftoc.json&tabs=azure-cli).
+
+=== "GAR"
+**Google Artifact Registry**
+
+ Recommended authentication options:
+
+ * [**Service account-based basic authentication**](https://cloud.google.com/artifact-registry/docs/docker/pushing-and-pulling#key)
+
+ Use the service account key in JSON format ([`_json_key`](https://cloud.google.com/artifact-registry/docs/docker/authentication#:~:text=of%20the%20following%3A-,_json_key,-if%20you%20are)) as the username and specify the minified JSON contents of the service account key as the password.
+
+ You can use `jq` as follows to minify the service account JSON key file:
+
+ `jq -c . For step-by-step instructions on constructing a certificate chain with a root certificate, click here
+ To construct a certificate chain with a root certificate, you must organize and combine the certificates in the correct sequence. A typical certificate chain consists of the following:
+ - **Root certificate**: The trusted self-signed certificate issued by the certificate authority (CA).
+ - **Intermediate certificates** (if any): Certificates issued by the root CA to subordinate CAs.
+ - **Leaf certificate**: Your end-entity certificate issued by the CA. This is an optional certificate that may be included within the chain or provided separately.
+ Follow these steps to construct the certificate chain:
+ 1. Obtain and organize your certificates in the correct order:
+ - **Leaf certificate**: The public certificate issued by the CA. This is optional and may be included within the chain or provided separately.
+ - **Intermediate certificates**: Obtain these from the CA, if applicable.
+ - **Root certificate**: Obtain this from the CA. If it is self-signed, it serves as the trust anchor.
+ 2. Combine the certificates into a single file in the following order:
+ - Leaf certificate: This is your public certificate issued by the CA.
+ - Intermediate certificates if applicable: Include these in the correct hierarchical order.
+ - Root certificate: Include this at the end of the file.
+ Use a text editor or a command-line tool to concatenate the certificates into one file, ensuring each certificate begins and ends with the proper markers. Also make sure the `BEGIN CERTIFICATE` and `END CERTIFICATE` markers appear on a new line:
+ ```
+ -----BEGIN CERTIFICATE-----
+
+
+
+ This chart visualizes the percentage of cost savings achieved (by manual or automatic application of recommendations) compared to missed savings (potential savings missed due to recommendations not being applied) up to the current date. You should aim to maximize the saved cost and minimize missed savings.
+
+* **Total Monthly Savings**
+
+
+
+
+ This card shows the cost saved in the current month through manual or automatic application of recommendations. It includes a breakdown for Production and Non-Production environments, with a dropdown showing savings for each respective environment.
+
+* **Monthly Missed Savings**
+
+
+
+ This card displays the potential cost savings that were missed due to the failure to apply recommendations, whether manually or automatically. It provides a breakdown of these missed savings for both production and non-production environments, listing values for each individual environment. It is recommended to keep these missed savings as minimal as possible.
+
+* **Annual Savings**
+
+
+
+ This card shows accumulated savings throughout the year. It combines the savings completed through the end of the previous month with savings achieved up to the present day of the current month. This demonstrates that a fully cost-optimized organization with no savings for the current month has achieved this state by saving costs in previous months.
+
+* **Monthly CPU and Memory Cost**
+
+
+
+ This card shows the cost incurred for CPU and Memory allocation across all components in your organization. It includes a percentage change compared to the previous month to indicate cost trends.
+
+* **Estimated Monthly Cost**
+
+
+
+ This card shows the forecasted cost at the end of the month, with an environmental breakdown, regardless of which day of the month you view it.
+
+* **Monthly CPU and Memory Efficiency**
+
+
+
+ This card shows the percentage utilization of CPU and Memory compared to allocation. This metric indicates your resource optimization level, which directly reflects cost optimization. The breakdown of CPU and Memory efficiencies provides individual understanding of each resource's optimization. The percentage change shown compares current efficiency to last month's efficiency with an arrow indicating increase or decrease.
+
+* **Cost Analysis Plot**
+
+
+
+ The plot consists of three lines:
+
+ * **Allocation Cost** - The maximum of Request Cost and Utilization Cost at a given point in time. This is what you're billed for CPU and memory resource costs.
+ * **Utilization Cost** - The ideal cost that should be billed if no extra resources were allocated. This is typically not achievable in practice as some buffer is needed for uninterrupted service.
+ * **Optimized Cost** - The cost suggested by the optimization algorithm that provides sufficient buffer for efficient performance while optimizing costs.
+
+ You can filter the view to show All resources, CPU only, or Memory only for time-based cost analysis.
+
+* **Cost Savings (Deployments Summary)**
+
+
+
+ Under the Cost Savings section, these cards provide a summary of all deployments in your organization:
+
+ * **Under Provisioned Deployments** - Number of deployments with insufficient resource allocation
+ * **Over Provisioned Deployments** - Number of deployments with over-allocated resources
+ * **Idle Deployments** - Deployments with no traffic for the last 3 days
+ * **Auto-optimized deployments** - Number of deployments with auto-optimization enabled
+ * **Deployments that require attention** - Number of deployments with auto-optimization disabled that have recommendations for manual application
+ * **Total number of deployments** - Number of active deployments
+
+* **Cost Savings (Project Summary)**
+
+
+
+ This table under the Cost Savings section includes a summary of all projects in your organization. Each row represents a project with columns showing:
+ * Saved Cost after applying recommendations automatically/manually
+ * Actual Cost after Savings
+ * CPU and Memory Efficiency
+ * Ratio of Applied Suggestions to total available recommendations
+
+ You can click on any project in this table or use the top navigation to visit the Project Level cost insights.
+
+## Project Level
+
+
+
+The Project Level view is similar to the Organization Level, with all monthly metrics focused on the selected project. The charts, cards, plots, and tables follow the same format as the Organization Level.
+
+An additional feature at this level is the ability to toggle auto-apply for each component in the Cost Savings (Component Summary) table, or for all components. This simplifies the process of enabling auto-application of recommendations across all components in a project.
+
+
+
+
+These toggles enable automatic application of recommendations for all deployments in the selected components.
+
+## Component Level
+
+
+
+The Component Level differs from both Organization and Project levels. At the Component Level, you can access the release level through both deployment track (version) and environment configuration as shown:
+
+
+
+At the Release Level within the Component Level, you can view:
+
+* **Component details and Optimization Configurations**
+
+
+
+ This card shows configuration data for the deployment, including number of replicas, scale to zero settings, and horizontal pod auto-scaling that can be configured in DevOps.
+
+#### Optimization Configurations
+ Under the Optimization Configurations section, you can configure how Choreo applies cost optimization recommendations:
+
+ Auto Apply Recommendations:
+
+ When enabled, this toggle automatically implements resource right-sizing recommendations daily. Every 24 hours the system automatically checks if the release has any recommendations that would save more than $0.01, and if found, applies them without requiring manual intervention. This feature helps maintain continuous cost efficiency without constant monitoring.
+
+
+ Safety Buffer:
+
+ This setting determines how conservatively the optimization algorithm calculates resource recommendations:
+
+ Low: Adds a 10% buffer above the calculated resource requirements, which maximizes cost savings but provides less headroom for unexpected traffic spikes
+
+ High: Adds a 20% buffer above the calculated resource requirements, offering more capacity for handling unexpected load increases - recommended for production environments
+
+
+
+ The Safety Buffer setting helps you balance between maximum cost efficiency and maintaining reliable performance. For mission-critical applications or services with variable workloads, the High setting provides additional capacity to handle sudden traffic increases, while the Low setting is suitable for predictable workloads where you want to optimize costs more aggressively.
+ These configurations allow you to tailor the optimization behavior to your specific needs, balancing cost-saving opportunities with operational requirements at the component level.
+
+* **Monthly Cost, Missed Savings, Efficiency and Estimated Cost**
+
+
+
+ These cards summarize the cost and resource metrics similar to those at the Organization and Project levels.
+
+* **CPU Metrics Analysis**
+
+
+
+* **Memory Metrics Analysis**
+
+
+
+* **Recommendations**
+
+
+
+ The system provides **automated** and **manual** recommendations for cost reduction.
+
+### Optimization Types
+
+* **Resource Right-Sizing**
+ * Suggests optimized CPU and memory limits
+ * Provides potential cost savings per adjustment
+
+* **Enable Scale to Zero**
+ * Stops a component when no requests are being served
+ * Reduces idle infrastructure costs
+
+* **Stop Deployment**
+ * Identifies and halts unused deployments
+ * Prevents unnecessary spending on unused resources
+
+### Applying Recommendations
+
+* **Manually Apply**: You can review and apply suggestions individually
+* **Auto-Apply Toggle**: Enables automatic cost optimizations for projects/components
+
+## Conclusion
+
+The Choreo Cost Optimization feature helps you improve cloud resource efficiency by providing insights and recommendations at various levels. With interactive visualizations, automated recommendations, and optimization tracking, you can reduce infrastructure costs while maintaining performance.
diff --git a/en/pe-docs/docs/insights/delivery-insights/configure-delivery-insights.md b/en/pe-docs/docs/insights/delivery-insights/configure-delivery-insights.md
new file mode 100644
index 0000000000..ef812a9267
--- /dev/null
+++ b/en/pe-docs/docs/insights/delivery-insights/configure-delivery-insights.md
@@ -0,0 +1,96 @@
+# Delivery Insights
+
+{.cInlineImage-full}
+
+You can view delivery insights in Choreo to use as Key Performer Indicators (KPIs) to measure your organization's DevOps team's performance. Choreo enables this feature by default for all organizations. Delivery insights includes the following four key metrics (DORA metrics) that are regarded as the most important metrics to indicate team performance:
+
+- Deployment Frequency: How often an organization successfully releases to production
+- Lead Time for Changes: The amount of time it takes a commit to get into production
+- Change Failure Rate: The percentage of deployments causing a failure in production
+- Mean Time to Recovery: How long it takes an organization to recover from a failure in production
+
+
+Choreo enables two insights by default; deployment frequency and lead time for change.
+
+## Configure the Delivery Insights dashboard with all metrics
+
+To configure the dashboard by enabling the other two metrics, follow the steps below:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the Choreo Console, go to the top navigation menu and click **Organization**. Then select your organization.
+3. On the left navigation menu, click **Insights** and then click on **Delivery**.
+4. Scroll to the bottom of the dashboard and click **Configure**.
+5. Select your incident management system. Currently, Choreo only supports GitHub.
+
+## Configuring GitHub as the incident management system
+
+{.cInlineImage-full}
+
+To configure GitHub as the incident management system, follow the steps below:
+
+### Step 1: Authorize
+
+{.cInlineImage-threeQuarter}
+
+First, let's authorize Choreo to access the repositories used to record incidents.
+
+On the **Add Integration** page, select **GitHub** and click **Authorize with GitHub**.
+
+Once the authorization process is complete, you can start configuring the GitHub repository.
+
+### Step 2: Configure
+
+{.cInlineImage-threeQuarter}
+
+By default, Choreo collects incident details(issues) from all repositories containing Choreo components. However, you can configure a GitHub account and a GitHub repository to allow Choreo to read issues from a specific repository, and then click **Next**.
+
+| **Field** | **Description** | **Value** |
+|-----------------|-----------------------------|-----------------------------|
+| **Data Plane** | Choreo collects incident details by running a scheduled job which invokes the GitHub API periodically. This job runs on the user's data plane. This configuration allows users to specify a preferred data plane to run the job, especially when they have multiple data planes. | Select a preferred data plane from the **Data Plane** list. |
+| **GitHub Account** | The GitHub account you have your repositories in. | Select your GitHub account that includes the repository used for incident collection.|
+| **GitHub Repository**| By default, Choreo will collect incident details(issues) from all repositories that already have Choreo components. |
+
+
+### Step 3: Filter label
+
+{.cInlineImage-threeQuarter}
+
+The filter label allows Choreo to scrape issues associated with that label.
+
+- **Incident Label**: The label Choreo uses to identify incidents. For example, `Type/Incident`.
+
+- **Invalid incident label**(Optional): Choreo will not scrape issues with this label and will proceed to skip these issues. For example, `Resolution/Invalid`. You can use this label when you want to ignore issues. For example, closing an issue after identifying that it doesn't qualify as an incident issue as it was due to a user error.
+
+Once you configure the labels, click **Save**.
+
+Choreo will enable incident data publishing in the background once you save. Once completed, the metric charts will appear in the delivery insights dashboard for **Mean Time To Recover** and **Change Failure Rate**. If there are any issues in the configuration, the configure banner will reappear, and the user can proceed to reconfigure.
+
+### Step 4: Enrich incident tickets with deployment information
+
+Choreo extracts deployment information from the relevant incident and generates DORA metrics that help you analyze the deployment statistics related to the incidents. Therefore, you must manually update the GitHub issue with the relevant deployment-related information. Follow the steps below to add the deployment information to the GitHub issue.
+
+#### Get deployment details
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component** for which the incident was reported.
+2. On the left navigation menu, click **DevOps** and then click on **CD Pipelines**
+3. On the **Production Environment** card, click **Deployment History**.
+4. On the right-hand side panel, select the relevant deployment, and click **Release details** to copy the deployment details to the clipboard.
+
+ {.cInlineImage-small}
+
+#### Add deployment information to the GitHub issue
+
+1. Edit the GitHub issue to add the deployment information.
+2. Paste the deployment information you copied (in step 4 under the section `Get deployment details`) at the end of the issue body.
+3. Click **Save**.
+
+That's it! You have successfully configured your delivery insights dashboard to include all DORA metrics.
+
+!!! note
+ The delivery insights dashboard is expected to reflect the latest statistics within approximately 30 minutes.
+
+## Edit configurations
+
+ 
+
+ You can edit or override the configurations you made via the edit option in the dashboard.
diff --git a/en/pe-docs/docs/insights/delivery-insights/view-delivery-insights.md b/en/pe-docs/docs/insights/delivery-insights/view-delivery-insights.md
new file mode 100644
index 0000000000..3b46bd9cb9
--- /dev/null
+++ b/en/pe-docs/docs/insights/delivery-insights/view-delivery-insights.md
@@ -0,0 +1,110 @@
+# View Delivery Insights
+
+The Choreo delivery insights dashboard offers a detailed overview of DevOps team efficiency through DORA metrics, which consist of four core performance indicators. Here’s how Choreo visualizes these metrics: each is presented with a concise summary and illustrated dynamically through charts or graphs to highlight trends and insights.
+
+### Snapshot view
+
+{.cInlineImage-full}
+
+The snapshot view includes four tiles on the top of the dashboard, summarizing DORA metrics for the entire time period you select. The snapshot view categorizes each metric into four performance levels: elite, high, medium, and low. The categorization is based on the 2020 DORA metric report.
+
+{.cInlineImage-threeQuarter}
+
+### Time series view
+
+The time series view provides a graphical representation of how the statistics have changed over a period of time. You can use this view to analyze team performance and identify trends.
+
+{.cInlineImage-full}
+
+
+## Deployment frequency
+
+DORA team definition: The frequency at which an organization successfully releases to production.
+
+In Choreo, this translates to the number of times an organization deploys a component to the production environment. Choreo does not count the deployment done to the development or other lower environments.
+
+### Snapshot view
+
+{.cInlineImage-small}
+
+The snapshot view of the `Deployment Frequency` metric shows the deployment frequency for all components within the selected organization. The frequency is dynamically determined and rounded to the nearest measurement. For example, if there is more than one deployment daily, the deployment frequency is measured in `deployments per day`. If the deployment frequency is less, it is measured in a higher granularity. For example, `deployments per week`.
+
+A lower deployment frequency indicates that your organizational efficiency is low and that you need to evaluate and improve the processes to encourage frequent releases.
+
+Choreo also displays the total number of deployments for the selected time range and the percentage increase or decrease compared to the previous time range.
+
+### Time series view
+
+{.cInlineImage-half}
+
+The time series view for the `Deployment Frequency` metric visualizes the deployment count as a bar chart for the selected time period. Deployment count is aggregated based on the ‘view by’ selector. Hovering over each bar shows the counts for the aggregated period.
+Using this chart, organizations can identify deployment patterns, such as days of the week/months of the year where more deployments are likely to happen (near quarterly release days) and periods with fewer deployments. Decision-makers can then take steps to investigate and improve performance.
+This chart displays the pattern before and after a process change so you can use it to evaluate the team's performance after a significant process change.
+
+## Lead Time for Change
+
+ DORA team definition: The time it takes for a commit to reach production.
+
+ In Choreo, this translates into the time between committing and promoting a deployment to production. Although this approach may overlook any commits you push to production between two commits, it effectively assesses the efficiency of the review, approval, and CI/CD processes. Therefore, focusing on the production commits is adequate. If a team commits locally for extended periods without deploying to production, this gets reflected in the `Deployment Frequency` charts.
+
+### Snapshot view
+
+{.cInlineImage-small}
+
+The snapshot view of this metric displays the 95th percentile of the lead time for the selected time period. 95th percentile serves as a better representation as it filters out large outliers that can taint the average value. Lower lead times for change suggest that your organization has efficient processes for change review, approval, and CI/CD, while longer times suggest that the process needs to improve. Organizations can also use the categorization label to determine their standpoint on global standards.
+
+Additionally, Choreo also displays the percentage increase or decrease compared to the last time period.
+
+### Time series view
+
+{.cInlineImage-half}
+
+The time series view of this metric visualizes the lead time as a bar chart for the selected time period. The time is summed based on the ‘view by’ selector. To handle outliers, the y-axis employs a log scale that represents values read dynamically. Hovering over each bar displays the actual counts for the aggregated period.
+Using this chart, organizations can identify trends in their release process. For example, organizations can identify the time of the year when lead time rises, such as summer break. Also, organizations can use this to benchmark and evaluate new process changes. For example, if you introduced a process to include peer programming and reviewing, this chart can be used to evaluate its effect on the lead time and provide leadership with factual information to proceed further.
+
+## Change failure rate
+
+The DORA team definition: The percentage of deployments causing a failure in production.
+
+In Choreo, this translates to the ratio of deployments causing production failures to the total number of deployments. If there is at least one incident reported against a deployment, Choreo considers that deployment as a failed deployment in production. Any deployment-time failures are not counted as production failures because such failures don't impact the end user. For this metric to be accurate, the organization is expected to open incidents adhering to the proper format as it is crucial for Choreo to identify production failures.
+
+### Snapshot view
+
+{.cInlineImage-small}
+
+The snapshot view of this metric visualizes the change failure rate as a percentage for the selected time period. This will be the absolute percentage for the entire time period. When deciding on the time, the time of deployment is considered instead of the incident reported time. For example, the change failure rate for January 2023 will reflect the following:
+ - All deployments that happened within January.
+ - Any incidents that were reported at any time (in or after January) against the January deployments.
+
+This view helps leadership assess the quality of deliverables and identify areas for improvement. Higher rates suggest that the organization needs to improve its processes to bring in more quality assurance aspects such as improved code coverage and end-to-end test coverage.
+
+Additionally, Choreo also shows the percentage increase or decrease compared to the previous time period.
+
+### Time series view
+
+{.cInlineImage-half}
+
+The time series view of this metric displays it as a line chart with data points corresponding to the granularity selected by the ‘view by’ selector. The absolute percentage is shown for each granularity. Hovering over the line chart displays the actual counts for the aggregated period.
+This chart helps leadership identify timely trends in product quality aspects. For example, this view displays the months of the year where the failure rate is high (for example, close to quarterly release/announcement dates). Also, you can use this to measure the effectiveness of changes introduced to improve quality. For example, if the organization introduced an end-to-end test pipeline integration to the PR approval process, they can use this view to factually observe the timely impact of that change and determine how it decreases the failure rate.
+
+## Mean Time to Recover(MTTR)
+
+The DORA team definition: The time it takes for an organization to recover from a production failure.
+
+In Choreo, this measures the time from identifying a production incident to resolving it. This metric reflects the responsiveness and agility of incident management teams.
+
+Choreo depends on the open and close times of incidents to gather the relevant information. Therefore, for the dashboards to be accurate, organizations must follow process guidelines to update and close incident tickets efficiently in their incident management system.
+
+### Snapshot view
+
+{.cInlineImage-small}
+
+The snapshot view for this metric displays the mean recovery time for the selected time period. Choreo dynamically adjusts the time unit to measure this metric for better readability.
+This chart helps organizations evaluate the response time and agility of their incident handling teams, which in turn is an indication of stability. Higher MTTR means the leadership should look at new ways of improving the efficiency and agility of the teams handling incidents.
+
+### Time series view
+
+{.cInlineImage-half}
+
+The time series view of this metric shows how the mean time to recovery changes over time on a granularity based on the ‘view by’ selector. Each time the `granularity mean` would be used as the aggregation factor. Hovering over the line chart displays the actual counts for the aggregated period.
+This view helps leadership understand timely trends on mean time to recovery, such as higher values during holiday periods when there is less staff. Also, you can use this measurement to evaluate the effectiveness of process changes such as introducing an incident response plan. The trend view clearly shows the before and after statistics and the effectiveness of the process change.
diff --git a/en/pe-docs/docs/insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md b/en/pe-docs/docs/insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md
new file mode 100644
index 0000000000..a99692fa8f
--- /dev/null
+++ b/en/pe-docs/docs/insights/work-with-choreo-insights-api/access-the-choreo-insights-api.md
@@ -0,0 +1,72 @@
+# Access the Choreo Insights API
+
+The **Insights** page in the Choreo Console displays data retrieved from the Insights API exposed over the Internet. However, in some scenarios, you may need to retrieve data from external systems and implement custom dashboards to display the data.
+
+Choreo provides a secure and user-friendly approach to accomplish this requirement. Follow the steps given below:
+
+## Become a member of the Choreo System organization
+
+1. Access the Developer Portal of the `Choreo System` organization via [https://devportal.choreo.dev/choreosystem/applications](https://devportal.choreo.dev/choreosystem/applications) and sign in using your preferred method.
+
+2. To obtain access to the `Choreo System` organization, click **Request Access**.
+
+ {.cInlineImage-full}
+
+## Create an application and generate keys
+
+To create an application and generate keys, follow the steps below:
+
+1. To create a new application in the `Choreo System` organization, click **+ Create Application**.
+
+2. Enter a name for the application and click **Create**. This creates the application and takes you to the **Overview** page.
+
+3. To subscribe to the **Insights** API via the newly created application, follow the steps below:
+ 1. In the left navigation menu, click **Subscriptions**.
+ 2. In the **Subscription Management** pane, click **+ Add APIs**.
+ 3. Search for `Insights` and click **Add**.
+
+4. To generate credentials for the application, follow the steps given below:
+ 1. In the left navigation menu, click **Production** under **Credentials**.
+ 2. Click **Generate Credentials**. Choreo generates tokens and populates the **Consumer Key** and **Consumer Secret** fields in the **Application Keys** pane.
+
+5. To specify an appropriate token expiry time for the application, follow the steps given below:
+ 1. In the **Application Keys** pane, click to expand **Advanced Configurations**.
+ 2. Specify an appropriate value in the **Application access token expiry time** field and click **Update**.
+
+ {.cInlineImage-threeQuarter}
+
+6. Execute the following cURL command to generate an access token:
+
+ ```bash
+ curl --location --request POST 'https://sts.choreo.dev/oauth2/token' \
+ --header 'Authorization: Basic
+
+
+
+## Objects
+
+### API
+
+Represents API details.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+listAllAPI
+[API]
+
+
+Fetches all the APIs with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
+can configure the
+provider parameter to further filter the APIs by a specific provider.
+
+
+
+provider
+String
+
+
+The name of the API provider.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+listApplications
+[Application]
+
+
+Fetches all the applications with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
+can configure the
+applicationFilter parameter to further filter the applications by a specific application filter.
+
+
+
+applicationFilter
+ApplicationFilter
+
+
+The application filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+listProviders
+[Provider]
+
+
+Fetches all the API providers with the given combination of tenant ID, environment ID, and organization ID.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+listSubscribers
+[Subscriber]
+
+
+Fetches all the API subscribers with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
+can configure the
+subscriberFilter parameter to further filter the subscribers.
+
+
+
+subscriberFilter
+SubscriberFilter
+
+
+The subscriber filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+listOrganizations
+[Organization]
+
+
+Fetches all the organizations of a user.
+
+
+
+
+listEnvironments
+[Environment]
+
+
+Fetches all the environments of an organization.
+
+
+
+
+org
+OrgFilter!
+
+
+The organization filter.
+
+
+
+
+projectId
+String
+
+
+The project ID by which the results need to be filtered. It is optional to specify a value for this
+parameter. Note that providing a project ID with an on-prem key is not allowed.
+
+
+
+
+listTenants
+[String]
+
+
+Fetches all the tenants with the given combination of environment ID and organization ID.
+
+
+
+
+tenantDataFilter
+TenantDataFilter!
+
+
+The tenant filter.
+
+
+
+
+getTotalTraffic
+Int
+
+
+Returns the total traffic during the given time range for the specified combination of tenant ID, environment ID,
+and organization ID.
+
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTotalErrors
+Int
+
+
+Returns the total number of errors that occurred during the given time range for the specified combination of tenant
+ID, environment ID, and organization ID.
+
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getOverallLatency
+Float
+
+
+Returns the overall response latency (95th percentile value) during the given time range for the specified
+combination of tenant ID, environment ID, and organization ID.
+
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getLatencySummary
+LatencySummary
+
+
+Returns the response latency value (95th percentile value) for each time granularity within the specified time range
+for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+
+latencySummaryFilter parameter to further filter the results.
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+latencySummaryFilter
+LatencySummaryFilter
+
+
+The latency summary filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getSuccessSummary
+SuccessSummary
+
+
+Returns the number of successful (2xx response code) hit count for each time granularity within the specified time
+range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+
+granularity parameter to override the default granularity value.
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+granularity
+String
+
+
+The granularity value.
+
+
+
+
+getErrorSummary
+ErrorSummary
+
+
+Returns the number of unsuccessful hits (i.e., the total of both
+4xx and 5xx response codes) for each time
+granularity within the specified time range for the given combination of tenant ID, environment ID, and organization
+ID. Optionally, you can configure the granularity parameter to override the default granularity value.
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+granularity
+String
+
+
+The granularity value.
+
+
+
+
+getErrorsByCategory
+ErrorsByCategory
+
+
+Returns the number of proxy errors (i.e., the total of both
+4xx and 5xx response codes) by each error category
+for each time granularity within the specified time range for the given combination of tenant ID, environment ID,
+and organization ID. Optionally, you can configure the errorsByCategoryFilter parameter to further filter the
+results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+errorsByCategoryFilter
+ErrorsByCategoryFilter
+
+
+The errors by category filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getErrorsDetails
+DetailsOfErrors
+
+
+Returns details of each proxy error (for both
+4xx and 5xx response codes) within the specified time range for
+the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+errorsDetailsFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+errorsDetailsFilter
+ErrorsDetailsFilter
+
+
+The error details filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getProxyTargetErrorsOverTime
+[ErrorsByStatusCodeCategory]
+
+
+Returns a list of hit counts for proxy and target errors for each time granularity within the specified time range
+for the given combination of tenant ID, environment ID, and organization ID. The errors in each proxy and target
+result set are grouped as
+4xx, 5xx, and total. Optionally, you can configure the errorsByStatusCodeFilter
+parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+errorsByStatusCodeFilter
+ErrorsByStatusCodeFilter
+
+
+The errors by status code filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getErrorsByStatusCode
+ErrorsByStatusCode
+
+
+Returns the hit count for each error response code (
+401, 404, and 500 etc.,) for each API within the specified
+time range for the given combination of tenant ID, environment ID, and organization ID.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+errorCountByStatusCodeFilter
+ErrorCountByStatusCodeFilter!
+
+
+The error count by status code filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTotalErrorsByAPI
+TotalError
+
+
+Returns the total proxy error hit count for an API across for the given combination of tenant ID, environment ID,
+and organization ID. Optionally, you can configure the
+filter parameter to further filter the results by a given
+time range.
+
+
+
+filter
+TimeFilter
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+apiId
+ID!
+
+
+The API ID.
+
+
+
+
+getAPIUsageOverTime
+[APIUsageOverTime]
+
+
+Returns a list of details related to the usage of each API over time for each time granularity within the specified
+time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can
+configure the
+apiUsageOvertimeFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+apiUsageOvertimeFilter
+APIUsageOverTimeFilter
+
+
+The API usage overtime filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getAPIUsageByAppOverTime
+APIUsageByAppOverTime
+
+
+Returns API usage by each application over time for each time granularity within the specified time range for the
+given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+
+apiUsageOvertimeFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+apiUsageOvertimeFilter
+APIUsageOverTimeFilter
+
+
+The API usage overtime filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getAPIUsageByBackendOverTime
+APIUsageByBackendOverTime
+
+
+Returns API usage by each backend over time for each time granularity within the specified time range for the given
+combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+
+apiUsageByBackendOverTimeFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+apiUsageByBackendOverTimeFilter
+APIUsageByBackendOverTimeFilter
+
+
+The API usage by backend overtime filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getResourceUsage
+ResourceUsages
+
+
+Returns API usage by resource within the specified time range for the given combination of tenant ID, environment
+ID, and organization ID. Optionally, you can configure the
+resourceUsageFilter parameter to further filter the
+results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+resourceUsageFilter
+ResourceUsageFilter
+
+
+The resource usage filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTotalTrafficByAPI
+Int
+
+
+Returns the total hit count for an API for the given combination of tenant ID, environment ID, and organization ID.
+Optionally, you can configure the
+filter parameter to further filter the results by a given time range.
+
+
+
+filter
+TimeFilter
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+apiId
+ID!
+
+
+The API ID.
+
+
+
+
+topSlowestAPIs
+[SlowAPI]
+
+
+Returns a list of top slowest APIs based on the response latency (95th percentile value) within the specified time
+range for the given combination of tenant ID, environment ID, and organization ID.
+
+
+
+
+filter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+limit
+Int!
+
+
+The limit for the slow APIs list.
+
+
+
+
+getLatency
+APILatency
+
+
+Returns different latency category values (95th percentile values) for a given API over time for each time
+granularity within the specified time range for the given combination of tenant ID, environment ID, and organization
+ID.
+
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+latencyFilter
+LatencyFilter!
+
+
+The latency filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getOverallLatencyByAPI
+OverallLatency
+
+
+Returns the overall response latency (95th percentile value) for an API for the given combination of tenant ID,
+environment ID, and organization ID. Optionally, you can configure the
+filter parameter to further filter the
+results by a given time range.
+
+
+
+filter
+TimeFilter
+
+
+The time filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+apiId
+ID!
+
+
+The API ID.
+
+
+
+
+getCacheHitsAndMisses
+CacheHits
+
+
+Return the total number of response cache hits, misses, and hit percentage for an API over time for each time
+granularity within the specified time range for the given combination of tenant ID, environment ID, and
+organization ID.
+
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+cacheFilter
+CacheFilter
+
+
+The cache filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTopPlatforms
+[Platform]
+
+
+Returns a list of top platforms ranked based on the hit count within the specified time range for the given
+combination of tenant ID, environment ID, and organization ID. The result list includes the top nine platforms with
+the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit count.
+Optionally, you can configure the
+deviceFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+deviceFilter
+DeviceFilter
+
+
+The device filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTopUserAgents
+[UserAgent]
+
+
+Returns a list of top user agents ranked based on the hit count within the specified time range for the given
+combination of tenant ID, environment ID, and organization ID. The result list includes the top nine user agents
+with the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit
+count. Optionally, you can configure the
+deviceFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+deviceFilter
+DeviceFilter
+
+
+The device filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getAPIUsageByGeoLocation
+[UsageByGeoLocation]
+
+
+NOTE: Currently, this operation returns data only for on-premise environments.
+
+Returns API usage by country within the specified time range for the given combination of tenant ID, environment ID,
+and organization ID. Optionally, you can configure the
+geoLocationFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+geoLocationFilter
+GeoLocationFilter
+
+
+The geolocation filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getAPIsUsageByApplications
+[APIUsageByApplication]
+
+
+Returns details relating to the usage of each API by application within the specified time range for the given
+combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
+
+apiUsageByAppFilter parameter to further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+apiUsageByAppFilter
+APIUsageByAppFilter
+
+
+The API usage by app filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getTopAPIsByAlertCount
+TopAPIsByAlertCount
+
+
+Returns top APIs ranked based on the alert count within the specified time range for the given combination of tenant
+ID, environment ID, and organization ID. Optionally, you can configure the
+topAPIsByAlertCountFilter parameter to
+further filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+topAPIsByAlertCountFilter
+TopAPIsByAlertCountFilter
+
+
+The top APIs by alert count filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getAlertSummary
+AlertSummaries
+
+
+Returns a summary for each alert within the specified time range for the given combination of tenant ID,
+environment ID, and organization ID. Optionally, you can configure the
+alertSummaryFilter parameter to further
+filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+alertSummaryFilter
+AlertSummaryFilter
+
+
+The alert summary filter.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+getSuccessAPIsUsageByApplications
+[SuccessAPIUsageByApplication]
+
+
+NOTE: This operation can only be invoked via using an on-prem key as the authentication header.
+
+Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API,
+grouped by each application. Optionally, you can configure the
+successAPIUsageByAppFilter parameter to further
+filter the results.
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+successAPIUsageByAppFilter
+SuccessAPIUsageByAppFilter
+
+
+The successful API usage by application filter.
+
+
+
+
+getSuccessAPIsUsageByApplicationsWithOnPremKey
+[SuccessAPIUsageByApplication]
+
+
+Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API,
+grouped by each application. Optionally, you can configure the
+successAPIUsageByAppFilter parameter to further
+filter the results.
+
+
+
+onPremKey
+String!
+
+
+The value of the On-Prem key.
+
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+successAPIUsageByAppFilter
+SuccessAPIUsageByAppFilter
+
+
+The successful API usage by application filter.
+
+
+
+
+getCustomReportOvertime
+CustomReportOvertime
+
+
+Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+metric
+Metric!
+
+
+The metric for which data needs to be retrieved.
+
+
+
+
+groupByFields
+[GroupByField]!
+
+
+The column/field by which data needs to be retrieved.
+
+
+
+
+groupByValues
+[String]!
+
+
+The value used to filter by the
+groupByField.
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+getCustomReportTopOvertime
+CustomReportTopOvertime
+
+
+Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans for
+the top N values for the selected groupByField.
+
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+timeFilter
+TimeFilter!
+
+
+The time filter.
+
+
+
+
+metric
+Metric!
+
+
+The metric for which data needs to be retrieved.
+
+
+
+
+groupByFields
+[GroupByField]!
+
+
+The column/field by which the data should be grouped.
+
+
+
+
+groupByValues
+[String]!
+
+
+The value used to filter by the
+groupByField.
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+getGroupByValues
+[[String]]
+
+
+Returns a list of value sets by which you can group the data available for the selected
+groupBy fields.
+
+
+
+dataFilter
+DataFilter!
+
+
+The data filter.
+
+
+
+
+groupByFields
+[GroupByField]!
+
+
+The column/field for which the API needs to retrieve distinct values.
+
+
+
+
+
+groupByValues
+[String]!
+
+
+The value used to filter by the
+groupByField.
+
+
+
+
+
+### APILatency
+
+Represents latency values for a single API over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+id
+ID!
+
+
+The ID of the API.
+
+
+
+
+name
+String!
+
+
+The API name.
+
+
+
+
+version
+String!
+
+
+The API version.
+
+
+
+
+
+provider
+String!
+
+
+The API provider name.
+
+
+
+
+
+
+### APIUsage
+
+Represents the API usage for a single timestamp. The timestamp is calculated based on the granularity value provided.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+summary
+[Latency]
+
+
+A list containing latency category values over time. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### APIUsageByApp
+
+Represents API usage across APIs by a single application.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+
+count
+Int!
+
+
+The API usage count.
+
+
+
+
+
+
+### APIUsageByAppOverTime
+
+Represents API usage across APIs by applications over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+applicationId
+ID!
+
+
+The application ID.
+
+
+
+
+applicationName
+String!
+
+
+The application name.
+
+
+
+
+applicationOwner
+String!
+
+
+The name of the application owner.
+
+
+
+
+
+usage
+[APIUsage]
+
+
+A list containing the APIs usage values. Returns an empty array if no data is available.
+
+
+
+
+
+
+### APIUsageByApplication
+
+Represents a single API usage by a single application.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[APIUsageByApp]
+
+
+A list containing the API usage values across APIs, grouped by the application. Returns an empty array if no data is
+available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### APIUsageByBackend
+
+Represents API usage across APIs by a single backend.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+String!
+
+
+The ID of the API.
+
+
+
+
+applicationId
+String!
+
+
+The Application ID.
+
+
+
+
+applicationName
+String!
+
+
+The application name.
+
+
+
+
+applicationOwner
+String!
+
+
+The name of the application owner.
+
+
+
+
+
+count
+Int!
+
+
+The usage of the API by the application.
+
+
+
+
+
+
+### APIUsageByBackendOverTime
+
+Represents API usage across APIs by each backend over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+backend
+String!
+
+
+The name of the backend.
+
+
+
+
+
+usage
+[APIUsage]
+
+
+A list containing the APIs usage values. Returns an empty array if no data is available.
+
+
+
+
+
+
+### APIUsageOverTime
+
+Represents a single API usage over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[APIUsageByBackend]
+
+
+A list containing the API usage values across APIs by each backend. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### AlertSummaries
+
+Represents alert summaries.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID
+
+
+The ID of the API.
+
+
+
+
+usage
+[APIUsage]
+
+
+A list containing the API usage values. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### AlertSummary
+
+Represents a summary for an alert.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[AlertSummary]
+
+
+A list containing the alert summary for each alert. Returns an empty array if no data is available.
+
+
+
+
+
+pagination
+Pagination!
+
+
+The pagination details.
+
+
+
+
+
+
+### Application
+
+Represents application details.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID!
+
+
+The ID of the API.
+
+
+
+
+timestamp
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+category
+String!
+
+
+The alert category. Possible values are
+LATENCY and TRAFFIC.
+
+
+
+metric
+String!
+
+
+The alert metric. Possible values are
+RESPONSE_LATENCY and TOTAL_TRAFFIC.
+
+
+
+severity
+String!
+
+
+The severity level of the alert. Possible values are
+LOW, MEDIUM, and HIGH.
+
+
+
+
+message
+String!
+
+
+The alert details.
+
+
+
+
+
+
+### CacheHit
+
+Represents the response cache hits and misses for a single timestamp. The timestamp is calculated based on the
+granularity value provided.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+id
+ID!
+
+
+The Application ID.
+
+
+
+
+name
+String!
+
+
+The application name.
+
+
+
+
+
+owner
+String!
+
+
+The name of the application owner.
+
+
+
+
+
+
+### CacheHits
+
+Represents the response cache hits and misses over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+hits
+Int!
+
+
+The number of times the response cache was hit.
+
+
+
+
+misses
+Int!
+
+
+The number of times the response cache was missed.
+
+
+
+
+
+hitPercentage
+Float!
+
+
+The response cache hits as a percentage of the sum of hits and misses.
+
+
+
+
+
+
+### CustomReportGroupBy
+
+Represents the usage data overtime for the selected parameters of a specific
+
+
+
+Field
+Argument
+Type
+Description
+
+
+summary
+[CacheHit]
+
+
+A list containing cache hits, misses, and the hit percentage over time. Returns an empty array if no data is
+available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+groupByValue.
+
+
+
+
+
+### CustomReportOvertime
+
+Represents usage data overtime for the selected parameters.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+groupByValue
+ID!
+
+
+The distinct group-by value that is used as an ID.
+
+
+
+
+
+usage
+[CustomReportUsage]
+
+
+A list containing the usage values. This returns an empty array if no data is available.
+
+
+
+
+
+
+### CustomReportTopOvertime
+
+Represents usage data overtime for the selected parameters grouped by the top N
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[CustomReportUsage]
+
+
+A list containing the usage values. This returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+groupByValues.
+
+
+
+
+
+### CustomReportUsage
+
+Represents usage data for a single timestamp in
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[CustomReportGroupBy]
+
+
+A list containing the usage values grouped by the selected
+groupByField. This returns an empty array if no data is
+available.
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+CustomReports.
+
+
+
+
+
+### DetailsOfErrors
+
+Represents error details over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+
+value
+Int!
+
+
+The usage value (Hit Count/ Latency).
+
+
+
+
+
+
+### Environment
+
+Represents an environment.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[ErrorDetails]!
+
+
+A list containing error details over time. Returns an empty array if no data is available.
+
+
+
+
+
+pagination
+Pagination!
+
+
+The pagination details.
+
+
+
+
+
+
+### ErrorCountByCategory
+
+Represents the number of errors from each category for a single timestamp. The timestamp is calculated according to the
+provided granularity value. If you select some categories, the error counts are retrieved only for those categories,
+and a
+
+
+
+Field
+Argument
+Type
+Description
+
+
+id
+String!
+
+
+The environment ID.
+
+
+
+
+externalEnvId
+String!
+
+
+The external environment ID.
+
+
+
+
+internalEnvId
+String
+
+
+The internal environment ID.
+
+
+
+
+sandboxEnvId
+String
+
+
+The sandbox environment ID.
+
+
+
+
+name
+String!
+
+
+The environment name.
+
+
+
+
+
+type
+EnvironmentType!
+
+
+The environment type. A Choreo environment is labeled as
+CHOREO, a private Choreo environment is labeled as
+CHOREO_PRIVATE, and the on-premise environment is labeled as ON_PREM.
+
+null value is shown for the other categories that are not selected.
+
+
+
+
+
+### ErrorCountByCode
+
+Represents the error count for a single error status code.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+auth
+Int
+
+
+The count of authorization errors.
+
+
+
+
+targetConnectivity
+Int
+
+
+The count of target connectivity errors.
+
+
+
+
+throttled
+Int
+
+
+The count of throttling errors.
+
+
+
+
+
+other
+Int
+
+
+The count of other errors.
+
+
+
+
+
+
+### ErrorCountByCodeForAPI
+
+Represents the error count for each status code for a single API.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+statusCode
+String!
+
+
+The error status code.
+
+
+
+
+
+count
+Int!
+
+
+The error count.
+
+
+
+
+
+
+### ErrorDetails
+
+Represents details of an error for a single timestamp. The timestamp is calculated according to the granularity value
+provided.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID!
+
+
+The ID of the API.
+
+
+
+
+
+errorCountByCode
+[ErrorCountByCode]
+
+
+A list containing the error count for each error status code. Returns an empty array if no data is available.
+
+
+
+
+
+
+### ErrorStatusCodeCategoryCounts
+
+Represents errors by the main status code (
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID
+
+
+The ID of the API.
+
+
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+applicationId
+String
+
+
+The Application ID.
+
+
+
+
+applicationName
+String
+
+
+The application name.
+
+
+
+
+applicationOwner
+String
+
+
+The name of the application owner.
+
+
+
+
+reason
+String!
+
+
+The reason for the error.
+
+
+
+
+
+count
+Int!
+
+
+The error count.
+
+
+4xx or 5xx) and the total error count.
+
+
+
+
+
+### ErrorSummary
+
+Provides the unsuccessful usage (i.e.,
+
+
+
+Field
+Argument
+Type
+Description
+
+
+_4xx
+Int
+
+
+The number of client errors.
+
+
+
+
+_5xx
+Int
+
+
+The number of server errors.
+
+
+
+
+
+total
+Int
+
+
+The total number of client and server errors.
+
+
+4xx and 5xx response codes) summary across all APIs.
+
+
+
+
+
+### ErrorValue
+
+Represents the unsuccessful request count (i.e.,
+
+
+
+Field
+Argument
+Type
+Description
+
+
+summary
+[ErrorValue]!
+
+
+A list containing unsuccessful usage values. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+4xx and 5xx response codes) for a single timestamp. The timestamp
+is calculated based on the granularity value provided.
+
+
+
+
+
+### ErrorsByCategory
+
+Represents the errors by category over time.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+
+errorCount
+Int
+
+
+Represents the error request count.
+
+
+
+
+
+
+### ErrorsByStatusCode
+
+Represents the error counts grouped by status code for each API.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+errors
+[ErrorCountByCategory]
+
+
+A list containing the error count for each error category over time. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### ErrorsByStatusCodeCategory
+
+Represents the error category values (grouped as
+
+
+
+Field
+Argument
+Type
+Description
+
+
+errors
+[ErrorCountByCodeForAPI]!
+
+
+A list containing the error count for each status code for each API. Returns an empty array if no data is available.
+
+
+
+
+
+pagination
+Pagination!
+
+
+Pagination details.
+
+
+4xx, 5xx, and total) for both proxy and target errors for a
+single timestamp. The timestamp is calculated based on the granularity value provided.
+
+
+
+
+
+### Latency
+
+Represents latency values for each latency category for a single timestamp. The timestamp is calculated based on the
+granularity value provided.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+proxy
+ErrorStatusCodeCategoryCounts
+
+
+Represents proxy-related errors categorized as client errors (
+4xx response codes) or server errors (5xx response
+codes), and the total of both categories.
+
+
+
+
+target
+ErrorStatusCodeCategoryCounts
+
+
+Represents target-related errors categorized as client errors (
+4xx response codes) or server errors (5xx
+response codes), and the total of both categories.
+
+
+
+
+
+### LatencySummary
+
+Provides the latency summary.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+response
+Int
+
+
+The response latency (95th percentile) in milliseconds (ms).
+
+
+
+
+backend
+Int
+
+
+The backend latency (95th percentile) in milliseconds (ms).
+
+
+
+
+requestMediation
+Int
+
+
+The request mediation latency (95th percentile) in milliseconds (ms).
+
+
+
+
+responseMediation
+Int
+
+
+The response mediation latency (95th percentile) in milliseconds (ms).
+
+
+
+
+responseMedian
+Int
+
+
+The median (50th percentile) of the response latency in milliseconds (ms).
+
+
+
+
+backendMedian
+Int
+
+
+The median (50th percentile) of the backend latency in milliseconds (ms).
+
+
+
+
+requestMediationMedian
+Int
+
+
+The median (50th percentile) of the request mediation latency in milliseconds (ms).
+
+
+
+
+
+responseMediationMedian
+Int
+
+
+The median (50th percentile) of the response mediation latency in milliseconds (ms).
+
+
+
+
+
+
+### LatencyValue
+
+Represents the latency value for a single timestamp. The timestamp is calculated according to the provided granularity
+value.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+summary
+[LatencyValue]!
+
+
+A list containing latency values. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+
+
+
+
+### Organization
+
+Represents an organization.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+
+latencyTime
+Float!
+
+
+Represents the latency (95th percentile) time in milliseconds (ms).
+
+
+
+
+
+
+### OverallLatency
+
+Represents the overall latency values.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+id
+String!
+
+
+The organization ID.
+
+
+
+
+uuid
+ID!
+
+
+The organization UUID.
+
+
+
+
+handle
+String!
+
+
+The organization handle name.
+
+
+
+
+
+name
+String!
+
+
+The organization name.
+
+
+
+
+
+
+### Pagination
+
+Represents pagination details.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+
+response
+Float
+
+
+The response latency (95th percentile value) in milliseconds (ms).
+
+
+
+
+
+
+### Platform
+
+Represents a platform.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+total
+Int!
+
+
+The total number of results.
+
+
+
+
+limit
+Int!
+
+
+The number of items in the result set.
+
+
+
+
+offset
+Int!
+
+
+The offset value for the result set.
+
+
+
+
+sortBy
+String!
+
+
+The sorting column name of the result set.
+
+
+
+
+
+sortOrder
+String!
+
+
+The sorting order of the result set. Possible values are
+asc and desc.
+
+
+
+
+
+### Provider
+
+Represents API Provider details.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+platform
+String!
+
+
+The name of the platform.
+
+
+
+
+
+count
+Int!
+
+
+The usage of the platform.
+
+
+
+
+
+
+### ResourceUsage
+
+Represents the usage of a single API resource.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+
+name
+String!
+
+
+The API provider name.
+
+
+
+
+
+
+### ResourceUsages
+
+Represents API resource usages.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID!
+
+
+The ID of the API.
+
+
+
+
+apiResourceTemplate
+String!
+
+
+The API resource template.
+
+
+
+
+apiMethod
+String!
+
+
+The API method.
+
+
+
+
+
+count
+Int!
+
+
+The usage of the API resource.
+
+
+
+
+
+
+### SlowAPI
+
+A slow API identified based on the response latency (95th percentile).
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[ResourceUsage]
+
+
+A list with the usage of each API resource. Returns an empty array if no data is available.
+
+
+
+
+
+pagination
+Pagination!
+
+
+Pagination details.
+
+
+
+
+
+
+### Subscriber
+
+Represents API Subscriber details.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID!
+
+
+The ID of the API.
+
+
+
+
+
+latency
+Int!
+
+
+Represents the latency (95th percentile) time in milliseconds (ms).
+
+
+
+
+
+
+### SuccessAPIUsageByApplication
+
+Represents successful usages(that have resulted in the
+
+
+
+Field
+Argument
+Type
+Description
+
+
+
+name
+String!
+
+
+The name of the API subscriber.
+
+
+2xx response code) of an API by an application.
+
+
+
+
+
+### SuccessSummary
+
+Provides the successful (2xx response code) usage summary across all the APIs.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+String!
+
+
+The ID of the API.
+
+
+
+
+apiName
+String!
+
+
+The name of the API.
+
+
+
+
+apiVersion
+String!
+
+
+The version of the API.
+
+
+
+
+apiCreatorTenantDomain
+String!
+
+
+The tenant domain of the API creator.
+
+
+
+
+applicationId
+String!
+
+
+The application ID.
+
+
+
+
+applicationName
+String!
+
+
+The name of the application.
+
+
+
+
+applicationOwner
+String!
+
+
+The name of the application owner.
+
+
+
+
+
+count
+Int!
+
+
+
+
+
+### SuccessValue
+
+Represents the successful request count (i.e., requests that have received the
+
+
+
+Field
+Argument
+Type
+Description
+
+
+summary
+[SuccessValue]!
+
+
+A list containing successful usage values. Returns an empty array if no data is available.
+
+
+
+
+
+granularity
+String!
+
+
+The granularity value for which data is retrieved.
+
+
+2xx response code) for a single
+timestamp. The timestamp is calculated according to the granularity value provided.
+
+
+
+
+
+### TopAPIByAlertCount
+
+Represents a top API by alert count.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+timeSpan
+String!
+
+
+Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
+granularity value is
+1d, the timestamp represents the start of the day calculated adhering to the timezone
+provided in the time filter.
+e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
+
+
+
+
+requestCount
+Int!
+
+
+Represents the successful request count.
+
+
+
+
+
+
+### TopAPIsByAlertCount
+
+Represents the top APIs by alert count.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+apiId
+ID!
+
+
+The ID of the API.
+
+
+
+
+
+count
+Int!
+
+
+The alert count.
+
+
+
+
+
+
+### TotalError
+
+Represents the total errors.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+usage
+[TopAPIByAlertCount]
+
+
+A list containing top APIs by alert count. Returns an empty array if no data is available.
+
+
+
+
+
+pagination
+Pagination!
+
+
+The pagination details.
+
+
+
+
+
+
+### UsageByGeoLocation
+
+Represents the usage of a single API in a single country.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+
+proxy
+Int
+
+
+The proxy-related error count.
+
+
+
+
+
+
+### UserAgent
+
+Represents a user agent.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+country
+String!
+
+
+The name of the country.
+
+
+
+
+
+count
+Int!
+
+
+The usage of the API.
+
+
+
+
+
+
+## Inputs
+
+### APIUsageByAppFilter
+
+Filters the API usage by application results.
+
+
+
+
+
+Field
+Argument
+Type
+Description
+
+
+userAgent
+String!
+
+
+The name of the user agent.
+
+
+
+
+
+count
+Int!
+
+
+The usage of the user agent.
+
+
+
+
+
+
+### APIUsageByBackendOverTimeFilter
+
+Filters the results for API usage by backend over time.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+appIds
+[String]
+
+
+The results are filtered for the list of applications you specify here. A maximum of five application IDs can be
+defined.
+
+
+
+
+
+subscribers
+[String]
+
+
+The results are filtered for the list of subscribers you specify here. A maximum of five subscriber IDs can be
+defined.
+
+
+
+
+
+
+### APIUsageOverTimeFilter
+
+Filters the results for API usage over time.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### AlertSummaryFilter
+
+Filters the alerts summary results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+appIds
+[String]
+
+
+The results are filtered for the list of applications you specify here. A maximum of five application IDs can be
+defined.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### ApplicationFilter
+
+Filters applications by the application owner and API IDs.
+
+
+
+
+
+Field
+Type
+Description
+
+
+paginationFilter
+PaginationFilter
+
+
+The pagination filter.
+
+
+
+
+searchFilter
+SearchFilter
+
+
+The search filter.
+
+
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+
+category
+String
+
+
+The alert category by which the results need to be filtered. The available categories to select are
+TRAFFIC and
+LATENCY.
+
+
+
+
+
+### CacheFilter
+
+Filters response cache results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+owner
+String
+
+
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+
+
+### DataFilter
+
+Filters results by the given combination of organization, environment, and tenant.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The results are filtered by the API ID specified here.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### DeviceFilter
+
+Filters results related to devices.
+
+
+
+
+
+Field
+Type
+Description
+
+
+orgId
+String!
+
+
+The organization by which the results need to be filtered. It is required to specify a value for this parameter.
+
+
+
+
+environmentId
+String
+
+
+The environment ID by which the results need to be filtered. It is required to specify a value for this parameter.
+
+
+
+
+environmentIds
+[String]
+
+
+The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter.
+
+
+
+
+tenant
+String!
+
+
+The name of the tenant by which the results need to be filtered. It is required to specify a value for this
+parameter.
+
+
+
+
+
+projectId
+String
+
+
+The project ID by which the results need to be filtered. It is optional to specify a value for this
+parameter. Note that providing a project ID with an on-prem key is not allowed.
+
+
+
+
+
+
+### ErrorCountByStatusCodeFilter
+
+Filters errors by status code results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+
+
+### ErrorsByCategoryFilter
+
+Filters errors by category results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The results are filtered by the API ID specified here.
+
+
+
+
+errorType
+ErrorType!
+
+
+The type of the error. It is required to specify a value for this parameter.
+
+
+
+
+errorCodeType
+ErrorCodeType
+
+
+The error code type. If this parameter is not configured, both client-related error response codes (
+401, 404,
+etc.) and server-related response codes (500, 501, etc.) are included in the result set.
+
+
+
+
+paginationFilter
+PaginationFilter
+
+
+The pagination filter.
+
+
+
+
+
+
+### ErrorsByStatusCodeFilter
+
+Filters errors by status code results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The ID of the API.
+
+
+
+
+categories
+[String]
+
+
+The list of categories by which the results need to be filtered. Category values that you can specify here are
+
+AUTH, TARGET_CONNECTIVITY, THROTTLED, and OTHER.
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### ErrorsDetailsFilter
+
+Filters the results for error details.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The results are filtered by the API ID specified here.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### GeoLocationFilter
+
+Filters the API usage by geolocation results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The results are filtered by the API ID specified here.
+
+
+
+
+appId
+String
+
+
+The application ID by which the results need to be filtered.
+
+
+
+
+category
+String
+
+
+The error category by which the results need to be filtered. The error category that you can specify here must be
+one of the
+AUTH TARGET_CONNECTIVITY, THROTTLED, and OTHER values.
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+paginationFilter
+PaginationFilter
+
+
+The pagination filter.
+
+
+
+
+
+searchFilter
+SearchFilter
+
+
+The search filter.
+
+
+
+
+
+
+### LatencyFilter
+
+Filters latency results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here.
+
+
+
+
+
+
+### LatencySummaryFilter
+
+Filters latency summary results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String!
+
+
+The results are filtered by the API ID specified here. It is required to specify a value for this parameter.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### OrgFilter
+
+Filters results for the given organization.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiId
+String
+
+
+The results are filtered by the API ID specified here.
+
+
+
+
+
+granularity
+String
+
+
+The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
+for the related time range is applied. The possible granularity values that you can specify are
+1m, 15m, 1h,
+1d, and 7d.
+
+
+
+
+
+### PaginationFilter
+
+Filters related to pagination.
+
+
+
+
+
+Field
+Type
+Description
+
+
+
+orgId
+String!
+
+
+The ID of the organization by which the results need to be filtered. It is required to specify a value for this
+parameter.
+
+
+
+
+
+
+### ResourceUsageFilter
+
+Filters resource usage results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+limit
+Int
+
+
+The total number of rows in the result set. This value must be a positive integer. If this limit value is not set,
+the total number of rows is five by default.
+
+
+
+
+offset
+Int
+
+
+The offset value to set when filtering results. This value must be zero or a positive integer. If you do not specify
+an offset value, the default offset value (i.e.,
+0) applies.
+
+
+
+sortBy
+String
+
+
+The column name by which the results are sorted. If the
+sortBy value is not set, the default column of the related
+operation that is available for sorting purposes is used.
+
+
+
+
+sortOrder
+String
+
+
+The order in which the results are sorted. Possible values are
+asc (to sort in ascending order) and desc (to
+sort in descending order). If no value is specified, the results are sorted in ascending order by default (except
+for count-specific operations such as getTopAPIsByAlertCount where the results are always sorted in descending
+order).
+
+
+
+
+
+### SearchFilter
+
+Filters results by searching matching results for the provided search text.
+
+
+
+
+
+Field
+Type
+Description
+
+
+paginationFilter
+PaginationFilter
+
+
+The pagination filter.
+
+
+
+
+
+searchFilter
+SearchFilter
+
+
+The search filter.
+
+
+
+
+
+
+### SubscriberFilter
+
+Filters the subscriber results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiIds
+[String]
+
+
+The list of API IDs that need to be searched with the given search text. Note that it is not possible to define API
+IDs without a search text in the search filter.
+
+
+
+
+
+searchText
+String!
+
+
+Text which needs to be searched among the results. It is required to specify a value for this parameter.
+
+
+
+
+
+
+### SuccessAPIUsageByAppFilter
+
+Filters successful API usage by application results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+
+apiIds
+[String]
+
+
+The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
+
+
+
+
+
+
+### TenantDataFilter
+
+Filters results by the tenant.
+
+
+
+
+
+Field
+Type
+Description
+
+
+apiIds
+[String]
+
+
+The list of API IDs by which the results need to be filtered.
+
+
+
+
+
+tenantDomains
+[String]
+
+
+The tenant domain name by which the results need to be filtered.
+
+
+
+
+
+
+### TimeFilter
+
+Filters results by the provided date range.
+
+
+
+
+
+Field
+Type
+Description
+
+
+orgId
+String!
+
+
+The ID of the organization by which the results need to be filtered. It is required to specify a value for this
+parameter.
+
+
+
+
+envId
+String
+
+
+The ID of the environment by which the results need to be filtered. It is required to specify a value for this
+parameter.
+
+
+
+
+
+environmentIds
+[String]
+
+
+The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter.
+
+
+
+
+
+
+### TopAPIsByAlertCountFilter
+
+Filters the top APIs by alert count results.
+
+
+
+
+
+Field
+Type
+Description
+
+
+from
+String!
+
+
+The start date of the time range. The date specified here must be a date earlier than the date specified via the
+
+to parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is
+required to specify a value for this parameter.
+e.g., '2021-08-16T12:00:00.000+05:30'.
+
+
+
+
+to
+String!
+
+
+The end date of the time range. The date specified here must be a date later than the date specified via the
+from
+parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is
+required to specify a value for this parameter.
+e.g., '2021-08-16T12:30:00.000+05:30'.
+
+
+
+
+
+## Enums
+
+### EnvironmentType
+
+Represents an error type.
+
+
+
+
+
+Field
+Type
+Description
+
+
+paginationFilter
+PaginationFilter
+
+
+The pagination filter.
+
+
+
+
+
+searchFilter
+SearchFilter
+
+
+The search filter.
+
+
+
+
+
+
+### ErrorCodeType
+
+Represents an error code type.
+
+Value
+Description
+
+
+
+
+CHOREO
+
+
+The Choreo environments.
+
+
+
+
+CHOREO_PRIVATE
+
+
+The private data-plane Choreo environments.
+
+
+
+
+
+ON_PREM
+
+
+The On-Premise environments.
+
+
+
+
+
+
+### ErrorType
+
+Represents an error type.
+
+Value
+Description
+
+
+
+
+_4XX
+
+
+The client-side errors.
+
+
+
+
+
+_5XX
+
+
+The server-side errors.
+
+
+
+
+
+
+### GroupByField
+
+Represents an Value
+Description
+
+
+
+
+PROXY
+
+
+The proxy-related errors.
+
+
+
+
+
+TARGET
+
+
+The target-related errors.
+
+
+groupByField used in CustomReports.
+
+
+
+
+
+### Metric
+
+Represents a metric used in Value
+Description
+
+
+
+
+API_NAME
+
+
+The API name.
+
+
+
+
+API_VERSION
+
+
+The API version.
+
+
+
+
+API_RESOURCE_TEMPLATE
+
+
+The API resource template.
+
+
+
+
+API_METHOD
+
+
+The API method.
+
+
+
+
+API_CREATOR
+
+
+The API creator.
+
+
+
+
+APPLICATION_NAME
+
+
+The name of the application.
+
+
+
+
+APPLICATION_OWNER
+
+
+The owner of the application.
+
+
+
+
+DESTINATION
+
+
+The destination.
+
+
+
+
+USER_AGENT
+
+
+The user Agent.
+
+
+
+
+PLATFORM
+
+
+The platform.
+
+
+
+
+
+TARGET_RESPONSE_CODE
+
+
+The target response code.
+
+
+CustomReports.
+
+
+
+
+
+## Scalars
+
+### Boolean
+
+The Value
+Description
+
+
+
+
+HIT_COUNT
+
+
+The number of API calls.
+
+
+
+
+RESPONSE_CACHE_HIT
+
+
+The number of API calls that used the response cache.
+
+
+
+
+REQUEST_MEDIATION_LATENCY
+
+
+The request mediation latency.
+
+
+
+
+RESPONSE_MEDIATION_LATENCY
+
+
+The response mediation latency.
+
+
+
+
+BACKEND_LATENCY
+
+
+The backend latency.
+
+
+
+
+TOTAL_LATENCY
+
+
+The total latency.
+
+
+
+
+API_ERRORS
+
+
+The number of hits for which API errors are returned.
+
+
+
+
+
+TARGET_ERRORS
+
+
+The number of hits for which target errors are returned.
+
+
+Boolean scalar type represents true or false.
+
+### Float
+
+The Float scalar type represents signed double-precision fractional values as specified by [IEEE 754](https://en.wikipedia.org/wiki/IEEE_floating_point).
+
+### ID
+
+The ID scalar type represents a unique identifier, often used to re-fetch an object or as the key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value is accepted as an ID.
+
+### Int
+
+The Int scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.
+
+### String
+
+The String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
+
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/asset-manifest.json
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/favicon.ico
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/index.html
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/index.html
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/index.html
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
similarity index 92%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
index 5ece3345f7..c0d9cc2404 100644
--- a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
+++ b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/insight.config.js
@@ -16,7 +16,7 @@ window.__RUNTIME_CONFIG__ = {
grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange',
subject_token_type: 'urn:ietf:params:oauth:token-type:jwt',
requested_token_type: 'urn:ietf:params:oauth:token-type:jwt',
- scope: 'apim:admin'
+ scope: 'apim:admin apim:api_view apim:api_manage apim:api_import_export apim:api_list_view'
}
},
INSIGHTS_API_URL: 'https://choreocontrolplane.choreo.dev/93tu/insights/1.0.0/query-api',
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/manifest.json
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/2.dff3c244.chunk.css.map
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/css/main.dd389ba7.chunk.css.map
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.LICENSE.txt
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/2.e5757962.chunk.js.map
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/main.78fb288a.chunk.js.map
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/js/runtime-main.8245b2d9.js.map
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.1b0f0f29.eot
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2 b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.703ca0a7.woff2
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.9cf9669b.ttf
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-bold.fb7355ad.woff
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2 b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.18a9997c.woff2
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.721edb3d.ttf
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.8feb26bf.eot
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-medium.9eb8c454.woff
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.34195eed.woff
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.4e0de531.ttf
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2 b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.ac841c91.woff2
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/gilmer-regular.dadefd19.eot
diff --git a/en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg b/en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
similarity index 100%
rename from en/site/monitoring-and-insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
rename to en/pe-docs/docs/insights/work-with-choreo-insights-api/graphiql-explorer/static/media/logout.ab831324.svg
diff --git a/en/pe-docs/docs/k8s-operations/containers/configure-container-resources-commands-and-arguments.md b/en/pe-docs/docs/k8s-operations/containers/configure-container-resources-commands-and-arguments.md
new file mode 100644
index 0000000000..6db1f8155d
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/containers/configure-container-resources-commands-and-arguments.md
@@ -0,0 +1,72 @@
+# Configure Container Resources, Commands, and Arguments
+
+In Choreo, you can view detailed information about the container that comprises a component, such as its image tag, the corresponding commit ID, any imposed resource usage limits, and so on.
+
+Each component in Choreo is limited to a single main container.
+
+{.cInlineImage-full}
+
+!!! info "Resource Limits"
+ Resource limits ensure that a single component does not take up more resources than it requires, which can affect other workloads on the data plane. If a process exceeds the allocated memory limit, the corresponding container will be forcefully shut down and restarted. If the process exceeds the allocated CPU limit, it gets throttled and can result in significant latencies in compute and I/O operations.
+
+Choreo allows you to edit the default container configuration depending on your requirement.
+
+## Update container configurations
+
+Follow these steps to update container configurations:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Containers**.
+4. On the **Containers** page, click **Edit** to update the corresponding container configuration.
+5. Apply the necessary changes and click **Save**.
+
+ {.cInlineImage-full}
+
+The following topics walk you through the container configuration changes you can apply.
+
+### Update resource requests and limits
+
+!!! info "Note"
+ The capability to update resource requests and limits is only available in paid pricing plans.
+
+To update resource requests and limits, move the corresponding slider to a required position. A resource request cannot be less than its corresponding limit.
+
+
+### Set the image pull policy
+
+You can select one of the following options as the image pull policy.
+
+- **Always**: The image is always pulled from the container registry, even if a matching tag is already present in the data plane.
+- **If Not Present** - The image is pulled from the container registry only if a matching image is not present in the data plane.
+
+ !!! tip
+
+ The recommended option is **If Not Present**.
+
+
+### Specify container ports
+
+You can specify appropriate values for the **Container Port** and **Service Port**. The **Service Port** is the port exposed outside of the container to your project-scoped endpoint. If you do not know the value to specify as the **Service Port**, specify the **Container Port** value in both fields.
+
+!!! tip
+
+ You do not need to configure port values manually for Ballerina components. The capability to edit port values is primarily for containerized/Dockerfile-based components.
+
+
+You can also select an appropriate **Protocol**.
+
+### Define a command and arguments for the container
+
+You can define a command and arguments for a container when you want to provide or override the `ENTRYPOINT` of a container. For example, in a scenario where you want to run legacy or third-party applications, you would want to provide or override the `ENTRYPOINT` of a container.
+
+{.cInlineImage-half}
+
+When you define a command and arguments,
+
+- It specifies the `ENTRYPOINT` array and it is not executed within a shell.
+- Variable references `$(VAR_NAME)` are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged.
+- `$$` are reduced to `$`, which allows escaping the `$(VAR_NAME)` syntax. This means that `"$$(VAR_NAME)"` produces the string literal `"$(VAR_NAME)"`.
+- Escaped references are never expanded, regardless of whether the variable exists or not.
+
+The `ENTRYPOINT` of the container image is used if you do not define a command and arguments for the container.
diff --git a/en/pe-docs/docs/k8s-operations/manage-configurations-and-secrets.md b/en/pe-docs/docs/k8s-operations/manage-configurations-and-secrets.md
new file mode 100644
index 0000000000..0c8dea6951
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/manage-configurations-and-secrets.md
@@ -0,0 +1,110 @@
+# Manage Configurations and Secrets
+
+Choreo allows you to easily manage and version your component's configurations and secrets as **file mounts** or **environment variables**.
+
+!!! info "Note"
+ All configurations and secrets applied to a Choreo component are stored in an encrypted secret vault in the cloud data plane, which is managed by WSO2.
+ If you are on a private data plane, the configurations and secrets are stored in an Azure key vault or AWS secret manager attached to your data plane in your cloud environment.
+
+## The difference between configurations and secrets
+
+Choreo considers all configurations and secrets to be sensitive content when storing them, but gives you the option to choose between secret or configuration when you create a file mount or an environment variable.
+
+- **Secrets** are write-only. Once you create a secret, you cannot see or retrieve its content via the Choreo Console. However, you can overwrite the existing content at any time.
+- **Configurations** can be read and updated via the Choreo Console after you create them.
+
+ !!!info "Note"
+
+ If you want to include sensitive data such as database passwords, cloud credentials, service accounts, and so on, the recommended approach is to use a secret instead of a configuration.
+
+## Apply a file mount to your container
+
+Follow these steps to apply a file mount to a component you have created:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Configs & Secrets**.
+4. Click **+ Create**.
+5. In the **Create a Config or Secret** pane, click **File Mount**.
+6. If you want to create the file mount as a secret, select **Mark as a Secret**. Otherwise, proceed to the next step.
+
+ !!!info "Note"
+
+ If you create the file mount as a secret, you will not be able to read the file content after you create the file mount.
+
+7. In the **Display Name** field, specify a name for the file mount.
+
+ !!!tip
+
+ The display name does not affect the file mount or its content. It is only a reference to identify the configuration or secret you create.
+
+8. In the **File Mount Path** field, specify where to mount the file inside the container. Use an absolute file path with the file name and extension if applicable.
+
+ !!!tip
+
+ The file name in the mount path does not need to match the configuration name or the name of the file you upload.
+
+9. Upload a configuration file or copy and paste the configuration content into the editor.
+
+10. Click **Create**.
+
+ !!!info "Note"
+
+ Configurations and secrets are applied immediately to your environment on creation. To ensure that the container reflects the new content, your existing running replicas undergo a rolling restart.
+
+## Apply environment variables to your container
+
+Follow these steps to apply environment variables to a component you have created:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Configs & Secrets**.
+4. Click **+ Create**.
+5. In the **Create a Config or Secret** pane, click **Environment Variables**.
+6. If you want to create the environment variable values as secrets, select **Mark as a Secret**. Otherwise, proceed to the next step.
+
+ !!!info "Note"
+
+ If you create environment variables as secrets, you will not be able to read the values you set for the environment variables after you create them.
+
+7. In the **Display Name** field, specify a name to identify the configuration or secret.
+
+ !!!tip
+
+ The display name you specify does not affect the environment variables you set. It is only a reference to identify the configuration or secret you create.
+
+8. Under **Add Environment Variables**, specify the necessary environment variables as key-value pairs. You can click **Add Item** to add any number of environment variables.
+
+9. Click **Create**.
+
+## Update an existing configuration or secret
+
+Follow these steps to update a configuration or secret you have defined:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Configs & Secrets**.
+4. Click the edit icon corresponding to the configuration or secret you want to update.
+5. Apply the necessary changes and click **Save**.
+
+## Delete an existing configuration or secret
+
+Follow these steps to delete a configuration or secret you have defined:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Configs & Secrets**.
+4. Click the delete icon corresponding to the configuration or secret you want to delete.
+5. Enter the name of the configuration or secret to confirm deletion.
+6. Click **Delete**.
+
+## Manage Ballerina configurables
+
+Choreo manages the [Ballerina configurables](https://ballerina.io/learn/by-example/configurable-variables/) for the Ballerina components you create.
+
+When you deploy or promote a Ballerina application, you can modify the Ballerina configurables via the **Deploy** page.
+
+!!!tip
+
+ You can use configurables instead of environment variables to add file mounts to a Ballerina component.
+ Environment variables are primarily for components written in other languages.
diff --git a/en/pe-docs/docs/k8s-operations/runtime/view-runtime-details.md b/en/pe-docs/docs/k8s-operations/runtime/view-runtime-details.md
new file mode 100644
index 0000000000..c7ae182b2b
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/runtime/view-runtime-details.md
@@ -0,0 +1,59 @@
+# View Runtime Details
+
+In Choreo, you can view details about running replicas of a component in a specific environment (i.e., Development or Production).
+
+To view the runtime details of a component, follow the steps given below:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and the relevant **Component**.
+3. In the left navigation menu, click **K8s Configurations** and then click **Runtime**. This opens the **Runtime** page populated with data retrieved from the underlying Choreo data plane.
+
+{.cInlineImage-full}
+
+The runtime details you can see here are analogous to a _zoomed-in_ view of a specific environment on the **Deploy** page.
+
+The following topics walk you through the specific details you can view and actions you can perform via the **Runtime** page.
+
+## Redeploy a release
+
+On the **Runtime** page, you can click **Redeploy Release** to immediately redeploy all resources, including configurations and secrets, to a specific environment. This triggers a rolling update to sync all the latest changes to the data plane.
+
+!!! info "What is a release?"
+ A release in Choreo uniquely identifies an underlying deployment of a component to an environment for a given version. For example, if you deploy a component to two environments across two versions, the component will have four active releases.
+
+The capability to redeploy a release also allows you to quickly restart all the running replicas of a component in a specific environment.
+
+## View running instances
+
+The running instances you see on the **Runtime** page provide insights into the active replicas of your component in the selected environment.
+
+- You can view details of each active replica and its associated real-time CPU and memory usage, status, restarts, and the time of the last activity.
+- If you want to see the real-time logs and information on conditions and events of a replica, click the menu icon of the replica and then click **Real-time Logs** or **Conditions & Events** depending on what you need to view. These options provide insights that help to diagnose issues in deployments.
+
+ {.cInlineImage-full}
+
+ !!! info "Note"
+ - All metrics such as the total and replica-level CPU and memory usage displayed on the **Runtime** page are real-time data and are instantaneous representations of a component's current state.
+ - You can take a look at the observability metrics of a component to see historical data and usage trends.
+### Observe real-time container logs
+
+Unlike the logs available in the **Observability Metrics** of a component, these logs are fetched in real-time from the data plane and are not historical. Therefore, you can only see logs of active containers and the last shutdown container.
+
+{.cInlineImage-full}
+
+- **Display Previous Logs:** Enable to retrieve logs from the last shutdown/crashed/restarted container of an instance.
+- **Since Seconds**: Specify the duration in seconds to fetch corresponding logs.
+- **Filter Logs**: Enable to filter and displays matching log lines. This is a fuzzy string search.
+
+### View container conditions and events
+
+Conditions and events provide information necessary to troubleshoot failing deployments.
+
+{.cInlineImage-full}
+
+If a component is not behaving as expected and you cannot detect any issues via the application logs, these events can provide necessary debugging information, such as the following:
+
+- Failing health checks (liveness and readiness probes).
+- Missing or invalid configuration/secret mounts.
+- Missing or invalid storage volume mounts.
+- Scheduling issues in the underlying data plane.
diff --git a/en/pe-docs/docs/k8s-operations/scaling/autoscale-component-replicas.md b/en/pe-docs/docs/k8s-operations/scaling/autoscale-component-replicas.md
new file mode 100644
index 0000000000..41357dd2e9
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/scaling/autoscale-component-replicas.md
@@ -0,0 +1,33 @@
+# Autoscale Component Replicas
+
+Choreo allows you to automatically scale your component replicas up or down in number based on resource consumption to ensure high availability.
+
+!!! info "Note"
+ Autoscaling capabilities are only available in paid plans for private data plane organizations.
+ In the free tier, components run in a single-replica, low-availability mode.
+
+{.cInlineImage-full}
+
+Follow these steps to configure autoscaling for a component:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component** for which you want to configure autoscaling.
+3. In the left navigation menu, click **K8s Operations** and then click **Scaling**.
+4. On the **Scaling** page, you can change the scaling parameters.
+
+The following parameters allow you to scale component replicas:
+
+- **Min replicas**: The minimum number of replicas to run at any given time. It is recommended to keep the value at a minimum of `2`.
+- **Max replicas**: The maximum number of replicas to scale up to. In the cloud data plane, this is restricted to a maximum of `5`. There is no restriction on the value in private data planes.
+- **CPU Threshold**: The average CPU utilization across all running replicas. If the CPU utilization across all active instances reaches the threshold, the number of active replicas automatically scales up until the average CPU utilization falls below the threshold.
+- **Memory Threshold**: The average memory usage across all running replicas. Like the **CPU Threshold**, if all active instances reach the memory threshold, the number of active replicas automatically scales up until the average memory usage falls below the threshold.
+
+!!! tip
+ If you update a scaling parameter, it may not immediately reflect in the Choreo Console because the change can take some time to propagate.
+
+!!! info "Run a fixed number of replicas"
+ If you want to run exactly `3` replicas for a component, you must set the minimum and maximum replicas to `3`.
+
+!!! warning "Scale to zero"
+ - Although it is possible to set the minimum number of replicas to `0`, your component does not scale to zero automatically during low usage. It can only go down to `1` replica.
+ - Setting both the minimum and maximum replicas to `0` suspends the deployment.
diff --git a/en/pe-docs/docs/k8s-operations/scaling/autoscale-components-with-scale-to-zero.md b/en/pe-docs/docs/k8s-operations/scaling/autoscale-components-with-scale-to-zero.md
new file mode 100644
index 0000000000..f59fb70405
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/scaling/autoscale-components-with-scale-to-zero.md
@@ -0,0 +1,73 @@
+# Autoscale Components with Scale-to-Zero
+
+Choreo provides the scale-to-zero capability for HTTP applications you deploy in the data plane. This lets you run your components in a serverless mode.
+
+Scale to zero is very useful in lower environments, where you can significantly reduce infrastructure costs by scaling down idle workloads. In production environments, you can also use scale-to-zero capability if your application's behavior aligns with this feature behavior. In the paid tier, if you want to run your application with more guaranteed high availability, it is recommended to choose HPA (Horizontal Pod Autoscaler) scaling method and configure a minimum replica count of 2 or higher.
+
+## How Scale to Zero works in Choreo
+
+!!! info
+ For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default.
+
+When Scale to Zero is enabled, your apps will automatically scale down to zero unless they receive HTTP traffic. When the application receives an HTTP request, your workload quickly scales up from zero to handle the request. When a new request is received by the deployment, the deployment will scale up to one replica and serve the request. When the deployment remains idle for a set period (approximately 5 minutes), it will automatically scale back to zero until a new request is received.
+
+When Scale to Zero is enabled, you can set the maximum number of replicas for deployments with this capability. Choreo dynamically scales deployments up to meet high HTTP traffic demand, up to the specified number of replicas. If the pending requests surpass the defined threshold under **Number of pending requests to spawn a new pod**, Choreo automatically adds a new replica to handle the increased load.
+
+{.cInlineImage-full}
+
+## Enable scale to zero
+
+For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default. When deploying or promoting the component, the deployment will automatically scale-to-zero.
+Upon the next request to the deployed service, a replica will be created to serve the request.
+
+!!! note
+ - For the services which contain at least one endpoint with the network visibility as **Project**, Choreo will not automatically scale-to-zero those components when you deploy or promote them.
+ - HTTP services that run on a port other than the below list of ports will not automatically scale-to-zero your component when deploying or promoting: 5000, 6000, 7000, 8000, 9000, 7070 to 7079, 8080 to 8089, and 9090 to 9099 or 8290.
+
+
+To enable scale-to-zero for service components created before February 23, 2024, follow the steps given below:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the **Component Listing** pane, click on the component you want to scale-to-zero.
+3. Make sure the component is deployed to an environment and is ready to receive traffic.
+4. In the left navigation menu, click **K8s Operations** and then click **Scaling**.
+
+ - **If you are a free user**, you will see a view similar to the one below. You can click the **scale-to-zero** card to enable scale-to-zero for your component.
+
+ {.cInlineImage-full}
+
+ - **If you are a paid user or you are running your applications in your own private data plane**, you will see a view similar to the one below. You can click the **scale-to-zero** card to enable scale-to-zero for your component.
+
+ {.cInlineImage-full}
+
+ !!! note
+ The scale-to-zero service should start within 60 seconds. If it doesn’t, the gateway will timeout the request.
+
+You can independently scale Choreo components in both the **Development** and **Production** environments. The deployment card indicates the scaling status of each environment. To configure the scale-to-zero feature for a specific environment, click on the **scale-to-zero** link, which redirects to the **K8s Operations** → **Scaling** page.
+
+{.cInlineImage-full}
+
+When you turn on the scale-to-zero for your application, the minimum replicas for your app will be set to zero. However, you can still select an appropriate maximum number of replicas.
+
+## Limitations
+
+- The scale-to-zero feature currently exclusively supports web applications and HTTP services. TCP and HTTPS services are not supported to be scaled to zero.
+- To scale to zero, your HTTP service must run on one of the specified ports: 5000, 6000, 7000, 8000, 9000, 7070 to 7079, 8080 to 8089, and 9090 to 9099 or 8290. If you have an endpoint in your component running in any other port, your component will not automatically scale-to-zero when deploying or promoting. Also, if you try to switch to the “scale-to-zero” option in the “Devops” → “Scaling” view, it will fail.
+- Scheduled tasks and manually triggered components cannot connect to a service on a project scope if scale-to-zero is enabled. Attempting to do so results in the following error:
+
+ `Host not found, not forwarding request.`
+
+ To allow a task-type component to invoke a project-level service, set it to HPA mode if you are on a paid plan, or to no scaling if you are on the Developer plan.
+
+## Architecture
+
+When your Choreo application scales down to zero, an intermediary proxy service intercepts incoming requests. If a request is directed at your application, this service initiates a scale-up. Requests are held in the proxy's queue until your application becomes active. After scaling up, the proxy forwards the queued requests to your application.
+
+If your application remains without HTTP traffic for an extended period (default idle time is 5 minutes), it will be scaled down to zero until more HTTP requests arrive. Conversely, if there's a surge in HTTP traffic to your scaled-up application, Choreo will further increase its scale to manage the demand. Choreo considers adding additional replicas if the number of queued requests surpasses the 'Target Pending Requests' threshold, which is set to 100 by default. You can adjust this threshold in the user interface.
+
+!!! note
+ The initial request after a long period of inactivity experiences a delay because the application must first scale up from zero. If your API operates in a service-chain sequence (e.g., service-1 activates service-2, which in turn calls service-3), this waiting time may extend further. If your application or its chain takes a considerable time to scale up, be aware that the first request might face a timeout.
+
+## Troubleshooting
+
+When Choreo enables scale-to-zero by default, it will configure the readiness probe with some default values. However, in some cases, you may observe that your first request responds with a 503 status code. To overcome these behaviors, fine-tune the readiness probe in the **DevOps** → **Health Checks** view to match your application's needs.
diff --git a/en/pe-docs/docs/k8s-operations/set-up-health-checks.md b/en/pe-docs/docs/k8s-operations/set-up-health-checks.md
new file mode 100644
index 0000000000..fe29926e3e
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/set-up-health-checks.md
@@ -0,0 +1,66 @@
+# Set Up Health Checks
+
+Health checks ensure that a running container is always healthy and ready to serve traffic.
+
+## Liveness probes
+
+Liveness probes run periodically on your container and restart if the probe fails.
+This allows the container to self-heal in scenarios where the application may have crashed or become unresponsive.
+
+## Readiness probes
+
+Similar to liveness probes, readiness probes run periodically throughout the lifecycle of a container.
+However, unlike liveness probes, these probes do not restart the container if the probe fails. Instead, they stop the container from receiving network traffic.
+
+!!! warning "Readiness probes on single replicas"
+ You must be mindful when you configure readiness probes on a single-running replica. If the readiness probe fails, your application stops receiving traffic because there is only one active replica. The application may not recover unless the liveness probe fails and restarts the container.
+
+## Probe types
+
+You can configure the following probe types for both readiness and liveness probes.
+
+### HTTP `GET` request
+
+This probe sends an HTTP `GET` request to a specified port and path on the container. A response status code in the range of 200-399 indicates that the request is a success.
+
+Depending on your requirement, you can configure additional HTTP headers.
+
+The recommended approach is to create a `/healthz` or `/health` endpoint in your service for this purpose.
+
+{.cInlineImage-half}
+
+### TCP connection probe
+
+This probe attempts to open a socket to the container on the specified port. If it cannot establish a TCP connection, it becomes a failure.
+
+### Execute a command
+
+This probe executes a given script inside the container. A non-zero return from the command is considered a failure.
+
+For example, `["cat", "/tmp/healthy"]` is considered healthy if the file `/tmp/healthy` is present. If not, it becomes a failure (non-zero exit code).
+In such scenarios, the application is responsible for writing and maintaining this file in the specified location.
+
+## Configure liveness and readiness probes
+
+Follow these steps to configure liveness and readiness probes on a container:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and the relevant **Component**.
+3. In the left navigation menu, click **K8s Configurations** and then click **Health Checks**.
+4. On the **Health Checks** page, click **+ Create**.
+5. Configure the liveness probe depending on your requirement.
+
+ {.cInlineImage-full}
+
+6. Click **Save**.
+7. Configure the readiness probe depending on your requirement.
+8. Click **Save**.
+
+ !!!info "Note"
+
+ You can update or remove a probe at any time.
+
+Follow these steps to ensure that the container works as expected:
+
+1. In the left navigation menu, click **K8s Configurations** under **DevOps**.
+2. On the **Runtime** page, check the details to confirm that the container works as expected. If the container does not start, check the **events and conditions** to see if any of the probes are causing the container to fail.
diff --git a/en/pe-docs/docs/k8s-operations/storage/configure-storage.md b/en/pe-docs/docs/k8s-operations/storage/configure-storage.md
new file mode 100644
index 0000000000..0d742bd270
--- /dev/null
+++ b/en/pe-docs/docs/k8s-operations/storage/configure-storage.md
@@ -0,0 +1,84 @@
+# Configure Storage
+
+All components you create in Choreo have a default **read-only file system**, which you cannot access or write to from your applications.
+
+Volume mounts allow you to create either temporary or persisted writable file system storage locations for your applications.
+
+## Volume mount types
+
+| Type | Description |
+| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Empty Directory (In-Memory) | A fast, temporary in-memory (tmpfs) storage location. This volume gets erased when you restart or remove the attached container. *Available on all data planes.* |
+| Empty Directory (Disk) | A temporary storage location on disk. This volume gets destroyed when you restart or remove the attached container. *Only available on private data planes.* |
+| Persistent Volume | A permanent storage location. This volume persists even if you restart or remove the attached container. *Only available on private data planes.* |
+
+!!! tip
+ All components have a writable location in the `/tmp` directory at the time of component creation. You can also configure other writable locations if required.
+
+
+## Create a temporary storage space for your container
+
+Empty directory (in-memory or on-disk) mounts allow you to create temporary file systems that your application can read from and write to. This option provides a convenient way to create a *scratch space* to write files temporarily before storing them in a more permanent storage location such as a cloud-backed storage bucket.
+For example, unzipping a file, temporarily writing results from a memory-intensive operation to disk, a temporary local cache, etc.
+However, it is important to note that these volumes destroy when you restart or update a container because the volumes are attached to the lifetime of a container.
+
+Follow these steps to create a temporary storage space for your container:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Storage**.
+4. Click **+ Create**.
+5. In the **Create a Volume Mount** pane, specify a name for the volume and select **Empty Directory (In-Memory)**.
+
+ {.cInlineImage-full}
+
+6. Click **Next**.
+
+ !!! warning "In-memory (tmpfs) storage uses up container memory"
+ Storage capacity for this type of volume will count against the container's memory limit.
+ Uncontrolled writes to this location may starve your application process of memory and can result in the container getting killed and restarted if the memory limits exceed.
+
+7. To add a mount location, specify a **Mount Path** and click **Add mount**.
+
+ !!!tip
+
+ - You can add multiple mount locations to a volume.
+ - Mount paths should be *absolute file paths* and will be available to your application to read/write from.
+
+ {.cInlineImage-full}
+
+8. Click **Create**. This applies the volume mount immediately to your container and triggers a rolling restart.
+
+## Create a persistent storage space for your container
+
+Follow these steps to create a persistent storage space for your container:
+
+!!! info "Note"
+
+ Persistent volume options are only available in private data plane organizations.
+
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and the relevant **Component**.
+3. In the left navigation menu, click **K8s Operations** and then click **Storage**.
+4. Click **+ Create**.
+5. In the **Create a Volume Mount** pane, specify a name for the volume and select **Persistent Volume**.
+6. Select a **Storage Class**.
+7. Move the **Storage Capacity** slider to set the required capacity.
+8. Select an appropriate **Access Mode**.
+
+ !!! tip "Check and specify an access mode supported by the storage class"
+ - You must check the cloud provider documentation to select an appropriate access mode that the storage class supports. Choreo does not verify whether the storage class supports the access mode you select.
+ - If the storage class does not support the access mode you select, it can result in a runtime mount error.
+
+ {.cInlineImage-full}
+
+9. Click **Next**.
+10. To add a mount location, specify a **Mount Path** and click **Add mount**.
+
+ !!!tip
+
+ - You can add multiple mount locations to a volume.
+ - Mount paths should be *absolute file paths* and will be available to your application to read/write from.
+
+11. Click **Create**. This applies the volume immediately to your container.
diff --git a/en/pe-docs/docs/observability/alerts/configure-alerts.md b/en/pe-docs/docs/observability/alerts/configure-alerts.md
new file mode 100644
index 0000000000..59e5e17ca2
--- /dev/null
+++ b/en/pe-docs/docs/observability/alerts/configure-alerts.md
@@ -0,0 +1,141 @@
+# Configure Alerts
+
+This section explains how you can configure alerts for your Choreo components. Setting up alerts allows you to proactively monitor your components ecosystem and take corrective measures when necessary.
+
+!!! tip
+ Setting up alerts in only available in the component level.
+
+## Alert Types
+
+Choreo supports the following types of alerts to help you monitor and manage your components effectively:
+
+- [Latency alerts](#latency-alerts)
+- [Traffic alerts](#traffic-alerts)
+- [Resource alerts](#resource-alerts)
+- [Log alerts](#log-alerts)
+- [Build failure alerts](#build-failure-alerts)
+- [Status code alerts](#status-code-alerts)
+
+### Latency Alerts
+
+Latency alerts notify you if the response latency of a component exceeds a predefined threshold in a given time period. This is useful for components that need to meet specific SLAs and for proactively identifying slow components.
+
+Configurable parameters
+
+| **Parameter** | **Description** |
+|---------------|---------------------------------------------------------------------------------|
+| Metric | 99th, 95th, 90th, or 50th percentile. |
+| Threshold | Latency in milliseconds (e.g.: 1800). |
+| Period | Duration the threshold must be exceeded (e.g.: 5 minutes). |
+
+### Traffic Alerts
+
+Traffic alerts notify you when the request count of a component exceeds a predefined threshold. This is useful for managing components with backend traffic limits or monetized backends that require proactive scaling based on incoming traffic.
+
+Configurable parameters
+
+| **Parameter** | **Description** |
+|---------------|---------------------------------------------------------------------------------|
+| Threshold | Requests per minute (e.g.: 200). |
+| Period | Monitoring window (e.g.: 5 minutes). |
+
+### Resource Alerts
+
+Resource alerts notify you when your component’s CPU or memory usage exceeds the defined thresholds. This ensures you can fix the resources allocations early to avoid performance issues or downtimes.
+
+Configurable parameters
+
+| **Parameter** | **Description** |
+|---------------|---------------------------------------------------------------------------------|
+| Metric | CPU or Memory. |
+| Threshold | **mCPU** for CPU and **MiB** for Memory(e.g.: 1000). |
+| Period | Duration the threshold must be exceeded (e.g.: 5 minutes). |
+
+!!! Tip
+ - **CPU**: mCPU (milliCPU) measures CPU usage in fractions of a core, where 1000m = 1 full core.
+ - **Memory**: MiB (Mebibyte) measures memory in binary units, where 1 MiB = 2^20^ bytes.
+
+### Log Alerts
+
+Log alerts trigger notifications when a specific phrase appears **a specific number of times** in your component logs within a defined Time window. This helps to identify recurring issues or critical errors quickly, enabling faster troubleshooting.
+
+Configurable parameters
+
+| **Parameter** | **Description** |
+|---------------|---------------------------------------------------------------------------------|
+| Search Phrase | Keyword or phrase to look for to trigger the alert (e.g.: failed). |
+| Count | Minimum number of occurrences to trigger the alert (e.g.: 10). |
+| Interval | Time window for counting occurrences (e.g.: 5 minutes). |
+
+### Build Failure Alerts
+
+Build failure alerts inform you if a build failure occurs for your component. This is essential for maintaining smooth development workflows.
+
+### Status Code Alerts
+
+Status code alert triggers when your component returns specific HTTP error(s) (e.g.: **403** Forbidden, **500** Internal Error). These alerts help to detect issues affecting your component’s availability.
+
+Configurable parameters
+
+| **Parameter** | **Description** |
+|---------------|---------------------------------------------------------------------------------|
+| Status Code | Error code or series (e.g.: 400:Bad Request). |
+| Count | Minimum number of occurrences (e.g.: 5). |
+| Interval | Time window (e.g.: 5 minutes). |
+
+!!! note
+ Status code alerts are only supported for API proxy component types.
+
+## Configure Alert
+
+Follow these steps to configure an alert:
+
+1. Navigate to the component you wish to configure alerts for.
+
+ !!! info
+ You need to have a scope of **Choreo DevOps** or **Choreo Platform Engineer** inorder to create Alerts.
+
+2. In the Choreo left menu, click **Observability** and then click **Alerts**.
+3. Click **Create Alert Rule** to create a new alert rule.
+
+ {.cInlineImage-full}
+
+4. Select the **[Alert Type](#alert-types)** you want to create.
+5. Select the **Environment** you want to create the alert for.
+6. Select the **Deployment Track** or **Version** as required for the component.
+7. Configure the remaining fields specific to your selected alert type.
+8. In the **Emails** field, specify the list of emails that should be notified when the alert is triggered.
+
+ !!! note
+ - When adding an email, enter the required email and press enter to add it.
+ - You can add a maximum of 5 email addresses per alert.
+
+9. You can configure additional parameters in **Advanced Configurations** dropdown as needed, which vary based on your alert type.
+10. The **Explanation window** provides a concise summary of the configured alert based on your alert configurations.
+11. Click **Create** to save and activate your alert rule.
+
+ !!! info
+ - You can configure a maximum of 10 alerts per component.
+
+12. Once successfully added, your alert will be listed in the **Configure Alerts** pane alongside any existing alerts for the component.
+13. Each alert can be **edited**, **removed** and **disabled** or **enabled** via this pane.
+
+ !!! note
+ when editing an alert, you can't edit the **Alert Type**, **Environment** and **Deployment Track**.
+
+## Alert History & Notifications
+
+### View Alert History
+
+You can check the past alerts that have triggered for your component when you click the **Alerts History** pane in Choreo Alerts. You can filter the alert history by **Alert Type**, **Environment**, **Deployment Track** or **Version** and **Time Range**.
+
+!!! note
+ When filtering, **API Proxy components** show a **Version** filter and other components display a **Deployment Track** filter, based on their monitoring context.
+
+You can click on an alert to expand it and see more details of the triggered alert.
+
+### Email Notifications
+
+When an alert is triggered, **recipients** added to the alert rule receive an email with **alert details** including a direct **Alert View link** to Choreo console.
+
+{.cInlineImage-full}
diff --git a/en/pe-docs/docs/observability/audit-logs.md b/en/pe-docs/docs/observability/audit-logs.md
new file mode 100644
index 0000000000..32fd543580
--- /dev/null
+++ b/en/pe-docs/docs/observability/audit-logs.md
@@ -0,0 +1,64 @@
+# Audit Logs in Choreo
+
+Audit logs, also called audit trails, enhance security, ensure compliance, provide operational insights, and help manage risks.
+
+In Choreo, an audit log records organization-level user-specific operations performed via the Choreo Console. It also captures the timestamp and the outcome of the action.
+
+As of now, Choreo captures the following user-specific operations as audit logs:
+
+- Project creation, update, and deletion.
+- Component creation, update, and deletion.
+- Component promotion initiation.
+- Component version creation.
+- Component deployment, redeployment, and undeployment initiation for all components other than REST API Proxy components.
+- Component API access mode update.
+- Enabling and disabling component auto-deployment on commit.
+- Component build configuration update.
+- Component endpoint creation, update, and deletion.
+- Organization user management.
+- On-premises key management.
+- Project-level configuration management.
+
+In Choreo, organization administrators and platform engineers are allowed to view audit logs by default. If other members need to access organization-specific audit logs, the administrator or the platform engineer can create a role with the relevant permission and assign it to members. For step-by-step instructions on how to create and assign a role with relevant permission, see [Manage audit log access](#manage-audit-log-access).
+
+To view audit logs, follow these steps:
+
+1. Sign in to [Choreo](https://console.choreo.dev/).
+2. In the top navigation menu, click the **Organization** list and select your organization.
+
+ !!! tip
+ As of now, you can only view organization-level audit logs.
+
+3. In the left navigation menu, click **Observability** and then click **Audit Logs**. This displays audit logs for the past 24 hours by default.
+
+ To view audit logs based on a specific time range and other requirements, you can apply the necessary filter criteria.
+
+ 
+
+### Audit log retention
+
+Choreo retains audit logs for one year and archives them for an additional year. Therefore, the total retention period for audit logs is two years.
+
+### Manage audit log access
+
+Follow the steps given below to create a role with audit log access permission and assign it to organization members who need access to audit logs:
+
+!!! info "Note"
+ You must be the organization administrator or a platform engineer to perform this action.
+
+#### Step 1: Create a role with audit log access permission
+
+1. In the top navigation menu, click the **Organization** list and select your organization.
+2. In the left navigation menu, click **User Management** and then click **Roles**.
+3. On the **Roles** page, click **+ Create Role**.
+4. Enter a name and description for the role.
+5. In the **Permissions** section, select **LOG-MANAGEMENT** to grant permission to view audit logs.
+6. Click **Create**.
+
+#### Step 2: Assign the created role to a group and organization member
+1. In the left navigation menu, click **User Management** and then click **Groups**.
+2. On the **Groups** page, click **+ Create Group**.
+3. Enter a name and description for the group and then click **Create**.
+4. Locate and click on the newly created group in the list.
+5. Navigate to the Roles tab, click **+ Add Role**, and choose the role you created in [Step 1](#step-1-create-a-role-with-audit-log-access-permission).
+6. In the Users tab, click **+ Add User** and select the users to assign the role to.
diff --git a/en/pe-docs/docs/observability/private-data-plane-logs.md b/en/pe-docs/docs/observability/private-data-plane-logs.md
new file mode 100644
index 0000000000..f9fc3bc4a3
--- /dev/null
+++ b/en/pe-docs/docs/observability/private-data-plane-logs.md
@@ -0,0 +1,70 @@
+# Private Data Plane (PDP) Logs
+
+Choreo offers the capability to access runtime logs through its console. However, in cases where viewing logs for your PDP is not supported by Choreo yet, you can still view the runtime logs of your components via the log analyzing solution provided by your cloud vendor as a workaround.
+
+## Prerequisites
+
+Before you try out this guide, complete the following:
+
+1. In the Choreo Console top navigation menu, select the **Organization**, then the **Project** and finally the relevant **Component** for which the incident was reported.
+2. On the left navigation menu, click **K8s Operations** and then click on **Runtime**.
+3. Copy the `Release ID` and the `Namespace`. Save it for later.
+
+## View Private Data Plane (PDP) logs with Azure Log Analytics
+
+You can view your PDP logs with Azure Log Analytics by following the steps below:
+
+1. Go to https://portal.azure.com/.
+2. Follow the [Azure Log Analytics Tutorial](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-tutorial#open-log-analytics) and open log analytics of your relative log analytics workspace.
+3. Copy and paste the query below into the query editor.
+4. Replace the `
|
+| Total request duration |
|
+| Maximum connection duration (WebSocket APIs) | 15 minutes |
+| Connection idle timeout (WebSocket APIs) | 5 minutes |
+| Size for API definition (OpenAPI document)| 10 Mb |
+| Number of APIs for PDP | 1000 API deployments |
+| Number of APIs per organization (free tier) | 5 APIs for free users |
+| Number of Developer Portal applications per organization (free tier) | 10 applications for free users |
+
+
+## Choreo cloud data plane limits
+
+Below are key limitations when working with web applications in the Choreo cloud data plane:
+
+| Resource | Limit |
+|------------------------------------|---------------------------------------------------------------------------------------------|
+| Request size limit (including headers, cookies, and payloads) | 256 KB |
+| Response body size limit | 20 MB |
+| Number of open ports permitted per web application| 1
While it is possible to have multiple ports open for project-level communication within a data plane, incoming internet traffic can only be directed to a single port. This contrasts with Service-type components, which allow for multiple endpoints.|
diff --git a/en/pe-docs/docs/references/choreo-platform-services-billing-and-upgrades.md b/en/pe-docs/docs/references/choreo-platform-services-billing-and-upgrades.md
new file mode 100644
index 0000000000..642397ec1a
--- /dev/null
+++ b/en/pe-docs/docs/references/choreo-platform-services-billing-and-upgrades.md
@@ -0,0 +1,12 @@
+# Choreo Platform Service Billing and Upgrades
+
+Choreo bills the platform services you create, such as databases, caches, or Kafka services, as part of your existing subscription. The cost depends on the service plan and the usage of each resource.
+
+## Platform service billing information
+
+- **Hourly billing**: Usage is billed based on the number of hours a resource is active. For example, if you create a database, cache, or Kafka service and remove it within the same month, you pay only for the hours it was active.
+- **Fixed pricing**: Pricing is based on the selected service plan. Choreo does not charge extra for network bandwidth usage.
+
+## Upgrade a service plan
+
+If you want to upgrade the service plan of a platform service you have created, contact [Choreo support](mailto:choreo-support@wso2.com).
diff --git a/en/pe-docs/docs/references/faq.md b/en/pe-docs/docs/references/faq.md
new file mode 100644
index 0000000000..c0246e1aee
--- /dev/null
+++ b/en/pe-docs/docs/references/faq.md
@@ -0,0 +1,620 @@
+# Frequently Asked Questions
+
+## General
+
+### Q: What is Choreo?
+Choreo is an internal developer platform designed to accelerate the creation of digital experiences. With Choreo, you can effortlessly build, deploy, monitor, and manage your cloud native applications. Our goal is to enhance developer productivity and enable innovation.
+
+### Q: What is an organization in Choreo?
+An organization is a logical grouping of users and their resources. It may represent a company, community, or a single user. Users can belong to multiple organizations, and each organization can have different roles assigned to its users to control access to Choreo features.
+
+### Q: What is a project in Choreo?
+A project is a logical grouping of related components to help you organize your work. Each project provides runtime isolation through namespaces when you deploy components.
+
+### Q: What is a component in Choreo?
+A component is a workload designed to run on Choreo. Examples of components include integrations, APIs, microservices, manual/scheduled jobs, web apps, and triggers.
+
+### Q: What is the difference between an internal and external API?
+In Choreo, you can publish an API as an internal or an external API. A user or an application can access an external API publicly over the internet, whereas an internal API is only accessible through other components within the same organization.
+
+### Q: What is a connector in Choreo Marketplace?
+A connector is a reusable Ballerina package that simplifies connecting to external or internal systems and APIs, such as Salesforce, SAP, GitHub, and Twilio. You can use the connectors available in the Choreo marketplace to implement your integration use cases. Connectors can be created and published by both WSO2 and Choreo users.
+
+### Q: What is a trigger in Choreo Marketplace?
+A trigger is a construct that enables users to receive known event payloads from external systems, facilitating event-driven programming.
+
+### Q: What is a sample/template in Choreo?
+A sample or template is a prebuilt Ballerina program that covers a popular integration use case or pattern. Examples include connecting Salesforce to Slack or implementing content-based routing.
+
+### Q: What are the support options in Choreo?
+You can find information about our support plans, including `free`, `basic`, and `enterprise` options at [https://wso2.com/choreo/customer-support/](https://wso2.com/choreo/customer-support/).
+
+### Q: How can I perform log monitoring or analytics for the Azure environment?
+If you have a log monitoring product or service, such as Azure Monitor, you can use it together with Choreo. Note: The log monitoring tool is not included in the infrastructure cost.
+
+### Q: What is the maximum request payload size supported by Choreo?
+Choreo allows a maximum request payload size of 50 MB.
+
+### Q: What source control software does Choreo support?
+Choreo now supports GitHub, Bitbucket and GitLab.
+
+### Q: Why don't I see the undeployed builds for my component in Choreo?
+You are allowed to build your component any number of times. However, Choreo has a limit on retaining undeployed builds. For users on the free-tier, Choreo will retain **only one** undeployed build. For those on any other tier, Choreo will retain the **latest five** undeployed builds.
+
+### Q: What is Ballerina?
+Ballerina is an open-source programming language designed for the cloud. It simplifies the process of using, combining, and creating network services. When you use Ballerina to write integrations in Choreo, you can save time and deliver 2-3x faster. To learn more, check out https://ballerina.io/.
+
+### Q: What is Asgardeo?
+Asgardeo is an identity provider (IdP) that allows developers to secure access for consumers, business partners, employees, and APIs. Asgardeo is Choreo’s default IDP. To learn more, visit https://wso2.com/asgardeo/.
+
+### Q: Why don’t I see the region selector on the project creation page?
+If you are a Choreo cloud data plane user, you can create projects in multiple regions only if you have a paid subscription in Choreo. Otherwise, your projects will be created in the same region you selected when onboarding the organization.
+
+If you are a private data plane user, there will be no region selector in project creation at all.
+
+### Q: As a Cloud Data Plane user, how can I create components in multiple data planes?
+When an organization admin onboards a new organization in Choreo, they can choose the preferred data plane. Choreo then sets the selected data plane as the default for the entire organization. Subsequently, users within the free tier of the cloud data plane can create components only in the set default data plane. If a free-tier user needs to create components in a different data plane, the user must get a paid subscription.
+
+## Security and data protection
+
+### Q: How is data managed in Choreo?
+Choreo manages data using WSO2 containers and Kubernetes clusters, which provide scalability, resilience, and security. Find out more [here](https://wso2.cachefly.net/wso2/sites/all/trust/wso2-public-cloud-data-protection-faq.pdf).
+
+### Q: What is the WSO2 Subprocessor list?
+This is a detailed list of all subprocessors used by WSO2, including their name, location, and purpose. This information is updated frequently to ensure compliance with data protection regulations and is found [here](https://wso2.cachefly.net/wso2/sites/all/trust/wso2-public-cloud-subprocessor-list.pdf).
+
+### Q: How do we secure WSO2 Private and Public Clouds?
+WSO2 uses a range of security controls and design patterns to protect against several threats, including internal attacks, software supply chain attacks, service and platform attacks, and more. For more details, see[Cloud Security Process](https://security.docs.wso2.com/en/latest/security-processes/cloud-security-process/).
+
+### Q: How can I connect a Choreo component with a protected third-party application?
+To connect a Choreo component with a third-party application, it is necessary to establish seamless communication between the component and the protected third-party application, especially when connecting to external databases like MySQL, MSSQL, PGSQL, Oracle DB, etc.
+To ensure this, the requests coming from the Choreo data plane must be allowed by adding the specific data plane IP ranges to your allowlist.
+
+- If your component is deployed in the Choreo US data plane, add the following IP range to your allowlist:
+ - 20.22.170.144/28
+
+- If your component is deployed in the Choreo EU data plane, add the following IP range to your allowlist:
+ - 20.166.183.112/28
+
+- If you are working on the [Cybertruck Challenge](https://wso2.com/cybertruck/), add the following IP range to your allowlist:
+ - 20.190.30.48/28
+
+## Data planes
+
+### Q: What is a Choreo control plane?
+The Choreo control plane is a centralized management component that oversees and coordinates the workloads deployed by customers. It provides a unified point of control and visibility for the organization, allowing administrators to manage, monitor, and orchestrate the organization’s resources efficiently.
+
+### Q: What is a data plane?
+A data plane in Choreo is a computing environment designed for running customer workloads. These environments are hosted in either a dedicated cloud infrastructure owned by the customer (private data planes) or on public cloud infrastructure owned by WSO2, also known as the Choreo data plane.
+
+### Q: Which regions support the Choreo data plane(CDP)?
+The Choreo data plane is currently supported in the US East 2 and North Europe. However, WSO2 is planning to add support for additional regions as needed.
+
+### Q: Which regions support private data planes(PDPs)?
+Private data planes can be deployed in any region where Azure and AWS are available and meet the requirements for PDPs.
+
+### Q: If I want to use my Azure AKS instances as the private data plane, what are the minimum requirements I should meet?
+We recommend using a minimum of two (2) workload nodes to ensure high availability.
+
+### Q: Are the Choreo control plane and data planes highly available? Are they running on multiple clusters?
+The Choreo control plane and data plane are designed for high availability using Azure components like AKS, MSSQL, ACR, KV, Service Bus, and so on, with a high availability of 99.99%, which allows at least three workload nodes. In the event of a node failure or upgrade, this setup provides reliable failover. WSO2 also has a backup and recovery strategy in place, including continuous restore drills. If you require AKS cluster-level redundancy, we can consider multiple zones. In this case, the cost will include an additional infrastructure cost.
+
+## Environments
+
+### Q: As a Choreo cloud data plane user, why can't I create environments?
+You can create environments only if you have a paid subscription in Choreo. It can be either Pay-as-you-Go (PAYG) or an Enterprise plan.
+
+### Q: I am a Pay-As-You-Go (PAYG) customer using the Choreo cloud data plane. How many environments can I create?
+You can create up to 5 environments at the organization level, including the existing Development & Production environments by default. If you have projects in both data planes (US & EU), there will be 4 environments already created in total, and you will only be allowed to create one additional environment either in the US or EU data plane.
+
+### Q: I am an Enterprise subscription customer using the Choreo private data plane. How many environments do I get?
+As an Enterprise subscription customer, the number of environments you can use is **not** limited. However, the more environments you use, the more resources you will consume in the data plane for the workload you deploy. This may result in higher infrastructure costs for the private data plane.
+
+### Q: As a Choreo cloud data plane user, why don’t I see both US & EU data planes in the data plane selector when creating an environment?
+You will see both US & EU data planes only if you have a paid subscription and have created projects in both US & EU data planes.
+
+### Q: I am a customer who use Choreo in a private data plane. How many environments can I create?
+Initially, you will receive the requested number of environments when establishing your private data plane. Subsequently, you can create additional environments as needed.
+
+## Billing and support
+
+### Q: Whom do I reach out to if I have a billing question?
+You can reach out to cloud-billing-support@wso2.com or create a support ticket via our support portal.
+
+### Q: What's a Developer plan?
+A Developer plan allows you to try out Choreo’s capabilities at no cost. It’s ideal for proof of concept (PoC) tasks or workloads with limited transactions. This plan allows you to experiment with up to 5 components and provides US$1,000/year of Choreo data plane (CDP) credits.
+
+### Q: How do I calculate the infrastructure costs?
+Calculating infrastructure costs depends on the type of workload you want to manage. Here are a few examples:
+
+- **Example 1**: Managing existing APIs as an API proxy with simple mediation; no additional infrastructure costs.
+- **Example 2**: Managing existing APIs as an API proxy with complex mediation and policies; Choreo will deploy 1 x container to handle these mediation and policies at approximately US$57.25 per month per API.
+- **Example 3**: Creating, deploying, and managing a new API or integration within Choreo; pay for 1 x component + infrastructure cost. Each container deployed will be approximately US$57.25 per month on the default configuration provided by Choreo. Additional resources will be charged based on the type of resource required.
+- **Example 4**: Creating, deploying, and managing a microservice; the same approach as example 3.
+
+### Q: What are the component limitations?
+
+- **Developer plan**: Allows up to a maximum of five free components and unlimited paid components.
+- **PAYG plan**: Allows unlimited paid components.
+- **Enterprise plan**: Allows unlimited paid components.
+
+### Q: How do I read the bill?
+Your bill will detail the number of components used, infrastructure consumed, support plans used, and any additional services you may have purchased. If you are unsure about any charges on your bill, reach out to choreo-support@wso2.com for clarification.
+
+### Q: Is support included in the Choreo Enterprise plan?
+The Choreo Enterprise plan does not automatically include support; however, you can purchase support plans in addition to the Enterprise plan at any time. Find out more at https://wso2.com/choreo/customer-support/.
+
+### Q: I am an Enterprise subscription customer who wants to use the Choreo private data plane. What costs will I incur in addition to the subscription and support plan?
+You can start by using a basic plan or contact us for an Enterprise support plan.
+
+### Q: I want to upgrade from PAYG to an Enterprise subscription. Will there be an outage during the upgrade?
+No, there are no outages when upgrading a plan.
+
+## Choreo CLI
+
+### Q: How do I uninstall the CLI?
+If you didn't download the binary directly, you can uninstall the CLI by deleting the `.choreo` directory in the
+home directory of your operating system.
+
+### Q: How do I update the CLI?
+You can update the CLI by running the following command:
+```sh
+curl -o- https://cli.choreo.dev/install.sh | bash
+```
+
+### Q: What are the supported component types in the CLI?
+The Choreo CLI currently supports the following component types:
+- Service
+- Web Application
+- Webhook
+- Scheduled Task
+- Manual Task
+
+### Q: How do I get help with a specific command in the CLI?
+You can get help with a specific command by running the following command:
+```sh
+choreo
+
+
+
+
+
diff --git a/en/pe-docs/docs/references/private-data-plane-management-models.md b/en/pe-docs/docs/references/private-data-plane-management-models.md
new file mode 100644
index 0000000000..8977083ada
--- /dev/null
+++ b/en/pe-docs/docs/references/private-data-plane-management-models.md
@@ -0,0 +1,497 @@
+# Private Data Plane Management Models
+
+Choreo supports various management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios. The following sections provide insights into WSO2's fully managed solutions and shared responsibility models, allowing you to make informed decisions regarding cloud-based operations and security.
+
+## WSO2 fully managed (infrastructure and PDP in WSO2 subscription) model
+
+WSO2 fully managed private data planes are supported only on Azure, AWS, and GCP cloud providers.
+
+
+
+
+
+ Component Type
+ Buildpack
+ Required Configurations
+
+
+ Service
+ Python
+
+
+
+
+
+
+ Node.js
+
+
+
+
+
+
+ Java
+
+
+
+
+
+
+ Go
+
+
+
+
+
+
+ PHP
+
+
+
+
+
+
+ Ruby
+
+
+
+
+
+
+ Docker
+
+
+
+
+
+
+ Ballerina
+
+
+
+
+
+
+ WSO2 MI
+
+
+
+
+
+
+ .Net
+
+
+
+
+
+
+ Webapp
+ Python
+
+
+
+
+
+
+ Node.js
+
+
+
+
+
+
+ Go
+
+
+
+
+
+
+ PHP
+
+
+
+
+
+
+ Ruby
+
+
+
+
+
+
+ .Net
+
+
+
+
+
+
+ Docker
+
+
+
+
+
+
+ Static website
+
+
+
+
+
+
+ React
+
+
+
+
+
+
+ Angular
+
+
+
+
+
+
+ Vue
+
+
+
+
+
+
+ Webhook
+ Python
+
+
+
+
+
+
+ Node.js
+
+
+
+
+
+
+ Java
+
+
+
+
+
+
+ Go
+
+
+
+
+
+
+ PHP
+
+
+
+
+
+
+ Ruby
+
+
+
+
+
+
+ Docker
+
+
+
+
+
+
+ Ballerina
+
+
+
+
+
+
+ WSO2 MI
+
+
+
+
+
+
+ Scheduled Task
+ Python
+
+
+
+
+
+
+ Node.js
+
+
+
+
+
+
+ Java
+
+
+
+
+
+
+ Go
+
+
+
+
+
+
+ .Net
+
+
+
+
+
+
+ PHP
+
+
+
+
+
+
+ Ruby
+
+
+
+
+
+
+ Docker
+
+
+
+
+
+
+ Ballerina
+
+
+
+
+
+
+ WSO2 MI
+
+
+
+
+
+
+ Manual Task
+ Python
+
+
+
+
+
+
+ Node.JS
+
+
+
+
+
+
+ Java
+
+
+
+
+
+
+ Go
+
+
+
+
+
+
+ .Net
+
+
+
+
+
+
+ PHP
+
+
+
+
+
+
+ Ruby
+
+
+
+
+
+
+ Docker
+
+
+
+
+
+
+ Ballerina
+
+
+
+
+
+
+
+WSO2 MI
+
+
+
+
+
+
+
+
+## WSO2 fully managed (infrastructure and PDP in customer subscription) model
+
+
+
+
+
+Task
+Task description
+Responsible party
+Accountable
+Consulted
+Informed
+
+
+Subscription prerequisites
+- Create subscriptions
+ - Check quota and service limits
+ - Run the Choreo compatibility prerequisite script
+WSO2
+WSO2
+Customer (If required)
+Customer (If required)
+
+
+Remote access for installation
+Provide owner access
+WSO2
+WSO2
+WSO2
+WSO2
+
+
+Network management
+- Obtain customers backend CIDR in case of VPN/peering
+ - Check end-to-end connectivity (primary and failover)
+WSO2/Customer
+WSO2/Customer
+Customer
+Customer
+
+
+Firewall rules/access control
+Set up firewall and required rules depending on the security tier
+WSO2
+WSO2
+Customer
+Customer
+
+
+Infrastructure provisioning
+- Provision Bastion
+ - Provision Kubernetes clusters
+WSO2
+WSO2
+-
+Customer(If required)
+
+
+Kubernetes cluster management
+- Manage Kubernetes versions
+ - Increase node pool size
+WSO2
+WSO2
+Customer
+Customer
+
+
+Infrastructure monitoring
+Set up alerts
+WSO2
+WSO2
+-
+Customer(If required)
+
+
+DNS management for Choreo system
+- Manage DNS infrastructure
+ - Manage SSL certificates for Choreo system components
+WSO2/Customer
+WSO2/Customer
+Customer
+Customer
+
+
+Choreo system components deployment
+Set up PDP agents via Helm
+WSO2
+WSO2
+-
+-
+
+
+Choreo system components management
+Upgrade/patch/debug versions
+WSO2
+WSO2
+-
+Customer(If required)
+
+
+Choreo system components monitoring
+- Set up continuous monitoring 24x7
+ - Provide monthly uptime reports
+WSO2
+WSO2
+-
+Customer
+
+
+Choreo system security monitoring
+If basic tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security (Image scanning, SAST)
+ - Manage security incidents
+ If standard tier/premium tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security
+ - Monitor runtime security alerts (Azure Defender)
+ - Monitor security incident and event management (SIEM) alerts
+ - Manage security incidents
+ - Adhere to compliance standards
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+
+
+Choreo application creation/deployment
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application management
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application monitoring
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
+Choreo application logs
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
+
+## Customer self-managed (WSO2 provides installation script and updates) model
+
+
+
+
+
+Task
+Task description
+Responsible party
+Accountable
+Consulted
+Informed
+
+
+Subscription prerequisites
+- Create subscriptions
+ - Check quota and service limits
+ - Run the Choreo compatibility prerequisite script
+Customer
+Customer
+WSO2
+-
+
+
+Remote access for installation
+Provide access
+Customer
+Customer
+WSO2
+WSO2
+
+
+Network management
+- Obtain customers backend CIDR in case of VPN/peering
+ - Check end-to-end connectivity (primary and failover)
+WSO2/Customer
+WSO2/Customer
+Customer
+Customer
+
+
+Firewall rules/access control
+Set up firewall and required rules depending on the security tier
+WSO2/Customer
+WSO2/Customer
+Customer
+Customer
+
+
+Infrastructure provisioning
+- Provision Bastion
+ - Provision Kubernetes clusters
+WSO2
+WSO2
+Customer
+Customer
+
+
+Kubernetes cluster management
+- Manage Kubernetes versions
+ - Increase node pool size
+WSO2
+WSO2
+Customer
+Customer
+
+
+Infrastructure monitoring
+Set up alerts
+WSO2
+WSO2
+-
+Customer(If required)
+
+
+DNS management for Choreo system
+- Manage DNS infrastructure
+ - Manage SSL certificates for Choreo system components
+WSO2/Customer
+WSO2/Customer
+Customer
+Customer
+
+
+Choreo system components deployment
+Set up PDP agents via Helm
+WSO2
+WSO2
+Customer
+-
+
+
+Choreo system components management
+Upgrade/patch/debug versions
+WSO2
+WSO2
+-
+Customer(If required)
+
+
+Choreo system components monitoring
+- Set up continuous monitoring 24x7
+ - Provide monthly uptime reports
+WSO2
+WSO2
+-
+Customer
+
+
+Choreo system security monitoring
+If basic tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security (Image scanning, SAST)
+ - Manage security incidents
+ If standard tier/premium tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security
+ - Monitor runtime security alerts (Azure Defender)
+ - Monitor security incident and event management (SIEM) alerts
+ - Manage security incidents
+ - Adhere to compliance standards
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+
+
+Choreo application creation/deployment
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application management
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application monitoring
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
+Choreo application logs
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
diff --git a/en/pe-docs/docs/references/private-data-plane-security-levels.md b/en/pe-docs/docs/references/private-data-plane-security-levels.md
new file mode 100644
index 0000000000..b20104c6a4
--- /dev/null
+++ b/en/pe-docs/docs/references/private-data-plane-security-levels.md
@@ -0,0 +1,87 @@
+# Private Data Plane Security Levels
+
+The following table outlines the private data plane security levels supported in Choreo:
+
+
+
+
+
+Task
+Task description
+Responsible party
+Accountable
+Consulted
+Informed
+
+
+Subscription prerequisites
+- Create subscriptions
+ - Check quota and service limits
+ - Run the Choreo compatibility prerequisite script
+Customer
+Customer
+WSO2
+WSO2
+
+
+Remote access for installation
+Provide owner access
+Customer
+Customer
+WSO2
+-
+
+
+Network management
+- Obtain customers backend CIDR in case of VPN/peering
+ - Check end-to-end connectivity (primary and failover)
+Customer
+Customer
+WSO2
+WSO2
+
+
+Firewall rules/access control
+Set up firewall and required rules depending on the security tier
+Customer
+Customer
+WSO2
+WSO2
+
+
+Infrastructure provisioning
+- Provision Bastion
+ - Provision Kubernetes clusters
+Customer
+Customer
+WSO2
+WSO2(If required)
+
+
+Kubernetes cluster management
+- Manage Kubernetes versions
+ - Increase node pool size
+Customer
+Customer
+WSO2
+WSO2(If required)
+
+
+Infrastructure monitoring
+Set up alerts
+Customer
+Customer
+WSO2
+-
+
+
+DNS management for Choreo system
+- Manage DNS infrastructure
+ - Manage SSL certificates for Choreo system components
+Customer
+Customer
+WSO2
+-
+
+
+Choreo system components deployment
+Set up PDP agents via Helm
+Customer
+Customer
+WSO2
+-
+
+
+Choreo system components management
+Upgrade/patch/debug versions
+Customer
+Customer
+WSO2
+-
+
+
+Choreo system components monitoring
+- Set up continuous monitoring 24x7
+ - Provide monthly uptime reports
+Customer
+Customer
+WSO2
+-
+
+
+Choreo system security monitoring
+If basic tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security (Image scanning, SAST)
+ - Manage security incidents
+ If standard tier/premium tier
+ - CSPM
+ - Apply security patches
+ - Manage supply chain security
+ - Monitor runtime security alerts (Azure Defender)
+ - Monitor security incident and event management (SIEM) alerts
+ - Manage security incidents
+ - Adhere to compliance standards
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+WSO2/Customer
+
+
+Choreo application creation/deployment
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application management
+
+ Customer
+Customer
+Customer
+Customer
+
+
+Choreo application monitoring
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
+Choreo application logs
+
+ Customer
+Customer
+Customer
+Customer
+
+
+
+
+\* Not available in the on-premises private data plane.
+
+!!! tip
+ Available add-ons:
+ - Security incident and event management (SIEM).
+ - 24/7 security operation center.
diff --git a/en/pe-docs/docs/references/troubleshoot-choreo.md b/en/pe-docs/docs/references/troubleshoot-choreo.md
new file mode 100644
index 0000000000..167dfc60bf
--- /dev/null
+++ b/en/pe-docs/docs/references/troubleshoot-choreo.md
@@ -0,0 +1,109 @@
+# Troubleshoot Choreo
+
+This page walks you through common problems you may encounter when building and deploying components with Choreo, along with the recommended solutions to resolve each issue.
+
+## Troubleshoot component build errors
+
+- ### Deploying an Angular web application displays the Nginx welcome page instead of the application's homepage.
+
+ This occurs due to specifying an incorrect build output directory when you set up your Angular application in Choreo.
+To resolve the issue, follow the guidelines given below:
+
+ - Ensure that the build output directory correctly points to where your Angular build script outputs the files. The deafult output directory is `dist/
+
+
+
+Basic tier
+Standard tier
+Premium tier
+
+
+Distributed denial-of-service (DDoS) protection basic *
+Distributed denial-of-service (DDoS) protection basic *
+Distributed denial-of-service (DDoS) protection premium *
+
+
+Controlled admin access *
+Controlled admin access *
+Controlled admin access *
+
+
+End-to-end data encryption in transit
+End-to-end data encryption in transit
+End-to-end data encryption in transit
+
+
+Data encryption at rest *
+Data encryption at rest *
+Data encryption at rest *
+
+
+Secret management
+Secret management
+Secret management
+
+
+Foundational CSPM *
+Foundational CSPM *
+Premium CSPM *
+
+
+Static application security testing (SAST)
+Static application security testing (SAST)
+Static application security testing (SAST)
+
+
+Infrastructure as code (IaC) scanning
+Infrastructure as code (IaC) scanning
+Infrastructure as code (IaC) scanning
+
+
+Software composition analysis
+Software composition analysis
+Software composition analysis
+
+
+Docker image security scanning
+Docker image security scanning
+Docker image security scanning
+
+
+N/A
+Kubernetes runtime protection *
+Kubernetes runtime protection *
+
+
+N/A
+Web application firewall (WAF) *
+Web application firewall (WAF) *
+
+
+
+N/A
+N/A
+Network firewall *
+404 - Not found. Try one of the menu links or use the search engine in the top right corner.
-
-
-
-
-
-
-
Configure a Custom Domain for Your Organization¶
-Choreo custom domain configuration model¶
-Configure a custom domain for an organization¶
-Prerequisites¶
-
-
-Add a custom domain¶
-
-
-
-
-
-
-
-
-
-
-
-
-apis.choreo.dev, the SSL file must include apis.choreo.com.apis.choreo.dev, the SSL file should use *.choreo.dev.
-
-
-
-Configure a custom URL for a component¶
-Request a custom URL for a component¶
-
-
-
-
-Approve a custom URL request¶
-
-
-
-
-
-
-
-
Configure a User Store with the Built-In Identity Provider¶
-Prerequisites¶
-Configure a Choreo built-in IdP user store¶
-
-
-username,password,groups,first_name,last_name,email
-"demouser","password1","[manager, engineering]","John","Doe","john@acme.org"
-.csv file. To include more user attributes, add columns as required in the .csv file.
-
-
-
-
-
-
-
-
-
-
-
-
-
Configure Asgardeo as an External Identity Provider (IdP)¶
-Prerequisites¶
-
-
-Add Asgardeo as an external IdP in Choreo¶
-
-
-
-
-
-
-
-
Configure Azure Active Directory (Azure AD) as an External Identity Provider (IdP)¶
-Prerequisites¶
-
-
-Add Azure Active Directory as an external IdP in Choreo¶
-
-
-
-
-
-
-
-
- Well-Known URL of your Azure AD instance, on your Azure account, under Azure Active Directory go to App registrations, and then Endpoints. Copy the URI underOpenID Connect metadata document.
-
-Well-Known URL, omit the v2.0 path segment from the URL. Learn more
-For example, convert https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration-> https://login.microsoftonline.com/<tenant-id>/.well-known/openid-configuration
-
-
-
-
-
Configure Enterprise Login¶
-Prerequisites¶
-
-
-Configure enterprise login for your Choreo organization¶
-
-
-choreo-help@wso2.com requesting to enable enterprise login for your organization.
-
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name/Host/Alias
-Specify
-@ or leave it blank
-
-Time to Live (TTL)
-Keep the default value or use
-86400
-
-
-Value/Answer/Destination
-wso2-domain-verification:<
-verification_code>Bring your own identity to Choreo¶
-
-
-Configure role-based access control for enterprise login¶
-Prerequisites¶
-
-
-Step 1: Configure Asgardeo¶
-
-
-
-
-
-
-
-
-Step 2: Map Choreo groups to enterprise IdP groups via the Choreo Console¶
-
-
-
-
-
-
-
-
-
-
Configure Self-Sign-Up¶
-Prerequisites¶
-
-
-Configure Developer Portal self-sign-up¶
-
-
-
-
-https://devportal.choreo.dev/starkindustries.
-
-
-
-Manage new users¶
-
-
-Enable auto-approval for new user registrations¶
-
-
-Manually approve or reject user accounts¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Control Access in the Choreo Console¶
-
-
-
-
-
- all users in a group inherit the permissions granted by that role across all organizational resources.
- For example, if a user has edit_project permission at the organization mapping level, that user can edit all the projects in the organization.Sample scenario¶
-Step 1: Create a project¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Display Name
-
-Engineering Project
-
-Name
-
-engineering-project
-
-
-Project Description
-
-My sample projectStep 2: Create a new group¶
-Engineering Project Developer:
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Group Name
-
-Engineering Project Developer
-
-
-Group Description
-
-Users with development access within the engineering projectStep 3: Assign roles to the group¶
-
-
-Step 4: Add users to the group¶
-Add a new user as a project developer
-
-
-Add an existing user as a project developer
-
-
-
-
-
-
-
-
-
-
Create API Subscription Plans¶
-
-
-
-
-
-
-
-
-
-
Customize the Developer Portal¶
-
-
-
-
-
-
-Try our APIs!).#C3C5CD and the primary color of the buttons to #086634).Reset the Developer Portal theme¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Inviting members
-
-Inviting users¶
-
-
-
-
-
-
Manage Members of an Organization¶
-Inviting users¶
-Manage user permission¶
-
-
-
-
-
-
API Policies¶
-Request, Response, or Error flow of an API invocation before it reaches the backend or the client. For example, you can add a policy to the response flow to transform the payload from JSON to XML and add a header to the response. Inbuilt mediation policies¶
-
-
-${headerName}.${fooValue}.${authzHeaderValue}.${authzHeaderValue}. ${myResourcePath}.Log Headers and Log Payload parameters. To exclude specific headers when logging, you can use the Excluded Headers parameter, which takes a comma-separated list of header names. An error will occur if payload logging is enabled but the payload cannot be read.Attach and manage mediation policies¶
-
-
-
-
-Response flow or the Error flow. Then the response is forwarded to the client.Error flow and sends an error response to the client.Attach a policy¶
-Request, Response, or Error flow of a REST API proxy, follow the steps given below:
-
-${<variableName>} format. For example, you can use ${name} as an example.
-
-Refresh mediation policies¶
-
-
-
-
-Implement an API policy¶
-Prerequisites¶
-
-
-~/.ballerina/settings.toml file and ensure you have configured an access token to Ballerina Central. If you have not configured an access token, follow the steps given below to configure one:
-
-Settings.toml file and copy it to your local ~/.ballerina directory.BALLERINA_CENTRAL_ACCESS_TOKEN environment variable.Step 1: Initialize a Ballerina project¶
-mediation.template as the project template, issue the following command: Ballerina.toml and the Package.md files of the generated project. For example, you can update the org, package, package version, API documentation content, keywords, etc.org value to your organization name. [package]
- org = "starkindustries"
- name = "validateHeader"
- version = "1.0.0"
- export = ["validateHeader"]
- distribution = "2201.5.5"
- keywords = ["choreo-apim-mediation-policy","choreo-apim-mediation-request-flow","choreo-apim-mediation-response-flow","choreo-apim-mediation-fault-flow"]
-Step 2: Implement the policy¶
-
-
-403 Bad Request response to the client.policy.bal file in the Ballerina project and update the generated policy stubs(i.e., request, response, or fault) appropriately. Request flow
-@mediation:RequestFlow
-public function validateRequestHeader(mediation:Context ctx, http:Request req, string headerName, string headerValue) returns http:Response|false|error|() {
- string|http:HeaderNotFoundError header = req.getHeader(headerName);
- if (header is http:HeaderNotFoundError) {
- string message = string `Header ${headerName} is not found`;
- log:printError(message);
- return generateResponse(message, http:STATUS_BAD_REQUEST);
- }
- if (header != headerValue) {
- string validationFailedMessage = string `Header validation failed. Expected ${headerValue} but found ${header}`;
- log:printError(validationFailedMessage);
- return generateResponse(validationFailedMessage, http:STATUS_BAD_REQUEST);
- }
- log:printInfo("Header validation successful");
- return ();
-};
-
-function generateResponse(string message, int statusCode) returns http:Response {
- http:Response response = new();
- response.setTextPayload(message);
- response.statusCode = statusCode;
- return response;
-}
-Response flow
-@mediation:ResponseFlow
-public function validateResponseHeader(mediation:Context ctx, http:Request req, http:Response res, string headerName, string headerValue) returns http:Response|false|error|() {
- string|http:HeaderNotFoundError header = res.getHeader(headerName);
- if (header is http:HeaderNotFoundError) {
- string message = string `Header ${headerName} is not found`;
- log:printError(message);
- return ();
- }
- if (header != headerValue) {
- string validationFailedMessage = string `Header validation failed. Expected ${headerValue} but found ${header}`;
- log:printError(validationFailedMessage);
- return ();
- }
- return ();
-}
-Fault flow
-Fault flow. Therefore, you can remove the Fault flow stub from the policy.bal file.Ballerina.toml. Therefore, the changes you make to the policy stubs should reflect in the Ballerina.toml file. For example, if the policy is applicable only on the request and response paths, you can remove the @mediation:FaultFlow annotation from the policy. Then, you MUST also remove the choreo-apim-mediation-fault-flow keyword from the generated Ballerina.toml file. If you do not do so, the Ballerina compiler will show an error at compile time.Publish as a private custom policy
-private prior to pushing the package to Ballerina Central as follows:
-
-Ballerina.toml file of your policy. visibility="private". For example:[package]
- org = "orgName"
- name = "packageName"
- version = "1.0.2"
- export = ["packageName"]
- distribution = "2201.5.5"
- keywords = ["choreo-apim-mediation-policy","choreo-apim-mediation-request-flow","choreo-apim-mediation-response-flow","choreo-apim-mediation-fault-flow"]
- visibility = "private"
-Best practices
-
-
-Request, Response, and Fault. You can remove any stub that you do not require. For example, when you create a policy that re-writes the resource paths, you can remove the Response and fault stubs.
-
-false if you want to terminate the mediation sequence with a predefined response (on the Choreo side).Step 3: Publish the policy¶
-
-
-Write unit tests¶
-validateRequestHeader function:import ballerina/http;
-import choreo/mediation;
-import ballerina/test;
-
-
-@test:Config {}
-public function testRequestHeaderValidationFailure() {
- http:Request req = new;
- http:Response|false|error|() result = validateRequestHeader(createContext("get", "/test"), req, "testHeader", "test");
-
-
- if !(result is http:Response) {
- test:assertFail("Expected http:Response, found " + (typeof result).toString());
- }
-
-
- test:assertEquals(result.statusCode, http:STATUS_BAD_REQUEST, "Status code mismatch");
-}
-
-
-function createContext(string httpMethod, string resPath) returns mediation:Context {
- mediation:ResourcePath originalPath = checkpanic mediation:createImmutableResourcePath(resPath);
- mediation:Context originalCtx =
- mediation:createImmutableMediationContext(httpMethod, originalPath.pathSegments(), {}, {});
- mediation:ResourcePath mutableResPath = checkpanic mediation:createMutableResourcePath(resPath);
- return mediation:createMutableMediationContext(originalCtx, mutableResPath.pathSegments(), {}, {});
-}
-Glossary¶
-mediation:Context
-# Retrieves the value for the specified key.
-public function get(string name) returns anydata;
-
-
-# Stores the provided key-value pair. If a mapping exists for the key, the value is overwritten.
-public function put(string name, anydata value);
-
-
-# Removes the entry mapped by the specified key and returns the removed value.
-public function remove(string name) returns anydata;
-
-
-# Retrieves the value for the specified key. If there is no mapping for the key, return the specified
-public function getOrDefault(string name, anydata default) returns anydata;
-
-
-# Checks whether a mapping exists for the specified key.
-public function hasKey(string name) returns boolean;
-
-
-# Returns the `mediation:Context` instance which captured the initial contextual information of the resource,
-# before the mediation flow was invoked. Calling this on an original `mediation:Context` object will return itself.
-public function originalContext() returns Context;
-
-
-# The HTTP method of the resource method
-public function httpMethod() returns string;
-
-
-# Retrieves an instance of `mediation:ResourcePath` which is an API for contextual information on the resource path
-# of this resource. It also contains methods for modifying the resource path as the user sees fit. This resource
-# path is the same path used by the mediation service for deriving the backend endpoint's resource to invoke.
-# Therefore, the default behavior of the mediation service is to invoke a resource in the backend endpoint which
-# has the same relative resource path as the corresponding mediation service resource.
-public function resourcePath() returns ResourcePath;
-
-
-# Sets the given `mediation:ResourcePath` instance as the resource path of this context.
-public function setResourcePath(ResourcePath path);
-
-
-# Adds a mapping between a path param name and a resolved value for it. There need not be a path parameter in the
-# resource path by the name specified in `name` for one to use this method. On its own, the path param values have
-# no bearing on the resource path.
-public function addPathParamValue(string name, PathParamValue value);
-
-
-# Returns the collection of resolved values for the path parameters in this particular context, mapped
-# by the parameter name.
-public function resolvedPathParams() returns map<PathParamValue> & readonly;
-
-
-# Removes the resolved path parameter value which maps to the specified name.
-public function removePathParamValue(string name);
-
-
-# Adds a query parameter to the request to be sent to the backend. If there is already a query parameter by
-# with the same name, the new value will be appended to it, making it an array.
-public function addQueryParam(string name, string value);
-
-
-# Removes the specified query parameter from the request. If the value of the parameter is an array, the whole
-# array will be removed.
-public function removeQueryParam(string name);
-
-
-# Retrieves a map of all the query parameters in the current request context. The returned map is a read-only snapshot
-# of the map of query parameters in the context at the time this method was called.
-public function queryParams() returns map<string[]> & readonly;
-Keywords¶
-Ballerina.toml file needs to include the following keywords for the mediation policies to work:
-
-Policy name and description
-Package.md file contains information about the policy. Choreo uses this information to render the policy configuring UI. This file is written in Markdown format and should be structured as follows.# ValidateHeader
-
-
-## Overview
-
-
-This policy validates the request and response headers with the configured values.
-Policy versioning
-
-
-
-
-
-
API Rate Limiting¶
-Enable rate limiting for an API¶
-
-
-API-level rate limiting¶
-Operation-level rate limiting¶
-Rate-limiting response headers¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Header Name
-Description
-
-
-
-x-ratelimit-limitDenotes the request count allocated for the specified time unit.
-
-
-
-x-ratelimit-resetProvides the time remaining to start the next rate-limiting time unit.
-
-
-
-x-ratelimit-remainingDenotes the remaining request count for the specified time unit.
-
-
-
-
-x-ratelimit-enforcedVisible after exceeding the allocated request count.
-
-
-
-
-
-
Control API Visibility¶
-Public. However, developers can control the visibility of their APIs by changing the default option to Private or Restricted.
-
-Change API visibility¶
-
-
-
-
-
-
-
-
-
-
-Restricted from the API visibility list. Once selected, you will see the roles available in your organization in the Visible Roles list.
-
-
-
-
-
-
-
Documents¶
-
-
-Add documents to an API¶
-
-
-
-
-
-
-
-
Lifecycle Management¶
-API lifecycle states¶
-
-
-
-
-
-
-
-API lifecycle state
-Use case
-Corresponding action
-
-
-CREATED
-The API is created but is not ready for consumption.
-The API is not visible to subscribers in the Developer Portal.
-
-
-PRE-RELEASED
-A prototype is created for early promotion and consumer testing. You can deploy a new API or a new version of an existing API as a prototype to provide subscribers with an early implementation of the API.
-The API is published to the Developer Portal as a pre-release.
-
-
-PUBLISHED
-The API is ready for subscribers to view and subscribe to via the Developer Portal
-The API is visible in the Developer Portal and is available for subscription.
-
-
-BLOCKED
-Access to the API is temporarily blocked.
-Runtime calls are blocked, and the API is not visible in the Developer Portal.
-
-
-DEPRECATED
-The old version of an API is moved to this state when a newer version of the API is PUBLISHED.
-The API is deployed and is available to existing subscribers. New subscriptions are disabled. Existing subscribers can continue to use it as usual until the API is retired.
-
-
-
-RETIRED
-The API is no longer in use when it is in this state.
-The API is unpublished and deleted from the Developer Portal.
-Manage the lifecycle of an API¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Assign Subscription Plans to APIs¶
-
-
-
-
-
-
-
-
Subscribe to an API with a Subscription Plan¶
-
-
-
-
-
-
-
-
Rename API Display Name¶
-<component name>-<endpoint name>. For example, if you create a component named Ballerina Reading List, the API is displayed as Ballerina Reading List - GraphQL Reading List 591.
-
-
-
-
-
-
-
Configure Mutual TLS Between Components¶
-Generate certificates to establish mutual TLS¶
-
-
-http://my-service-3781140846:7080/todos, the hostname will be my-service-3781140846.Read mutual TLS certificates from your component¶
-Sample for mutual TLS communication¶
-
-
-
-
-
-
Pass End-User Attributes to Upstream Services¶
-How it works¶
-http://wso2.org/claims.{token header}.{claims list}.{signature}X-JWT-Assertion header in the outgoing message. The backend service fetches the JWT and retrieves the required information about the user, application, or token.Claims¶
-{
- "sub": "11f53c32-f8ac-4810-bb79-615b2184baf5",
- "http://wso2.org/claims/apiname": "JWT Test - Endpoint 9090 803",
- "http://wso2.org/claims/applicationtier": "Unlimited",
- "http://wso2.org/claims/version": "1.0.0",
- "http://wso2.org/claims/keytype": "PRODUCTION",
- "iss": "wso2.org/products/am",
- "http://wso2.org/claims/applicationname": "jwtTest2",
- "http://wso2.org/claims/enduserTenantId": "0",
- "http://wso2.org/claims/applicationUUId": "45101ccb-865f-4f48-b7ac-18e43b07edd3",
- "client_id": "IMJB5ZiR1dHQYBdiMIRAGis1WToa",
- "http://wso2.org/claims/subscriber": "5f4a7105-a889-4f92-9612-eef5bafe4eec",
- "azp": "IMJB5ZiR1dHQYBdiMIRAGis1WToa",
- "org_id": "b554e001-761c-4d3a-a7a6-a61d73d34221",
- "http://wso2.org/claims/tier": "Unlimited",
- "scope": "email openid profile",
- "exp": 1690537362,
- "http://wso2.org/claims/applicationid": "45101ccb-865f-4f48-b7ac-18e43b07edd3",
- "http://wso2.org/claims/usertype": "Application_User",
- "org_name": "test",
- "iat": 1690533762,
- "email": "testmail@gmail.com",
- "jti": "69558555-d386-4a81-9ca0-0a23f809cd3c",
- "http://wso2.org/claims/apicontext": "/b554e001-761c-4d3a-a7a6-a61d73d34221/swog/jwt-test/endpoint-9090-803/1.0.0"
-}
-
-
-
-
-
-
-
-Claim Name
-Description
-Mandatory/Optional
-
-
-
-iatThe time the token was issued.
-Mandatory
-
-
-
-jtiThe unique token identifier.
-Mandatory
-
-
-
-expThe token expiry time.
-Mandatory
-
-
-
-issThe issuer of the token.
-Mandatory
-
-
-
-http://wso2.org/claims/apinameThe name of the API in Choreo.
-Optional
-
-
-
-http://wso2.org/claims/versionThe API version.
-Optional
-
-
-
-http://wso2.org/claims/keytypeThe environment in Choreo that the API is in (
-Development or production).Optional
-
-
-
-http://wso2.org/claims/apicontextThe API context in Choreo.
-Optional
-
-
-
-http://wso2.org/claims/subscriberThe subscriber to the API, usually the app developer.
-Optional
-
-
-
-http://wso2.org/claims/applicationnameThe application through which the API invocation is done.
-Optional
-
-
-
-http://wso2.org/claims/applicationidThe ID of the application through which the API invocation is done.
-Optional
-
-
-
-http://wso2.org/claims/applicationUUIdThe UUID of the application.
-Optional
-
-
-
-client_idThe client identifier. This is copied from the original token.
-Optional
-
-
-
-azpThe authorized party (the party to which the ID token was issued). This is copied from the original token.
-Optional
-
-
-
-org_idThe organization ID. This is copied from the original token.
-Optional
-
-
-
-org_nameThe organization name. This is copied from the original token.
-Optional
-
-
-
-http://wso2.org/claims/tierThe tier/price band for the subscription.
-Optional
-
-
-
-scopeThe scope of the token. This is copied from the original token.
-Optional
-
-
-
-http://wso2.org/claims/usertypeThe type of application user whose action invoked the API.
-Optional
-
-
-
-
-emailThe email address of the user. This is copied from the original token.
-Optional
-{
- "http://wso2.org/claims/apiname": "DefaultAPI",
- "http://wso2.org/claims/version": "1.0.0",
- "http://wso2.org/claims/keytype": "PRODUCTION",
- "iss": "wso2.org/products/am",
- "http://wso2.org/claims/enduserTenantId": "0",
- "exp": 1673245727,
- "http://wso2.org/claims/usertype": "Application_User",
- "iat": 1673242127,
- "jti": "6e3f4392-8bd9-4900-9d08-eaab7429c510",
- "http://wso2.org/claims/apicontext": "/9e71ab5e-6df5-4727-92d2-80ecf1a6218d/qbky/default/1.0.0"
-}
-JWKS support in Choreo to validate the JWT¶
-
-
-https://<PDP_GATEWAY_DOMAIN>/.wellknown/jwks<PDP-GATEWAY-DOMAIN> with the default domain configured to access the PDP APIs.{
- "keys": [
- {
- "kty": "RSA",
- "e": "AQAB",
- "use": "sig",
- "kid": "ZjcwNmI2ZDJmNWQ0M2I5YzZiYzJmZmM4YjMwMDFlOTA4MGE3ZWZjZTMzNjU3YWU1MzViYjZkOTkzZjYzOGYyNg",
- "alg": "RS256",
- "n": "8vjeHzRhvpfMystncPnLBWy_t5F3eCxbcLbdugWnzfnIgaV6TWnqPBUagJBKpzRZs4A9Qja_ZrSVJjYsbARzCS_qiWp0Cdwkqn6ZCXpmbpfjYnKORq8N8M-zWaSZYbNvWJ5oSO4kH-LKWzODaFebwTJBpsR1vChHH95doxFuUjiZaisVaQgUJ6drRdlDtImp9r9EAX36YROuYFPoEJcvsH4_uuAR6ClJ12RE3M-YN4NTi1waVNvGbz43oNrpPy7SXgpizingxSGMqI6WU2ysRmk_f9ALgiPIpFDpufiCTYaIcRT-YcUyp9nMDlTRskMuD-dQ1sdJOa11P_yMs-glfQ"
- }
- ]
-}
-
-
-
-
-
-
-
-Property
-Description
-
-
-
-ktyThe cryptographic family to which the key belongs.
-
Choreo only supports RSA.
-
-
-eThe exponent value of the public key.
-
-
-
-useThe purpose of the key. For example, whether it is for signing or encryption.
-
-
-
-kidThe identification parameter to match a specific key.
-
-
-
-algThe algorithm to use with the key.
-
-
-
-
-nThe modulus value of the public key.
-Enable passing end-user attributes to the backend¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Secure API Access with Asgardeo¶
-
-
-Prerequisites¶
-
-
-Step 1: Assign scopes to an API in Choreo¶
-
-
-Step 2: Create an API and an application in Asgardeo¶
-
-
-
-
-JWT as the Access Token.Step 3: Create an application in Choreo and enable external IdP authentication¶
-
-
-Asgardeo.
-
-Step 4: Invoke the Choreo API with scopes¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Secure API Access with Microsoft Azure Active Directory (Azure AD)¶
-
-
-Prerequisites¶
-
-
-Application Developer role is required. Learn moreStep 1: Assign scopes to an API in Choreo¶
-
-
-Step 2: Create a web API on Azure AD¶
-
-
-
-
-Step 2.1: Assign users to the web API¶
-
-
-Step 3: Create a client application on Azure AD and invoke the Azure web API¶
-Step 3.1: Create a client application¶
-
-
-Step 3.2: Consume the Azure AD web API from the Azure AD application¶
-
-
-Step 3.3: Create secrets for the Azure web application¶
-
-
-Secret ID and Value for future reference. Application (client) ID and save it for future reference.Step 4: Create an application in Choreo and enable external IdP authentication.¶
-
-
-Application (client) ID you copied in at Step 3.2 as the Client ID.
-
-Step 5: Invoke the API with scopes¶
-
-
-
-
-
-
-
-
-
-
-curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
-{token_endpoint} \
--d 'client_id={client_id}' \
--d 'scope={scopes}' \
--d 'code={authorization_code}' \
--d 'redirect_uri={redirect_url}' \
--d 'client_secret={The client_secret value you copied from the Azure Application}'
--d 'grant_type=authorization_code' \
-curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
-https://login.microsoftonline.com/dd912d48-b0be-401f-b18c-8ca89e9c0b6c/oauth2/v2.0/token \
--d 'client_id=5eb1de74-e449-4973-a620-52c4dc9157a9' \
--d 'scope=api://580b40b7-5513-4714-a4e0-8d4e784f7dc6/urn:taylordean:books:books_add' \
--d 'code=0.AXAASC…zZUzKYm18yM_5-SXz1uvRbbGYF7F32hE9zIQFRQY35haD' \
--d 'redirect_uri=https://localhost:9000' \
--d 'grant_type=authorization_code' \
--d 'state=111' \
--d 'client_secret=l4Q8Q~4WKiRXYSQZly5E6Ess.fKf__U1yJR3IaMd'
-
-
-
-
-
-
Secure Communication Between the Choreo Gateway and Your Backend with Mutual TLS¶
-Configure mutual TLS to establish secure connectivity¶
-Step 1: Configure the backend certificate¶
-Prerequisites
-
-
-.pem extension.
-
-Step 2: Configure mutual TLS with the backend service¶
-
-
-
-
-
-
-Step 3: Associate the certificate with the API¶
-
-
-Step 4: Deploy the API¶
-
-
-Change the certificate for the production environment¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Secure Web Applications with Managed Authentication¶
-Step 1: Set up managed authentication for your web application¶
-Step 1.1: Implement the sign-in functionality¶
-/auth/login path on click. You can use the following code snippet or any custom button component from a preferred UI component library:/). The user can then invoke any Choreo-deployed APIs depending on the permission granted.Optional: Pass additional query parameters to the identity provider
-/auth/login request. Choreo appends these parameters to the authorize request sent to the identity provider.Step 1.2: Obtain user information claims¶
-Obtain user information via the
-userinfo cookieuserinfo cookie that is accessible from the post-sign-in path you configured (by default, set to /). This userinfo cookie, provided by the identity provider, contains encoded user information claims.
-
-userinfo cookie is intentionally set to have a short lifespan of only 2 minutes.js-cookie library for cookie parsing. You can use any cookie-parsing library of your choice. import Cookies from 'js-cookie';
-
- // Read userinfo cookie value.
- const encodedUserInfo = Cookies.get('userinfo')
-
- // Decode the value.
- const userInfo = JSON.parse(atob(encodedUserInfo))
-
- // Store the value in a preferred browser-based storage if needed.
-
- // Clear the cookie.
- Cookies.remove('userinfo', { path: <post-login-path> })
-Obtain user information via a GET endpoint
-/auth/userinfo in addition to the userinfo cookie that it sets after successful sign-in. You can use this endpoint to query information about users who have signed in. It also serves as a mechanism to check the state of a user who has signed in.200 OK response with the user information in JSON format in the response body. However, if the user is not signed in, the server sends a 401 Unauthorized response.Step 1.3: Implement the sign-out functionality¶
-/auth/logout path along with the session_hint cookie value on click. You can use the following code snippet or any custom button component from a preferred UI component library:
-
-js-cookie library for cookie parsing. You can use any cookie-parsing library of your choice. <button onClick={async () => {
- window.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`;
-}}>Logout</button>`
-Step 1.4: Invoke APIs¶
-/choreo-apis/<api-suffix>, regardless of whether managed authentication is enabled for the web application or not.https://2d9ec1f6-2f04-4127-974f-0a3b20e97af5-dev.e1-us-east-azure.choreoapis.dev/rbln/item-service/api-e04/1.0.0, the <api-suffix> would be /rbln/item-service/api-e04/1.0.0. You can invoke the API using the /choreo-apis/rbln/item-service/api-e04/1.0.0 relative path from your single-page application.Step 1.5: Handle session expiry¶
-401 Unauthorized response status code for a Choreo API request from a logged-in user indicates that the session may have expired, requiring the user to re-login.401 Unauthorized response from a Choreo API, you can encapsulate the request with re-login logic. The following sample code snippet shows how to wrap GET requests: export const performGet = async (url) => {
- try {
- // API call
- return await fetch('/choreo-apis/<api-suffix>');
- } catch (error) {
- if (error instanceof HttpError && error.status === 401) {
- // Re-login
- window.location.href = "/auth/login";
- } else {
- throw error;
- }
- }
- };
-Step 1.6: Set up a custom error page¶
-
-
-
-
-
-
-
-Parameter
-Description
-
-
-code
-A short textual error code indicating the error
-
-
-
-message
-The description of the error
-Step 2: Enable managed authentication and configure the paths¶
-
-
-
-
-
-
-
-
-
-Field
-Description
-Default value
-
-
-Post Login Path
-The relative path that the application will be redirected to on successful sign-in. In your code, you must implement the necessary logic to obtain signed-in user's information from the
-userinfo cookie set by managed authentication. See Obtain user information via the userinfo cookie section in Obtain user information claims./
-
-
-Post Logout Path
-The relative path to which Choreo redirects you on successful sign-out.
-/
-
-
-Error Path
-The relative path to which Choreo redirects you when an error occurs during a redirection-based flow (i.e., sign in or sign out). See Set up a custom error page.
-Built-in error page
-
-
-Session Expiry Time
-The time in minutes after which the user session expires. For a seamless experience, the session expiry value should match the refresh token expiry time of the OIDC application in your identity provider.
-10080 Minutes (7 Days)
-
-
-
-Additional Scopes
-All additional scopes required by the web application. The
-openid, profile, and email scopes are added by default together with the scopes required to invoke subscribed APIs.none
-Step 3: Configure the identity provider for the web application¶
-
-
-
-
-
-
-Code and Refresh Token as the Allowed grant types.
-
-JWT as the Token type.
-
-
-
-
-
-Code and Refresh Token as allowed grant types.
-
-
-
-
-
-
-
Test Secure API Access with Choreo Built-In Security Token Service¶
-
-
-
-
-Prerequisites¶
-
-
-Step 1: Assign permissions to an API in Choreo¶
-
-
-
-
-
-
-Step 2: Create roles and assign permissions¶
-
-
-Step 3: Assign roles to user groups¶
-
-
-Step 4: Test the API invocation¶
-
-
-Test the invocation when Choreo-managed authentication is enabled¶
-Test the invocation when the application manages the authentication¶
-
-
-
-
-
-
-
-
- code and refresh grant types are selected. This is required to obtain access tokens with an authorization code grant.
-
-
-
-
-
-
-
Choreo Command Line Interface (CLI) Overview¶
-
-
-Key features of the Choreo CLI¶
-
-
-
-
-
-
-
-
-
-
Get Started with the Choreo CLI¶
-
-
-Prerequisites¶
-
-
-
-
-Step 1: Login to Choreo¶
-Step 2: Create a project¶
-Step 3: Create a Web Application component¶
-
-
-
-
-
-Enter remote repository URL manually.
-
-
-
-
-
-
-Prompt
-value
-
-
-Configure source repository
-
-Enter remote repository URL manually
-
-Remote repository URL
-Your forked repository
-
-
-Branch
-
-main
-
-Directory
-
-.
-
-Build-pack
-
-nodejs
-
-Language Version
-
-20.x.x
-
-
-Port
-
-8080Step 4: View component details¶
-Step 5: Build the component¶
-Step 5.1: View build status¶
-Step 5.2: View build logs¶
-choreo logs --type=build --project="web-app-project" --component="my-web-app" --deployment-track="main" --build-id=<build_id>
-Step 6: Deploy to the Development environment¶
-successful you can deploy the component in the Development environment by running the following command:choreo create deployment "my-web-app" --env=Development --project="web-app-project" --build-id=<build-id>
-Step 6.1: Verify the deployment in the Development environment¶
-Step 6.2: View runtime logs¶
-choreo logs --type component-application --component my-web-app --project web-app-project --env Development --follow
-Step 7: Deploy to the Production environment¶
-
-
-choreo create deployment "my-web-app" --env=Production --project="web-app-project" --build-id=<build-id>
-Step 7.1: Verify the deployment in the Production environment¶
-View all CLI functions¶
-
-
-
-
-
-
Choreo Marketplace¶
-Discover services¶
-Search¶
-
-
-Filter¶
-
-
-Explore a service¶
-
-
-component-config file or endpoints.yaml file.
-If the user does not specify an API definition, this tab remains empty.Add a service to the Choreo Marketplace¶
-Add a Choreo service¶
-component name - endpoint name, while all other details remain unchanged.Service versioning in the Choreo Marketplace¶
-v1.0, v1.1, v1.2, and v2.0, the Choreo Marketplace displays services with versions v1 and v2 representing the latest versions v1.2 and v2.0 respectively.Semantic-version-based intelligent routing in the Choreo Marketplace¶
-Foo to a Choreo service named Bar, which is currently available in the Choreo Marketplace as version v1, and if the latest version of the service Bar within the v1 range is v1.2, the component Foo will automatically connect to Bar v1.2. Subsequently, when Bar releases version v1.3, traffic from Foo will automatically route to Bar v1.3.Edit services in the Choreo Marketplace¶
-
-
-
-
-
-
CI/CD¶
-
-
-Build¶
-
-
-Repeatable builds¶
-Trigger a build¶
-Build logs¶
-Deployment¶
-
-
-
-
-Set up area and initial deployment¶
-Immutable deployments¶
-Promote a component to a higher environment¶
-Configurations¶
-Environment-independent configurations¶
-Environment-specific configurations¶
-Task execution¶
-Zero-downtime deployments¶
-
-
-
-
-
-
Component¶
-
-
-
-
-
-
Connections¶
-Project Connections¶
-Component Connections¶
-
-
-
-
-
-
Data Planes¶
-Private data planes¶
-Infrastructure¶
-System components¶
-
-
-Connectivity with the control plane¶
-IP:Port from its perspective for these interactions. However, if an organization's network restricts all outbound traffic, it is necessary to permit outbound traffic to the public IP range of the Choreo control plane.
-
-
-
-
-
-
-
-Data plane component
-Endpoint
-Direction
-Protocol
-
-
-Choreo PDP agent
-Choreo control plane (CP) (mizzen server)
-Outbound
-WSS
-
-
-Kubernetes API server
-Outbound (cluster internal)
-HTTPS, WS
-
-
-APIM/local adaptor
-Global adaptor
-Outbound
-HTTPS
-
-
-Azure Service Bus (CP)
-Outbound
-AMQP
-
-
-APIM/Enforcer
-Event hub (CP)
-Outbound
-AMQP
-
-
-Choreo secret resolver
-Cloud secret store
-Outbound (VPC internal)
-HTTPS
-
-
-Container registry
-Container registry (public)
-Inbound
-HTTPS
-
-
-Container registry
-Outbound (VPC internal)
-HTTPS
-
-
-Certificate manager
-Azure DNS service
-Outbound
-HTTPS
-
-
-LetsEncrypt
-Outbound
-HTTPS
-
-
-Flux source controller
-GitHub
-Outbound
-HTTPS
-
-
-
-Flux Helm controller
-Choreo container registry
-Outbound
-HTTPS
-Observability architecture¶
-
-
-Security¶
-Management models¶
-
-
-
-
-
-
-
-
Deployment Tracks¶
-The significance of Deployment Tracks¶
-
-
-Streamlined deployments¶
-CI/CD with Deployment Tracks¶
-CD-Only strategy with Deployment Tracks¶
-Efficient API versioning¶
-v. v1.2.
-
-
-
-
-
-
-
Endpoint¶
-
-
-
-
-
-
Environments¶
-
-
-
-
-
-
Organization¶
-Switch organizations¶
-Inviting users¶
-Manage user permission¶
-Groups¶
-API Publisher group, they will automatically receive the API Publisher role.
-
-Roles¶
-
-
-Organization ID¶
-
-
-Organization Handle¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Project¶
-
-
-
-
-
-
Resource Hierarchy¶
-Organizations and data planes¶
-Environments and data planes¶
-Components and environments¶
-
-
-
-
-
-
Consume a Service¶
-
-
-Prerequisites¶
-Discover APIs¶
-
-
-Create an application¶
-Step 1: Create an application¶
-
-
-Step 2: Generate keys¶
-Generate environment-specific keys and tokens
-
-
-
-
-Subscribe to an API¶
-
-
-Consume the API via your web application¶
-
-
-
-
-Step 1: Create a web application component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-
-Reading List Web App
-
-
-Description
-
-Frontend application for the reading list service
-
-
-
-
-
-
-Field
-Description
-
-
-GitHub Account
-Your account
-
-
-GitHub Repository
-
-choreo-samples
-
-Branch
-
-main
-
-Buildpack
-Click React since the frontend is a React application built with Vite
-
-
-Build Context Path
-
-reading-list-app/reading-list-front-end
-
-Build Command
-
-npm install && npm run build
-
-Build Output
-
-dist
-
-
-Node Version
-
-18Step 2: Create an OAuth application in the IdP¶
-
-
-
-
-
-
-Step 3: Configure the web application to connect to the IdP and invoke the service¶
-window object at runtime. This is done via the config.js file in the root of the web application. In this section, you will mount the config.js file for the development environment. You will need to do the same for other environments as well when you deploy your web application to multiple environments.
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Config Type
-Config Map
-
-
-
-Mount Type
-File Mount
-
-
-
-
-
-
-
-Field
-Description
-
-
-Config Name
-Web App Config
-
-
-
-Mount Path
-/usr/share/nginx/html/config.js. Every config that needs to be exposed through the web server should be placed inside
-/usr/share/nginx/html/window.config = {
- redirectUrl: "<web-app-url>",
- asgardeoClientId: "<asgardeo-client-id>",
- asgardeoBaseUrl: "https://api.asgardeo.io/t/<your-org-name>",
- choreoApiUrl: "<reading-list-service-url>"
-};
-
-
-
-
-
-
-
-Field
-Description
-
-
-redirectUrl
-The web app URL you copied earlier.
-
-
-asgardeoClientId
-The Client ID of your OAuth application. In Asgardeo, you can find it on the Protocol tab of the readingListApp application
-
-
-asgardeoBaseUrl
-Specify the IdP API URL (For example, Asgardeo API URL) with your organization name. i.e.,
-https://api.asgardeo.io/t/<ORG_NAME>.
-
-
-choreoApiUrl
-The reading list service URL. Copy the Public URL of the Reading List Service component from the endpoint table in the overview page for the relevant environment
-Step 4: Deploy the web application¶
-
-
-
-
-
-
-
-
Create a subscription
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Create an application
-
-Step 1: Create an application¶
-
-
-Step 2: Generate keys¶
-Generate environment-specific keys and tokens
-
-
-
-
-
-
-
-
-
-
Generate an Access Token¶
-Prerequisites¶
-
-
-Generate an access token via cURL¶
-
-
-Generate an access token via the Choreo Console (for testing purposes)¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Manage Applications¶
-Step 1: Create an application¶
-
-
-Step 2: Generate keys¶
-Generate environment-specific keys and tokens
-
-
-
-
-Grant types¶
-Authorization code grant¶
-Refresh token grant¶
-
-
-Client credentials grant¶
-Implicit grant¶
-Password grant¶
-Revoke access tokens¶
-
-
-
-
-
-
Manage Subscriptions¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Share Applications¶
-
-
-
-
-
-
-
-
Bring Your Own Image (BYOI)¶
-
-
-Prerequisites¶
-
-
-Step 1: Register a container registry¶
-
-
-Authentication types¶
-Public (anonymous) access
-
-
-
-
-
-
-
-Vendor
-Registry host
-
-
-Docker Hub (public repositories)
-
-registry.hub.docker.com
-
-
-Docker Hub (private repositories)
-
-registry.docker.comBasic authentication
-Docker config
-auths.Vendor-specific authentication
-
-
-
-
-_json_key) as the username and specify the minified JSON contents of the service account key as the password.jq as follows to minify the service account JSON key file:jq -c . <service-account.json>
-
-
-
-Step 2: Create a component in Choreo¶
-
-
-[container-registry-host]/[repository-name]/[image-name]:[tag]/library/. For example, you can access the public Nginx image https://hub.docker.com/_/nginx as registry.hub.docker.com/library/nginx:1.25.Step 3: Deploy the component in Choreo¶
-
-
-
-
-
-
-
-
-
-Option
-Description
-
-
-Update Image Tag
-This option allows you to update the tag of the image.
-
-
-Update Image URL
-With this option, you can change the image name, tag, and the image repository of the image URL.
-
-
-
-Previous Images
-This option allows you to select a previous image and redeploy the image.
-Step 4: Expose service endpoints¶
-
-
-endpoints.yaml file by its file name, similar to the Git-based Choreo components. The endpoints template follows the standard definitions for defining endpoints in Choreo. For more details, see Configure Endpoints.Auto-deploy images in Choreo with an external CI/build pipeline¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Configure endpoints body
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Name
-A unique identifier for the endpoint within the service component.
-
-
-Port
-The network port on which the endpoint is accessible.
-
-
-Type
-The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP.
-
-
-Network Visibility
-Determines the level of visibility of an endpoint. Possible values are:
-
-
-Schema
-Specifies the structure and format of the data exchanged through the endpoint.
-
-
-
-Context (HTTP and GraphQL only)
-A context path that you add to the endpoint's URL for routing purposes.
-Configure endpoints¶
-Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.Configure endpoints with buildpacks (except Ballerina)¶
-endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.endpoints.yaml file.Configure endpoints with the Ballerina buildpack¶
-Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.endpoint.yaml file to define dynamic endpoint parameters.endpoints.yaml file.Learn the endpoints.yaml file¶
-endpoints.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-version
-Required
-The version of the
-endpoints.yaml file.
-
-name
-Required
-A unique name for the endpoint, which Choreo will use to generate the managed API.
-
-
-port
-Required
-The numeric port value that gets exposed via this endpoint.
-
-
-type
-Required
-The type of traffic this endpoint is accepting, such as
-REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type.
-
-networkVisibility
-Required
-The network level visibility of this endpoint, which defaults to
-Public if not specified. Accepted values are Project, Organization, or Public.
-
-context
-Required
-The context (base path) of the API that Choreo exposes via this endpoint.
-
-
-
-schemaFilePath
-Required
-The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context.
-Sample endpoints.yaml
-
-
-docker-build-context-path should be replaced with component-root.
-For example: <component-root>/.choreo/endpoints.yamldocker-build-context-path should be replaced with <Project Path>.
-For example: <Project Path>/.choreo/endpoints.yaml# +required Version of the endpoint configuration YAML
-version: 0.1
-
-# +required List of endpoints to create
-endpoints:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
-- name: Greeting Service
- # +required Numeric port value that gets exposed via this endpoint
- port: 9090
- # +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, UDP, TCP
- type: REST
- # +optional Network level visibility of this endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Project
- # +optional Context (base path) of the API that is exposed via this endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional Path to the schema definition file. Defaults to wild card route if not provided
- # This is only applicable to REST endpoint types.
- # The path should be relative to the docker context.
- schemaFilePath: greeting_openapi.yaml
-Apply advanced component connection configurations¶
-component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
-
-component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
-
-endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
-
-component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.Learn the
-component-config.yaml file¶component-config.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-apiVersion
-Required
-The version of the
-component-config.yaml file defaults to core.choreo.dev/v1beta1.
-
-kind
-Required
-The resource type of the file defaults to
-ComponentConfig.
-
-spec.inbound
-Optional
-The list of inbound connection configurations.
-
-
-
-spec.outbound
-Optional
-The list of outbound connection configurations.
-Inbound connection configurations (
-spec.inbound)spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.Outbound connection configurations (
-spec.outbound)spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.serviceReferences schema has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-name
-Required
-A unique name for the service reference.
-
-
-connectionConfig
-Required
-A unique name for the connection instance.
-
-
-env
-Optional
-The list of environment variable mappings that get injected into the container.
-
-
-env.from
-Required
-The key name of the connection configuration.
-
-
-
-env.to
-Required
-The environment variable that gets injected into the container.
-Sample component-config.yaml
-
-
-docker-build-context-path with the component-root.
-For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>.
-For example, <Project Path>/.choreo/component-config.yaml.apiVersion: core.choreo.dev/v1beta1
-kind: ComponentConfig
-spec:
- # +optional Incoming connection details for the component (AKA endpoints).
- inbound:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
- - name: Greeting Service
- # +required Numeric port value that gets exposed via the endpoint
- port: 9090
- # +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, TCP, UDP.
- type: REST
- # +optional Network level visibility of the endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Public
- # +optional Context (base path) of the API that gets exposed via the endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional The path to the schema definition file. Defaults to wildcard route if not specified.
- # This is only applicable to REST endpoint types.
- # The path should be relative to the Docker context.
- schemaFilePath: greeting_openapi.yaml
- # +optional Outgoing connection details for the component.
- outbound:
- # +optional Defines the service references from the Internal Marketplace.
- serviceReferences:
- # +required Name of the service reference.
- - name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC
- # +required Name of the connection instance.
- connectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412
- # +optional Environment variables injected to the component for connection configuration.
- env:
- # +required Key name of the connection configuration.
- - from: ServiceURL
- # +required Environment variable injected to the container.
- to: SERVICE_URL
-Expose endpoints as managed APIs¶
-
-
-Understand the default component URL¶
-<domain>/<project-name>/<component-name><domain>/<project-name>/<component-name>/<endpoint-name>Change the default endpoint of a component¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Configure Endpoints¶
-
-
-
-
-
-
-
-Field
-Description
-
-
-Name
-A unique identifier for the endpoint within the service component.
-
-
-Port
-The network port on which the endpoint is accessible.
-
-
-Type
-The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP.
-
-
-Network Visibility
-Determines the level of visibility of an endpoint. Possible values are:
-
-
-Schema
-Specifies the structure and format of the data exchanged through the endpoint.
-
-
-
-Context (HTTP and GraphQL only)
-A context path that you add to the endpoint's URL for routing purposes.
-Configure endpoints¶
-Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.Configure endpoints with buildpacks (except Ballerina)¶
-endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.endpoints.yaml file.Configure endpoints with the Ballerina buildpack¶
-Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.endpoint.yaml file to define dynamic endpoint parameters.endpoints.yaml file.Learn the endpoints.yaml file¶
-endpoints.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-version
-Required
-The version of the
-endpoints.yaml file.
-
-name
-Required
-A unique name for the endpoint, which Choreo will use to generate the managed API.
-
-
-port
-Required
-The numeric port value that gets exposed via this endpoint.
-
-
-type
-Required
-The type of traffic this endpoint is accepting, such as
-REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type.
-
-networkVisibility
-Required
-The network level visibility of this endpoint, which defaults to
-Public if not specified. Accepted values are Project, Organization, or Public.
-
-context
-Required
-The context (base path) of the API that Choreo exposes via this endpoint.
-
-
-
-schemaFilePath
-Required
-The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context.
-Sample endpoints.yaml
-
-
-docker-build-context-path should be replaced with component-root.
-For example: <component-root>/.choreo/endpoints.yamldocker-build-context-path should be replaced with <Project Path>.
-For example: <Project Path>/.choreo/endpoints.yaml# +required Version of the endpoint configuration YAML
-version: 0.1
-
-# +required List of endpoints to create
-endpoints:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
-- name: Greeting Service
- # +required Numeric port value that gets exposed via this endpoint
- port: 9090
- # +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, UDP, TCP
- type: REST
- # +optional Network level visibility of this endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Project
- # +optional Context (base path) of the API that is exposed via this endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional Path to the schema definition file. Defaults to wild card route if not provided
- # This is only applicable to REST endpoint types.
- # The path should be relative to the docker context.
- schemaFilePath: greeting_openapi.yaml
-Apply advanced component connection configurations¶
-component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
-
-component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
-
-endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
-
-component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.Learn the
-component-config.yaml file¶component-config.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-apiVersion
-Required
-The version of the
-component-config.yaml file defaults to core.choreo.dev/v1beta1.
-
-kind
-Required
-The resource type of the file defaults to
-ComponentConfig.
-
-spec.inbound
-Optional
-The list of inbound connection configurations.
-
-
-
-spec.outbound
-Optional
-The list of outbound connection configurations.
-Inbound connection configurations (
-spec.inbound)spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.Outbound connection configurations (
-spec.outbound)spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.serviceReferences schema has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-name
-Required
-A unique name for the service reference.
-
-
-connectionConfig
-Required
-A unique name for the connection instance.
-
-
-env
-Optional
-The list of environment variable mappings that get injected into the container.
-
-
-env.from
-Required
-The key name of the connection configuration.
-
-
-
-env.to
-Required
-The environment variable that gets injected into the container.
-Sample component-config.yaml
-
-
-docker-build-context-path with the component-root.
-For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>.
-For example, <Project Path>/.choreo/component-config.yaml.apiVersion: core.choreo.dev/v1beta1
-kind: ComponentConfig
-spec:
- # +optional Incoming connection details for the component (AKA endpoints).
- inbound:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
- - name: Greeting Service
- # +required Numeric port value that gets exposed via the endpoint
- port: 9090
- # +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, TCP, UDP.
- type: REST
- # +optional Network level visibility of the endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Public
- # +optional Context (base path) of the API that gets exposed via the endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional The path to the schema definition file. Defaults to wildcard route if not specified.
- # This is only applicable to REST endpoint types.
- # The path should be relative to the Docker context.
- schemaFilePath: greeting_openapi.yaml
- # +optional Outgoing connection details for the component.
- outbound:
- # +optional Defines the service references from the Internal Marketplace.
- serviceReferences:
- # +required Name of the service reference.
- - name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC
- # +required Name of the connection instance.
- connectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412
- # +optional Environment variables injected to the component for connection configuration.
- env:
- # +required Key name of the connection configuration.
- - from: ServiceURL
- # +required Environment variable injected to the container.
- to: SERVICE_URL
-Expose endpoints as managed APIs¶
-
-
-Understand the default component URL¶
-<domain>/<project-name>/<component-name><domain>/<project-name>/<component-name>/<endpoint-name>Change the default endpoint of a component¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Deploy a Containerized Application¶
-
-
-Connect your repository to Choreo¶
-
-
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-GitHub Account
-Your GitHub account or organization. If you want to add another GitHub account, you can expand the list and click + Add.
-
-
-GitHub Repository
-Depending on the repository access you provided, the list will show available repositories to be connected.
-
-
-Branch
-The branch of the repository.
-
-
-Buildpack
-Determines the implementation of the component: Any language or other language as a Docker container.
-
-
-Dockerfile Path
-The path to your Dockerfile. This path is defined relative to the repository root.
-
For example, if the Dockerfile is at the repository root, the value for this field is /Dockerfile.
-
-Docker Context Path
-The Docker build context path. To include the repository root, leave the default
-/ value.
-
-Port*
-The port at which your service is running.
-
-
-
-OpenAPI Filepath*
-The path to an OpenAPI specification (in YAML/JSON) relative to the repository root. If you don't provide a path, the system automatically generates a default allow-all specification.
-
-
-UID) under the USER instruction in your Dockerfile. You can refer to the sample Dockerfile for guidance.
-
-10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Deploy the containerized component¶
-Application configurations¶
-Configuration types
-
-
-Mount types
-
-
-Deployment configurations¶
-Build, deploy, and promote¶
-Troubleshoot security vulnerability scan failures (Trivy)¶
-trivyignore (<docker-build-context-path>/.trivyignore) file to your build context path. In the file, add the CVEs you need the pipeline to ignore, one entry per line as follows:# in front of the comment as follows:
-
-
-
-
-
Deploy an Application with Buildpacks¶
-
-
-Buildpacks¶
-Develop a component¶
-readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Reading Books List Service
-
-
-
-Manual Task
-Hello World Task
-Procfile¶
-Procfile is a configuration file used to declare the commands that are run by your application's containers. Procfile with the web process type in the project root directory.Procfile for an application:web: python main.py
-web: gunicorn --bind :8080 --workers 1 --threads 8 --timeout 0 main:app
-web: flask run --host=0.0.0.0readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Echo Service
-
-
-Manual Task
-Covid19 Statistics To Email
-
-
-Webhook
-Salesforce New Case To Google Sheet
-
-
-
-Scheduled Task
-Shopify New Customers to HubSpot Create/Update Contact
-readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Greeting Service
-
-
-Manual Task
-Hello World Task
-
-
-
-Web Application
-Hello World Web Application
-readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-
-Service
-Greeting Service
-readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Product Management Service
-
-
-
-Manual Task
-Hello World Task
-
-
-Main class should be defined in the manifest file.mvn.cmd exist in the project without the .mvn directory, the build will fail. To ensure a successful build, you must either commit the .mvn directory along with any Maven files or not include any Maven files in the project if you choose not to commit the .mvn directory.Procfile
-Procfile is a configuration file used to declare the commands that are run by your application's containers.
-If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory.
-In Java projects, it is optional to include a Procfile.Procfile for an application:web: java -jar target/sample.jar readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Reading Books List Service
-
-
-
-Manual Task
-Hello World Task
-Procfile
-Procfile is a configuration file used to declare the commands that are run by your application's containers.
-If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory.
-In NodeJS projects, it is optional to include a Procfile.Procfile for an application:web: node app.js readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Hello World Service
-
-
-Manual Task
-Hello World Task
-
-
-
-Web Application
-Hello World Web Application
-Procfile
-Procfile is a configuration file used to declare the commands that are run by your application's containers.
-If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory.
-In PHP projects, it is optional to include a Procfile.Procfile for an application:web:php -S 0.0.0.0:8000 index.php readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-Service
-Hello World Service
-
-
-Manual Task
-Hello World Task
-
-
-
-Web Application
-Hello World Web Application
-Procfile
-Procfile is a configuration file used to declare the commands that are run by your application's containers.
-If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory.
-In Ruby projects, it is optional to include a Procfile.Procfile for an application:web: ruby app.rb
-web:bundle exec ruby app.rb -p 8080 readme.md inside the example.
-
-
-
-
-
-
-Component Type
-Example
-
-
-
-Service
-Hello World Service
-WAR file, it is necessary to include a Procfile.Procfile
-Procfile is a configuration file used to declare the commands that are run by your application's containers.
-If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory.
-In Java projects, it is optional to include a Procfile.Procfile for an application:web: java -jar target/sample.war Configure build-time environment variables¶
-GOOGLE_MAVEN_BUILD_ARGS as the environment key and clean install as the value.
-
-
-
-
-
Develop a Webhook¶
-bug label in a specific repository.
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create a Webhook component¶
-
-
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-GitHub Account
-Your account
-
-
-GitHub Repository
-choreo-samples
-
-
-Branch
-
-main
-
-Buildpack
-Ballerina
-
-
-
-Project Path
-
-github-event-to-email-webhookStep 2: Deploy¶
-
-
-
-
-Step 3: Connect the webhook to the GitHub repository¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Payload URL
-The invoke URL you copied in Step 3, sub-step 1.
-
-
-Content Type
-Select
-application/json
-
-
-Secret
-The last webhook secret you configured in Step 2.
-
-
-Step 4: Test¶
-Bug label in the repository that you connected to the webhook.Step 5: Promote¶
-
-
-
-
-
-
-
-
Develop an API Proxy¶
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create an API proxy¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Display Name
-
-HR API
-
-Name
-
-hr-api
-
-Context
-
-abc-hr
-
-Version
-
-1.0
-
-Target
-
-https://samples.choreoapps.dev/company/hr
-
-
-Access Mode
-External
-Step 2: Define resources for the API proxy¶
-
-
-/department/{departmentId} as the URI Pattern.
-
-
-
-
-
-
-Field
-Value
-
-
-Operation ID
-
-findDepartment
-
-
-Description
-
-Find a department by department ID/*, click the delete icon corresponding to each resource. This marks the resources for deletion.Step 3: Deploy the API proxy¶
-
-
-Step 3: Test the API proxy¶
-
-
-
-
-
-
-
-
-
-GET /department/{departmentId} resource and click Try it Out to test it.1 as the departmentId and click Execute. You will see a response similar to the following:Step 4: Manage the API proxy¶
-Step 4.1: Apply a rate limiting level to the API proxy¶
-
-
-Step 4.2: Publish the API proxy¶
-
-
-Step 5: Invoke the API¶
-
-
-HR API in the Choreo Developer Portal.
-
-
-
-GET /department/{departmentId} resource and click Try it out.1 as the departmentId and click Execute. You will see a response similar to the following:
-
-
-
-
-
Develop Components Using VS Code¶
-Prerequisites¶
-
-
-Get started¶
-
-
-
-
-
Sign In command provided by the Choreo extension.Create a new component¶
-
-
-.choreo/context.yaml file is generated in the root of the Git repository. For more details, see Understand the project context.
-
-Understand the project context¶
-context.yamlfile, resides in the /.choreo directory within the root of the Git repository.context.yaml file and lists the components of the associated project. This allows you to easily open and manage the components they are developing within the VS Code workspace.context.yaml file can contain multiple projects, whereas, a workspace opened via VS Code can have multiple context.yaml files with different project associations. In such cases, VS Code allows you to switch between these projects, add new project associations, or remove existing ones, allowing you as a developer to focus on components of a particular project at a time.context.yaml file to the Git repository. Committing this file enables other team members working on the same repository to have a seamless developer experience with Choreo.context.yaml file for a particular project is not committed to the Git repository or is unavailable for other reasons, you can easily regenerate it using one of the following methods:
-
-
Link Directory command provided by the Choreo extension.Discover additional features¶
-Choreo.Troubleshoot issues¶
-
-
-Get help¶
-
-
-
-
-
-
Develop Components With Git¶
-
-
-Connect a Git repository to Choreo¶
-
-
-Authorize GitHub with Choreo¶
-
-
-
-
-
-
-
-Permission
-Read
-Write
-Description
-
-
-Issues
-Y
-N
-Read component ID label to filter the pull requests
-
-
-Metadata
-Y
-N
-List repositories
-
-
-Contents
-Y
-Y
-List branches and create a branch to commit sample code
-
-
-Pull Request
-Y
-Y
-Create a pull request if you start with a Choreo sample
-
-
-
-Webhooks
-Y
-Y
-Trigger automatic deployment and configuration generation
-Add Git submodules to a project¶
-
-
-
-
-
-
-
-
-Authorize Bitbucket with Choreo¶
-
-
-
-
-
-
-
-Permission
-Read
-Write
-Description
-
-
-Account
-Y
-N
-Get user information and workspace details
-
-
-Repositories
-Y
-Y
-List branches and create a branch to commit sample code
-
-
-Pull Requests
-Y
-Y
-Create a pull request if you start with a Choreo sample
-
-
-
-Webhooks
-Y
-Y
-Trigger automatic deployment and configuration generation
-Authorize self-managed GitLab with Choreo¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Permission
-Description
-
-
-
-API
-Grants full read/write access to the API, covering all groups and projects, as well as read/write access to the repository.
-
-
-
-
-
-
Develop a Manual Task¶
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.<sample-repository-dir>/weather-to-email-integration directory. To understand how the functionality is implemented, you must read the code comments. The following table describes what you will find in each file in the repository:
-
-
-
-
-
-
-File path
-File content
-
-
-Ballerina.toml
-Contains metadata about the project
-
-
-Dependencies.toml
-Lists the dependencies required for the project
-
-
-main.bal
-Contains the entry point of the project, including the main function
-
-
-types.bal
-Contains custom data types used in the project
-
-
-
-utils.bal
-Contains utility functions and helper functions used in the project
-Step 1: Create a manual task component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Name
-
-WeatherToEmail
-
-
-Description
-
-My first manual task
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-
-choreo-samples
-
-Branch
-
-main
-
-Buildpack
-Ballerina
-
-
-
-Project Directory
-
-weather-to-email-integration
-
-Step 2: Build the manual task¶
-
-
-Step 3: Deploy the manual task¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-apiKey
-The API key you obtained in the prerequisites section
-
-
-latitude
-Latitude of the location to get the weather forecast
-
-
-longitude
-Longitude of the location to get the weather forecast
-
-
-
-email
-The email address to receive the formatted weather forecast information
-Step 4: Execute the manual task¶
-
-
-
-
-readme.md file in the sample repository.CMD. In such scenarios, you must use ENTRYPOINT to define your default commands. readme.md file in the sample repository.readme.md file in the sample repository.
-
-Procfile is available in the project.Main class should be defined in the manifest file.mvn.cmd exist in the project without the .mvn directory, the build will fail. To ensure a successful build, you must either commit the .mvn directory along with any Maven files or not include any Maven files in the project if you choose not to commit the .mvn directory.readme.md file in the sample repository.
-
-Procfile is available in the project.package.json file with the main attribute defined.readme.md file in the sample repository.Step 5: Test the manual task¶
-[WSO2 Choreo Demo] Next 24H Weather Forecast is sent from choreo.demo@gmail.com to the email address specified as the email configurable variable value in Step 3. Step 6: Observe the manual task¶
-
-
-Step 7: Monitor executions¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Develop a Scheduled Task¶
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.<sample-repository-dir>/weather-to-email-scheduled-task directory. To understand how the functionality is implemented, you must read the code comments. The following table describes what you will find in each file in the repository:
-
-
-
-
-
-
-File path
-File content
-
-
-Ballerina.toml
-Contains metadata about the project
-
-
-Dependencies.toml
-Lists the dependencies required for the project
-
-
-main.bal
-Contains the entry point of the project, including the main function
-
-
-types.bal
-Contains custom data types used in the project
-
-
-
-utils.bal
-Contains utility functions and helper functions used in the project
-Step 1: Create a scheduled task component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Name
-
-WeatherToEmail
-
-
-Description
-
-My first scheduled task
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-
-choreo-samples
-
-Branch
-
-main
-
-Buildpack
-Ballerina
-
-
-
-Project Directory
-
-weather-to-email-scheduled-task
-
-
-
-
-Step 2: Build the scheduled task¶
-
-
-Step 3: Deploy the scheduled task¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-apiKey
-The API key you obtained in the prerequisites section
-
-
-latitude
-Latitude of the location to get the weather forecast
-
-
-longitude
-Longitude of the location to get the weather forecast
-
-
-
-email
-The email address to receive the formatted weather forecast information
-
-
-
-
-
-
-
-Field
-Value
-
-
-Select Time Zone
-Select a time zone to schedule the task
-
-
-Select Range
-Day
-
-
-Every
-
-1
-
-
-At
-
-08:00Step 4: Test the scheduled task¶
-[WSO2 Choreo Demo] Next 24H Weather Forecast is sent from choreo.demo@gmail.com to the email address specified as the email configurable variable value in Step 3.Step 5: Observe the scheduled task¶
-
-
-Step 6: Monitor executions¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Develop an Event Handler¶
-Prerequisites¶
-
-
-
-
-Stark Industries.username, hostname, password, and vhost from the RabbitMQ instance to use later as environment variables.Step 1: Create an event handler component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Name
-
-SalesOrderListener
-
-
-Description
-
-RabbitMQ integration
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-
-choreo-samples
-
-Branch
-
-main
-
-Buildpack
-WSO2 MI because you are creating the REST API from a WSO2 Integration Studio project
-
-
-
-Project Directory
-
-mi-rabbitmq-listener
-
-
-
-
-Step 2: Deploy the integration¶
-
-
-
-
-
-
-
-
-
-Name
-Value
-
-
-HOSTNAME
-Hostname of your RabbitMQ server
-
-
-VHOST
-Virtual hostname of your RabbitMQ server
-
-
-USERNAME
-Username for connecting to RabbitMQ
-
-
-
-PASSWORD
-Password associated with the RabbitMQ username
-Step 3: Test the integration¶
-
-
-
-
-
-
-
-
-
-
-
-
Develop an Integration with Integration Studio¶
-
-
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create the integration component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Name
-
-Hello World
-
-
-Description
-
-Hello World REST API
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-
-choreo-samples
-
-Branch
-
-main
-
-Buildpack
-WSO2 MI because you are creating the REST API from a WSO2 Integration Studio project
-
-
-
-Project Directory
-
-hello-world-miStep 2: Deploy the integration component¶
-
-
-Step 3: Test the integration¶
-
-
-{"Hello" : "Integration"}Step 4: Observe the integration¶
-
-
-Step 5: Publish the integration component¶
-
-
-
-
-
-
-
-
Develop a Ballerina Service¶
-
-
-greet that accepts a single query parameter as input.
-
-$ curl GET http://localhost:9090/greeter/greet?name=Ballerina$ hello Ballerina!Prerequisites¶
-
-
-
-
-Stark Industries.Ballerina.Learn the repository file structure¶
-<sample-repository-dir>/greeting-service.
-
-
-
-
-
-
-Filepath
-Description
-
-
-
-service.balThe greetings service code written in the Ballerina language.
-
-
-
-tests/service_test.balTest files related to the
-service.bal file.
-
-
-
-Ballerina.tomlThe Ballerina configuration file.
-Step 1: Create a service component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Ballerina Greetings
-
-Component Name
-
-ballerina-greetings
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-samples
-
-
-
-Branch
-
-main/greeting-service.Step 2: Build and deploy¶
-Ballerina.toml file matches the distribution version specified in the Dependencies.toml file.Step 2.1: Build¶
-
-
-Step 2.2: Deploy¶
-
-
-Manage the deployment¶
-
-
-
-
-
-
Develop a Service with Docker¶
-
-
-greet that accepts a single query parameter as input.Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<sample-repository-dir>/greeting-service-go
-
-
-
-
-
-
-Filepath
-Description
-
-
-
-main.goThe Go-based greeter service code.
-
-
-
-DockerfileThe Dockerfile to build the container image of the application.
-
-
-
-.choreo/endpoints.yamlChoreo-specific configuration that provides information about how Choreo exposes the service.
-
-
-
-
-openapi.yamlThe OpenAPI contract of the greeter service. This is required to publish the service as a managed API. This
-openapi.yaml file is referenced by the .choreo/endpoints.yaml file.Configure the service port with endpoints¶
-endpoints.yaml file inside the .choreo directory. Be sure to place the .choreo directory at the root of the Docker build context path.endpoints.yaml file is in the greeting-service-go/.choreo/ directory. Step 1: Create a service component from a Dockerfile¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Greetings
-
-Component Name
-
-greetings
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-samples
-
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-/greeting-service-go
-
-
-Dockerfile
-
-/greeting-service-go/Dockerfile
-
-
-
-10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Step 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-
-
-Step 2.2: Deploy¶
-
-
-
-
-
-
-
-
Develop a Service¶
-
-
-greet that accepts a single query parameter as input.Go buildpack. The service will run on port 9090.Prerequisites¶
-
-
-
-
-Stark Industries.Go.Learn the repository file structure¶
-<sample-repository-dir>/greeting-service-go
-
-
-
-
-
-
-Filepath
-Description
-
-
-
-main.goThe Go-based greeter service code.
-
-
-
-.choreo/endpoints.yamlChoreo-specific configuration that provides information about how Choreo exposes the service.
-
-
-
-
-openapi.yamlThe OpenAPI contract of the greeter service. This is required to publish the service as a managed API. This
-openapi.yaml file is referenced by the .choreo/endpoints.yaml file.Configure the service port with endpoints¶
-endpoints.yaml file inside the .choreo directory. Be sure to place the .choreo directory at the root of the Docker build context path.endpoints.yaml file is in the greeting-service-go/.choreo/ directory. Step 1: Create a service component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Greetings
-
-Component Name
-
-greetings
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-choreo-samples
-
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Go Project Directory
-
-/greeting-service-go
-
-
-Language Version
-1.x
-Step 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-Greetings component you created. This takes you to the component overview page.Step 2.2: Deploy¶
-
-
-
-
-
-
-
-
Expose a Ballerina GraphQL Endpoint via a Service¶
-Queries¶
-status, which filters the reading list by reading status. Accepted values for status are reading, read, and to_read.$ curl -X POST -H "Content-Type: application/json" -d '{"query": "query {allBooks (status: \"reading\") { id title author status }}"}' http://localhost:8090
-$ {
- "data": {
- "allBooks": [
- {
- "id": 1,
- "title": "Sample Book",
- "author": "Test Author",
- "status": "to_read"
- }
- ]
- }
-}
-id, which will select the book item from the reading list by book id. The id is an Integer value. $ curl -X POST -H "Content-Type: application/json" -d '{"query": "query {book (id: 1) { id title author status }}"}' http://localhost:8090
-$ {
- "data": {
- "book": {
- "id": 1,
- "title": "Sample Book",
- "author": "Test Author",
- "status": "to_read"
- }
- }
-}
-Mutations¶
-to_read. This method returns the added book item upon successful execution.$ curl -X POST -H "Content-type: application/json" -d '{ "query": "mutation { addBook(book: {title: \"Sample Book\", author: \"Test Author\"}) { id title author status } }" }' 'http://localhost:8090'
-$ {
- "data": {
- "addBook": {
- "id": 1,
- "title": "Sample Book",
- "author": "Test Author",
- "status": "to_read"
- }
- }
-}
-id and status as inputs to update the reading status of the selected book. The id refers to the id of the book. It is an integer. The status refers to the reading status that needs to be updated. This method returns the updated book item upon successful execution.$ curl -X POST -H "Content-type: application/json" -d '{ "query": "mutation { setStatus(id: 1, status: \"reading\") { id title author status } }" }' 'http://localhost:8090'
-$ {
- "data": {
- "setStatus": {
- "id": 1,
- "title": "Sample Book",
- "author": "Test Author",
- "status": "reading"
- }
- }
-}
-id as the input to delete the book item from the reading list. This method returns the removed book item upon successful execution.$ curl -X POST -H "Content-type: application/json" -d '{ "query": "mutation { deleteBook(id: 1) { id title author status } }" }' 'http://localhost:8090'
-$ {
- "data": {
- "deleteBook": {
- "id": 1,
- "title": "Sample Book",
- "author": "Test Author",
- "status": "reading"
- }
- }
-}
-Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<sample-repository-dir>/reading-list-graphql.
-
-
-
-
-
-
-Filepath
-Description
-
-
-
-service.balThe reading list service code written in the Ballerina language.
-
-
-
-Ballerina.tomlThe Ballerina configuration file.
-
-
-
-
-.choreo/endpoints.yamlThe configuration file with endpoint details.
-Step 1: Create a service component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Ballerina Reading List
-
-Component Name
-
-ballerina-reading-list
-
-
-Description
-Manage a reading list
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-
-Ballerina Project Directory
-
-reading-list-graphqlStep 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-Step 2.2: Deploy¶
-
-
-
-
-
-
-
-
Expose a gRPC Endpoint via a Service¶
-
-
-sayHello. Following is the proto file the server and the client application are using:Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<sample-repository-dir>/go-grpc.
-
-
-
-
-
-
-File Path
-Description
-
-
-
-main.goThe greeter service code written in the Go language.
-
-
-
-greeter_client/main.goThe greeter client application written in the Go language.
-
-
-
-Dockerfile.serverThe Dockerfile to build the container image of the server application.
-
-
-
-Dockerfile.clientThe Dockerfile to build the container image of the client application.
-
-
-
-.choreo/endpoints.yamlThe Choreo-specific configuration that provides information about how Choreo exposes the service.
-
-
-
-
-pkg/greeter.protoThe interface definition of the gRPC service. This is used to generate the server and client stubs for the Go application.
-Configure the service port with endpoints¶
-endpoints.yaml file inside the .choreo directory to configure the endpoint details of the containerized component. Ensure the .choreo directory is at the root of the Docker build context path.endpoints.yaml file is at go-grpc/.choreo/endpoints.yaml, where the build context path is go-grpc.Step 1: Create a service component with a gRPC endpoint¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go gRPC Server
-
-Component Name
-
-go-grpc-server
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-go-grpc
-
-
-Dockerfile
-
-go-grpc/Dockerfile.server
-
-
-
-10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Step 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-
-
-Step 2.2: Deploy¶
-
-
-Step 3: Invoke the gRPC service¶
-Step 3.1: Create a manual task for the gRPC client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go gRPC Client
-
-Component Name
-
-go-grpc-client
-
-
-Description
-
-Receive greetings
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-go/grpc
-
-
-Dockerfile
-
-go/grpc/Dockerfile.clientStep 3.2: Build the gRPC client component¶
-
-
-Step 3.3: Setup environment variables and deploy the gRPC client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-
-GREETER_SERVICE
-
-
-Value
-Paste the URL value copied after deploying the gRPC service via step 2.2 above. Make sure to drop the
-http:// or grpc:// part and the trailing / from the URL when copying. For example, if the URL is http://go-grpc-server-3192360657:8080/, add only go-grpc-server-3192360657:8080.Step 3.4: Execute the gRPC client component¶
-
-
-
-
-
-
-
-
Expose a TCP Server via a Service¶
-
-
-
-
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<sample-repository-dir>/docker-tcp-service.
-
-
-
-
-
-
-File Path
-Description
-
-
-
-server/main.goThe greeter service code written in the Go language.
-
-
-
-client/main.goThe greeter client application written in the Go language.
-
-
-
-Dockerfile.serverThe Dockerfile to build the container image of the server application.
-
-
-
-Dockerfile.clientThe Dockerfile to build the container image of the client application.
-
-
-
-
-.choreo/endpoints.yamlThe Choreo-specific configuration provides information about how Choreo exposes the service.
-Configure the service port with endpoints¶
-endpoints.yaml file inside the .choreo directory to configure the endpoint details of a containerized component. Place the .choreo directory at the root of the Docker build context path.endpoints.yaml file is at docker-tcp-service/.choreo/endpoints.yaml, where the build context path is docker-tcp-service.Step 1: Create a service component with a TCP endpoint¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go TCP Server
-
-Component Name
-
-go-tcp-server
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-docker-tcp-service
-
-
-Dockerfile
-
-docker-tcp-service/Dockerfile.server
-
-
-
-10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Step 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-
-
-Step 2.2: Deploy¶
-
-
-Step 3: Invoke the TCP service¶
-Step 3.1: Create a manual trigger for the TCP client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go TCP Client
-
-Component Name
-
-go-tcp-client
-
-
-Description
-
-Receive greetings
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-docker-tcp-service
-
-
-Dockerfile
-
-docker-tcp-service/Dockerfile.clientStep 3.2: Build the TCP client component¶
-
-
-Step 3.3: Setup environment variables and deploy the TCP client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-
-SERVER_ADDRESS
-
-
-Value
-Paste the URL value copied after deploying the TCP service via step 2.2 above. Make sure to drop the
-tcp:// part and the trailing / from the URL when copying. For example, add only go-tcp-server-1097922445:8080.Step 3.4: Execute the TCP client component¶
-
-
-
-
-
-
-
-
Expose a UDP Server via a Service¶
-
-
-
-
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<sample-repository-dir>/docker-udp-service.
-
-
-
-
-
-
-File Path
-Description
-
-
-
-server/main.goThe greeter service code written in the Go language.
-
-
-
-client/main.goThe greeter client application written in the Go language.
-
-
-
-Dockerfile.serverThe Dockerfile to build the container image of the server application.
-
-
-
-Dockerfile.clientThe Dockerfile to build the container image of the client application.
-
-
-
-
-.choreo/endpoints.yamlThe Choreo-specific configuration provides information about how Choreo exposes the service.
-Configure the service port with endpoints¶
-endpoints.yaml file inside the .choreo directory to configure the endpoint details of a containerized component. Place the .choreo directory at the root of the Docker build context path.endpoints.yaml file is at docker-udp-service/.choreo/endpoints.yaml, where the build context path is docker-udp-service.Step 1: Create a service component with a UDP endpoint¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go UDP Server
-
-Component Name
-
-go-udp-server
-
-
-Description
-Send greetings
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-docker-udp-service
-
-
-Dockerfile
-
-docker-udp-service/Dockerfile.server
-
-
-
-10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Step 2: Build and deploy¶
-Step 2.1: Build¶
-
-
-
-
-Step 2.2: Deploy¶
-
-
-Step 3: Invoke the UDP service¶
-Step 3.1: Create a manual trigger for the UDP client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-
-Go UDP Client
-
-Component Name
-
-go-udp-client
-
-
-Description
-
-Receive greetings
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-GitHub Repository
-
-choreo-samples
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-Docker Context
-
-docker-udp-service
-
-
-Dockerfile
-
-docker-udp-service/Dockerfile.clientStep 3.2: Build the UDP client component¶
-
-
-Step 3.3: Setup environment variables and deploy the UDP client¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-
-SERVER_ADDRESS
-
-
-Value
-Paste the URL value copied after deploying the UDP service via step 2.2 above. Make sure to drop the
-udp:// part and the trailing / from the URL when copying. For example, add only go-udp-server-1097922445:8080.Step 3.4: Execute the UDP client component¶
-
-
-
-
-
-
-
-
Service Component Overview¶
-What is a service component?¶
-
-
-
-
-
-
-
-Field
-Description
-
-
-Name
-A unique identifier for the endpoint within the service component.
-
-
-Port
-The network port on which the endpoint is accessible.
-
-
-Type
-The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP.
-
-
-Network Visibility
-Determines the level of visibility of an endpoint. Possible values are:
-
-
-Schema
-Specifies the structure and format of the data exchanged through the endpoint.
-
-
-
-Context (HTTP and GraphQL only)
-A context path that you add to the endpoint's URL for routing purposes.
-Configure endpoints¶
-Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.Configure endpoints with buildpacks (except Ballerina)¶
-endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.endpoints.yaml file.Configure endpoints with the Ballerina buildpack¶
-Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.endpoint.yaml file to define dynamic endpoint parameters.endpoints.yaml file.Learn the endpoints.yaml file¶
-endpoints.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-version
-Required
-The version of the
-endpoints.yaml file.
-
-name
-Required
-A unique name for the endpoint, which Choreo will use to generate the managed API.
-
-
-port
-Required
-The numeric port value that gets exposed via this endpoint.
-
-
-type
-Required
-The type of traffic this endpoint is accepting, such as
-REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type.
-
-networkVisibility
-Required
-The network level visibility of this endpoint, which defaults to
-Public if not specified. Accepted values are Project, Organization, or Public.
-
-context
-Required
-The context (base path) of the API that Choreo exposes via this endpoint.
-
-
-
-schemaFilePath
-Required
-The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context.
-Sample endpoints.yaml
-
-
-docker-build-context-path should be replaced with component-root.
-For example: <component-root>/.choreo/endpoints.yamldocker-build-context-path should be replaced with <Project Path>.
-For example: <Project Path>/.choreo/endpoints.yaml# +required Version of the endpoint configuration YAML
-version: 0.1
-
-# +required List of endpoints to create
-endpoints:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
-- name: Greeting Service
- # +required Numeric port value that gets exposed via this endpoint
- port: 9090
- # +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, UDP, TCP
- type: REST
- # +optional Network level visibility of this endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Project
- # +optional Context (base path) of the API that is exposed via this endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional Path to the schema definition file. Defaults to wild card route if not provided
- # This is only applicable to REST endpoint types.
- # The path should be relative to the docker context.
- schemaFilePath: greeting_openapi.yaml
-Apply advanced component connection configurations¶
-component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
-
-component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
-
-endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
-
-component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.Learn the
-component-config.yaml file¶component-config.yaml file has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-apiVersion
-Required
-The version of the
-component-config.yaml file defaults to core.choreo.dev/v1beta1.
-
-kind
-Required
-The resource type of the file defaults to
-ComponentConfig.
-
-spec.inbound
-Optional
-The list of inbound connection configurations.
-
-
-
-spec.outbound
-Optional
-The list of outbound connection configurations.
-Inbound connection configurations (
-spec.inbound)spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.Outbound connection configurations (
-spec.outbound)spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.serviceReferences schema has a specific structure and contains the following details:
-
-
-
-
-
-
-Field
-Required
-Description
-
-
-name
-Required
-A unique name for the service reference.
-
-
-connectionConfig
-Required
-A unique name for the connection instance.
-
-
-env
-Optional
-The list of environment variable mappings that get injected into the container.
-
-
-env.from
-Required
-The key name of the connection configuration.
-
-
-
-env.to
-Required
-The environment variable that gets injected into the container.
-Sample component-config.yaml
-
-
-docker-build-context-path with the component-root.
-For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>.
-For example, <Project Path>/.choreo/component-config.yaml.apiVersion: core.choreo.dev/v1beta1
-kind: ComponentConfig
-spec:
- # +optional Incoming connection details for the component (AKA endpoints).
- inbound:
- # +required Unique name for the endpoint. (This name will be used when generating the managed API)
- - name: Greeting Service
- # +required Numeric port value that gets exposed via the endpoint
- port: 9090
- # +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.
- # Allowed values: REST, GraphQL, GRPC, TCP, UDP.
- type: REST
- # +optional Network level visibility of the endpoint. Defaults to Public
- # Accepted values: Project|Organization|Public.
- networkVisibility: Public
- # +optional Context (base path) of the API that gets exposed via the endpoint.
- # This is mandatory if the endpoint type is set to REST or GraphQL.
- context: /greeting
- # +optional The path to the schema definition file. Defaults to wildcard route if not specified.
- # This is only applicable to REST endpoint types.
- # The path should be relative to the Docker context.
- schemaFilePath: greeting_openapi.yaml
- # +optional Outgoing connection details for the component.
- outbound:
- # +optional Defines the service references from the Internal Marketplace.
- serviceReferences:
- # +required Name of the service reference.
- - name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC
- # +required Name of the connection instance.
- connectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412
- # +optional Environment variables injected to the component for connection configuration.
- env:
- # +required Key name of the connection configuration.
- - from: ServiceURL
- # +required Environment variable injected to the container.
- to: SERVICE_URL
-Expose endpoints as managed APIs¶
-
-
-Understand the default component URL¶
-<domain>/<project-name>/<component-name><domain>/<project-name>/<component-name>/<endpoint-name>Change the default endpoint of a component¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Build and Deploy a Single-Page Web Application¶
-
-
-Prerequisites¶
-
-
-Create a web application¶
-
-
-
-
-package.json engine property. The required Node version must be explicitly set in the build configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-GitHub Account
-Your account
-
-
-GitHub Repository
-choreo-samples
-
-
-
-Branch
-main
-
-
-
-
-
-
-
-Field
-Description
-
-
-Project Directory
-/react-single-page-app
-
-
-Build Command
-
-npm run build
-
-Build Path
-
-build
-
-
-Node Version
-
-18Build your web application¶
-
-
-
-
-Deploy and access your web application¶
-
-
-
-
-Create a short URL for your web application in production¶
-https://{your-short-prefix}.choreoapps.dev structure, where you can select a name of your preference for {your-short-prefix}.
-
-Manage runtime configurations for web applications¶
-process.env stub is available during build time. However, it does not actually read in variables from the runtime. Instead, it is baked into the final JavaScript output during the build process.
-
-
-
-config.js in the public directory of your React application. This file should contain the runtime configuration variables you want to expose to your application, such as API endpoints or feature flags. Let's expose the API URL and a feature flag as follows:window.config = {
-apiUrl: 'https://api.example.com',
- featureFlags: {
- enableNewFeature: true,
- enableExperimentalFeature: false,
- },
-};
-index.html file inside the public directory, add a script tag as follows to include the config.js file inside the tag. The config.js file will be accessible via JavaScript at runtime.
-<!DOCTYPE html>
-<html lang="en">
-<head>
- <meta charset="utf-8" />
- <title>My React App</title>
-</head>
-<body>
- <div id="root"></div>
- <script src="%PUBLIC_URL%/config.js"></script>
-</body>
-</html>
-window.config object available to your app at runtime.
-window.config object as follows:index.html expects the config.js file as in this example).
-https://wso2.com/choreo/docs/devops-and-ci-cd/manage-configurations-and-secrets/#apply-a-file-mount-to-your-container.Limitations¶
-
-
-Troubleshoot a web application¶
-
-
-
-
-
-
-
-
-
-
-public/ as the output directory when it should have been build/.
-
-
-
-
-
Develop Web Applications Locally with Choreo’s Managed Authentication¶
-How local development works in Choreo¶
-/choreo-apis/* and /auth/* are then forwarded to Choreo, while all other requests are forwarded to the locally running web application. The proxy runs on HTTPS using a self-signed certificate, crucial for secure, HTTP-only cookie-based managed authentication. Upon running the proxy, you can access the web application using the proxy's URL and start developing the application locally. You will observe that the behavior of the web application, in terms of the managed authentication functionality, is similar to how it would be after deploying to Choreo.Configure local development¶
-Prerequisites¶
-
-
-
-
-Apply configurations¶
-
-
-Access your web application to develop it locally¶
-Prerequisites¶
-
-
-http://localhost on a specific port.Access your web application locally¶
-
-
-
-
-
-
-
-
-
-
Manage Deployment Tracks for Choreo Components¶
-Create a deployment track¶
-
-
-
-
-
-
-Unlink a deployment track¶
-
-
-Link a deployment track¶
-
-
-
-
-Relink a deployment track¶
-
-
-
-
-Sample Scenario: Manage version releases with deployment tracks¶
-
-
-feature-x from either the main or dev branch.feature-x branch into the dev branch for testing.dev branch, the developer proceeds to merge all the changes into the main branch for production deployment.
-
-main branch from the associated deployment track (let’s consider this as the deployment track 1).dev branch containing the tested changes into the main branch.dev branch from the associated deployment track (let’s consider this as deployment track 2).main branch for deployment.dev branch.
-
-dev to ensure a continuous development and release cycle.Delete a deployment track¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Manage the Micro Integrator Runtime Version in Your Integration Project¶
-Understand the version string¶
-4.1.0 and 4.2.0, following semantic versioning principles. The product remains committed to receiving updates from WSO2, including security fixes, bug resolutions, and enhancements. Within the Choreo platform, the MI runtime version is constructed by combining the product release version with its corresponding update level.4.1.0.14 or 4.2.0.17. The first three digits represent the product release version, while the last digit signifies the update level of the product. The fourth digit is optional and can be omitted.Version management in WSO2 Integration Studio¶
-
pom.xml file holds crucial information about the target runtime. The runtime version you configure when you create a new project is saved within the root pom.xml file. The version information is stored in the pom.xml file. If there is a need to update the runtime version, you have the flexibility to modify the value to a valid runtime version and ensure that the project runs in the required runtime environment.Configure a Micro Integrator runtime environment in Integration Studio¶
-
-
-
WSO2 directory and select WSO2 Remote Server.
- 
9164. If you have not manually changed the default port, you must set the Management API URL as https://localhost:9164/management. If you have changed the default HTTPS port, you must set the port number appropriately when specifying the Server URL. For more information on the default ports of WSO2 Micro Integrator, see WSO2 Micro Integrator default ports in the WSO2 API Manager documentation.Convention for version interpretation in Choreo deployments¶
-
-
-
-
-
-
-
-Version format
-Example
-Description
-
-
-Product version
-
-4.1.0, 4.2.0Deploy on the latest update level of the mentioned product version.
-
-
-Product version with update level
-
-4.1.0.15, 4.2.0.17Deploy on the exact update level of the mentioned product version.
-
-
-GA version
-
-4.1.0.0, 4.2.0.0Deploy on the exact GA version without any update.
-
-
-
-Default version
-Empty value
-Deploy on the latest update level of the default product version.
-Migrate between runtime versions¶
-Update the runtime version in the integration project¶
-
-3. Specify the new runtime version as shown below:
-
-4. Alternatively, you can manually update the version by opening the root pom.xml file. Open pom.xml and change the required runtime version in <project.runtime.version> element under <properties> section.
-
-
Troubleshoot errors¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Error code
-Description
-
-
-110 - 119
-Internal server error.
-
-
-121
-Malformed runtime version.
-
-
-122
-The specified runtime version is not available. Either the product or update level is not available.
-
-
-123
-Trivy security vulnerabilities found in the
-libs directory.
-
-124
-Trivy security vulnerabilities found in the
-dropins directory.
-
-125
-Trivy security vulnerabilities found in the
-libs or dropins directory.
-
-
-126
-Error building integration project.
-
-
-
-
-
-
Create a Connection¶
-
-
-
-
-
-
-
-
-
-
Use a Connection in Your Service¶
-Consume a service through a connection¶
-Step 1: Add connection configurations¶
-
-
-component-config file under the spec section.outbound:
- serviceReferences:
- - name: <SERVICE_NAME>
- connectionConfig: <CONNECTION_ID>
- env:
- - from: ServiceURL
- to: <YOUR_ENV_VARIABLE_NAME_HERE>
- - from: ConsumerKey
- to: <YOUR_ENV_VARIABLE_NAME_HERE>
- - from: ConsumerSecret
- to: <YOUR_ENV_VARIABLE_NAME_HERE>
- - from: TokenURL
- to: <YOUR_ENV_VARIABLE_NAME_HERE>
-
-
-
-
-
-
-
-Field
-Description
-
-
-Name
-The name of the service you are connecting to.
-
-
-ConnectionConfig
-The unique connection identifier for the connection.
-
-
-env
-The environment variable mapping.
-
-
-from
-The key of the configuration entry.
-
-
-
-to
-The environment variable name to which Choreo will inject the value of the key.
-<YOUR_ENV_VARIABLE_NAME_HERE> with an appropriate environment variable name of your choice. If you have previously added an outbound service reference, append this as another item under serviceReferences.
-
-
-
-
-
-
-Name
-Type
-Description
-Optional
-Sensitive
-
-
-ServiceURL
-string
-Service URL of the Choreo service
-false
-false
-
-
-ConsumerKey
-string
-Consumer key of the Choreo service
-false
-false
-
-
-ConsumerSecret
-string
-Consumer secret of the Choreo service
-false
-true
-
-
-
-TokenURL
-string
-Token URL of the STS
-false
-false
-Step 2: Read configurations within the application¶
-Step 3: Acquire an OAuth 2.0 access token¶
-
-
-CONSUMER_KEY="your_consumer_key"
-CONSUMER_SECRET="your_consumer_secret"
-TOKEN_URL="your_token_url"
-
-# Encode client credentials as Base64
-CLIENT_CREDENTIALS=$(echo -n "$CLIENT_ID:$CLIENT_SECRET" | base64)
-
-curl -X POST $TOKEN_URL \
- -H "Content-Type: application/x-www-form-urlencoded" \
- -H "Authorization: Basic $CLIENT_CREDENTIALS" \
- --data-urlencode "grant_type=client_credentials"
-Step 4: Invoke the Service¶
-
-
-
-
-
-
-
-
- const response = await axios.get(serviceURL/{RESOURCE_PATH}, {
- headers: {
- 'Authorization': `Bearer ${accessToken}`
- }
-});
-
-
-
-
-
-
Use a Connection in Your Web Application¶
- Step 1: Add the connection configuration
-
-
-config.js) and add the configuration provided in the in-line developer documentation into it. config.js file via JavaScript at runtime, add a script tag as follows in the index.html file to reference the config.js file:<!DOCTYPE html>
-<html lang="en">
-<head>
- <meta charset="utf-8" />
- <title>My React App</title>
-</head>
-<body>
- <div id="root"></div>
- <script src="%PUBLIC_URL%/config.js"></script>
-</body>
-</html>
- Step 2: Read the configuration
- Step 3: Invoke the service
- Step 1: Add the connection configuration
-config.js) and add the following configuration into it. window.configs = {
- apiUrl: '<SERVICE_URL>',
- consumerKey: '<CONSUMER_KEY>',
- consumerSecret: '<CONSUMER_SECRET>',
- tokenUrl: '<TOKEN_URL>',
- };
- Step 2: Read the configuration
- Step 3: Acquire an OAuth 2.0 access token
-
-
-CONSUMER_KEY="your_consumer_key"
-CONSUMER_SECRET="your_consumer_secret"
-TOKEN_URL="your_token_url"
-
-# Encode client credentials as Base64
-CLIENT_CREDENTIALS=$(echo -n "$CLIENT_ID:$CLIENT_SECRET" | base64)
-
-curl -X POST $TOKEN_URL \
--H "Content-Type: application/x-www-form-urlencoded" \
--H "Authorization: Basic $CLIENT_CREDENTIALS" \
---data-urlencode "grant_type=client_credentials"
- Step 4: Invoke the service
-
-
-
-
-
-
-
-
Work with the Micro Integrator Runtime in Choreo¶
-Integration types¶
-
-
-Develop integrations with WSO2 Integration Studio¶
-Integration project directory structure¶
-
-
-
-
-OpenAPI support¶
-Work with third-party libraries¶
-
-
-libs at the
-root of your project. If your project root and GitHub repository root are not the same, place the libs directory in
-the project root. After adding the required JAR files to the libs directory, the Micro Integrator runtime will
-automatically include them when deploying the component. This process ensures that any dependencies needed by your
-integration flow are available at runtime.jar libraries, you may also need to incorporate OSGi bundle JARs into your project. To do this,
-create another directory called dropins at the root of your project. Similarly, if the project root and GitHub
-repository root differ, place the dropins directory in the project root. Within the dropins directory, add the OSGi
-bundle JAR files. The OSGI runtime will pick up these bundles during deployment, enabling you to utilize their
-functionality within your Micro Integrator project.Importing custom certificates to MI¶
-client-truststore.jks file. This functionality
-proves valuable when users need to establish connections with servers or services utilizing SSL/TLS encryption and
-possessing self-signed certificates or certificates issued by private certificate authorities (CAs) that are not
-automatically trusted. Importing the certificate to the MI client-truststore.jks file enables MI clients to establish secure connections with
-the server or service seamlessly, eliminating SSL/TLS errors or warnings./wso2mi/certs/ folder. Users need to verify that the mount path for the certificate file aligns with this
-specific path.
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Config Name
-An appropriate name for the certificate.
-
-
-
-Mount path
-
-/wso2mi/certs/<filename>. For example, /wso2mi/certs/certificate.crtWorking with sensitive data using MI Secure Vault¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-An appropriate name for the secret/alias.
-
-
-
-Value
-Value for the secret
-<property name="secret_value_1" expression="wso2:vault-lookup('user_pass')" scope="default" type="STRING"/>
-Scan third-party libraries to identify security vulnerabilities¶
-Customize WSO2 Micro Integrator preconfigured settings¶
-deployment.toml file in the GitHub repository subpath of your Micro Integrator project:deployment.toml file that can be used to configure the JMS transport. For more information on WSO2 MI
-configuration parameters, see the MI Config Catalog.[[transport.jms.sender]]
-name = "myQueueSender"
-parameter.initial_naming_factory = "org.apache.activemq.jndi.ActiveMQInitialContextFactory"
-parameter.provider_url = "$env{JMS_PROVIDER_URL}"
-parameter.connection_factory_name = "QueueConnectionFactory"
-parameter.connection_factory_type = "queue"
-parameter.cache_level = "producer"
-
-[[transport.jms.listener]]
-name = "myQueueListener"
-parameter.initial_naming_factory = "org.apache.activemq.jndi.ActiveMQInitialContextFactory"
-parameter.provider_url = "$env{JMS_PROVIDER_URL}"
-parameter.connection_factory_name = "QueueConnectionFactory"
-parameter.connection_factory_type = "queue"
-parameter.cache_level = "consumer"
-Environment variables¶
-
-
-Configure logging¶
-
-
-logging_level_ followed by the package or class name.org.apache.synapse.transport.http.wire package to debug.
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Config Name
-An appropriate name for the configuration.
-
-
-Name
-
-logging_level_org_apache_synapse_transport_http_wire
-
-
-Value
-
-debugConnectors¶
-Deploying integrations in Choreo¶
-
-
-endpoints.yaml configuration file. Place this file in the .choreo directory in the project path of the component.
-If the Micro Integrator project has inbound endpoints, you can expose them via different endpoints using the endpoints.yamlendpoints.yaml file.endpoints.yaml is not provided and if the source Micro Integrator project has APIs, Choreo scans the project and generates the API endpoints. If the project has few APIs, an endpoint will be generated for each API. The visibility of this auto-generated endpoint is set to Public by default. You can change the visibility in the deployment flow.endpoints.yaml is not provided and if the source Micro Integrator project doesn't have APIs, Choreo generates a default endpoint which will expose the default micro integrator port (8290) with Public visibility and wildcard context.Explore Choreo examples on GitHub¶
-WSO2 MI. This will point you to the samples in the Choreo samples GitHub repositoryChoreo samples - GitHub Repository¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Autoscale Component Replicas¶
-
-
-2.5. There is no restriction on the value in private data planes.3 replicas for a component, you must set the minimum and maximum replicas to 3.
-
-0, your component does not scale to zero automatically during low usage. It can only go down to 1 replica.0 suspends the deployment.
-
-
-
-
-
Autoscale Components with Scale-to-Zero¶
-How Scale to Zero works in Choreo¶
-Enable scale to zero¶
-
-
-
-
-
-
-Limitations¶
-
-
-Host not found, not forwarding request.Architecture¶
-Troubleshooting¶
-
-
-
-
-
-
Configure Container Resources, Commands, and Arguments¶
-Update container configurations¶
-
-
-Update resource requests and limits¶
-Set the image pull policy¶
-
-
-Specify container ports¶
-Define a command and arguments for the container¶
-ENTRYPOINT of a container. For example, in a scenario where you want to run legacy or third-party applications, you would want to provide or override the ENTRYPOINT of a container.
-
-ENTRYPOINT array and it is not executed within a shell. $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged.$$ are reduced to $, which allows escaping the $(VAR_NAME) syntax. This means that "$$(VAR_NAME)" produces the string literal "$(VAR_NAME)". ENTRYPOINT of the container image is used if you do not define a command and arguments for the container.
-
-
-
-
-
Configure Storage¶
-Volume mount types¶
-
-
-
-
-
-
-
-Type
-Description
-
-
-Empty Directory (In-Memory)
-A fast, temporary in-memory (tmpfs) storage location. This volume gets erased when you restart or remove the attached container. Available on all data planes.
-
-
-Empty Directory (Disk)
-A temporary storage location on disk. This volume gets destroyed when you restart or remove the attached container. Only available on private data planes.
-
-
-
-Persistent Volume
-A permanent storage location. This volume persists even if you restart or remove the attached container. Only available on private data planes.
-/tmp directory at the time of component creation. You can also configure other writable locations if required.Create a temporary storage space for your container¶
-
-
-
-
-
-
-Uncontrolled writes to this location may starve your application process of memory and can result in the container getting killed and restarted if the memory limits exceed.
-
-Create a persistent storage space for your container¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Configure VPNs on the Choreo Cloud Data Plane¶
-
-
-
-
-
-
-Configure and use Tailscale to access private network endpoints¶
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create the Tailscale proxy¶
-Step 1.1: Create a project
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Display Name
-Tailscale Proxy Project
-
-
-Name
-tailscale-proxy-project
-
-
-
-Project Description
-My Tailscale project
-Step 1.2: Create the Tailscale proxy component
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-Tailscale proxy
-
-
-Component Name
-tailscale-proxy
-
-
-
-Description
-Tailscale proxy component
-Step 2: Configure and deploy the Tailscale proxy¶
-Step 2.1: Add required volume mounts
-
-
-/var/run/tailscale/.localStep 2.2: Configure and deploy the component
-
-
-TS_AUTH_KEY environment variable as a secret. To add the environment variable, you must obtain an authentication key from your Tailscale network.
-
-
-
-/config.yaml as the Mount Path.endpoints.yaml configuration to expose your Tailscale proxy as a service. The following is a sample endpoints.yaml configuration you can use:endpoints.yaml file given below defines two project-level endpoints. These endpoints can be used by other components within the same project to access the services. If you want to directly expose your private endpoint via the Choreo gateway either with the Public or Organization visibility, you can set the networkVisibility property of the endpoint to Public or Organization.Step 3: Access private network endpoints with the Tailscale proxy¶
-Post-deployment actions¶
-Handle node key expiry¶
-Handle auth key expiry¶
-Update port mapping configurations¶
-Best practices¶
-Configure health checks¶
-Use Tailscale ACLs¶
-Disable scale-to-zero for the Tailscale proxy¶
-Run multiple replicas with HPA (horizontal pod autoscaler)¶
-Security best practices¶
-Troubleshoot issues¶
-
-
-
-
-
-
Manage Configurations and Secrets¶
-The difference between configurations and secrets¶
-
-
-Apply a file mount to your container¶
-
-
-Apply environment variables to your container¶
-
-
-Update an existing configuration or secret¶
-
-
-Delete an existing configuration or secret¶
-
-
-Manage Ballerina configurables¶
-
-
-
-
-
-
Manage Environments¶
-Create a new environment¶
-Prerequisites¶
-
-
-ENVIRONMENT-MANAGEMENT permission. By default, ENVIRONMENT-MANAGEMENT permission is granted to Admin and Choreo DevOps roles.
-
-
-
-Change the order of promotion¶
-
-
-Delete an environment¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Set Up Health Checks¶
-Liveness probes¶
-Readiness probes¶
-Probe types¶
-HTTP
-GET request¶GET request to a specified port and path on the container. A response status code in the range of 200-399 indicates that the request is a success./healthz or /health endpoint in your service for this purpose.TCP connection probe¶
-Execute a command¶
-["cat", "/tmp/healthy"] is considered healthy if the file /tmp/healthy is present. If not, it becomes a failure (non-zero exit code).
-In such scenarios, the application is responsible for writing and maintaining this file in the specified location.Configure liveness and readiness probes¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
View Runtime Details¶
-
-
-
-Redeploy a release¶
-View running instances¶
-
-
-
-
-Observe real-time container logs¶
-
-
-View container conditions and events¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Billing for Platform Services (Databases and Caches)¶
-
-
-
-
-
-
-
-
Choreo-Managed Cache¶
-Create a Choreo-Managed Cache¶
-
-
-
-
-
-
-
-
-Connect to your Choreo-Managed Cache¶
-
-
-High availability and automatic backups¶
-
-
-
-
-
-
-
-Service plan
-High availability
-Backup features
-Backup history
-
-
-Hobbyist
-Single-node with limited availability.
-Single backup only for disaster recovery
-None
-
-
-Startup
-Single-node with limited availability.
-Single backup only for disaster recovery
-1 day
-
-
-Business
-Two-node (primary + standby) with higher availability (automatic failover if the primary node fails).
-Automatic backups
-3 days
-
-
-
-Premium
-Three-node (primary + standby + standby) with highest availability (automatic failover if the primary node fails).
-Automatic backups
-13 days
-
-
-Automatic backups¶
-
-
-Failure recovery¶
-
-
-
-
-Limitations¶
-Connection limits¶
-m represents the memory in megabytes, where at least 10,000 connections are available, even on the smallest servers.
-For example, on a server with 4GB memory (4,096 MB), the simultaneous connections are:Restricted commands¶
-
-
-EVAL, EVALSHA, and SCRIPT LOAD commands.EVAL, EVALSHA, and SCRIPT LOAD commands are enabled by default.
-
-bgrewriteaof: Initiates a background append-only file rewrite.cluster: Manages Caching cluster commands.command: Provides details about all Caching commands.debug: Contains sub-commands for debugging Caching.failover: Manages manual failover of a master to a replica.migrate: Atomically transfers a key from one caching instance to another.role: Returns the role of the instance in the context of replication.slaveof: Makes the server a replica of another instance, or promotes it as master.acl: Manages caching access control lists.bgsave: Creates a snapshot of the data set into a dump file.config: Alters the configuration of a running caching server.lastsave: Returns the UNIX timestamp of the last successful save to disk.monitor: Streams back every command processed by the Caching server.replicaof: Makes the server a replica of another instance.save: Synchronously saves the dataset to disk.shutdown: Synchronously saves the dataset to disk and then shuts down the server.eval commands are also disabled:
-
-
-
-
-
-
-
- eval: Executes a Lua script server-side.eval_ro: Read-only variant of the eval command.evalsha: Executes a script cached on the server side by its SHA1 digest.evalsha_ro: Read-only variant of the evalsha command.fcall: Calls a Caching function.fcall_ro: Read-only variant of the fcall command.function: Manages Caching functions.script: Manages the script cache.
-
-
-
-
-
Choreo-Managed Databases, Vector Databases, and Caches¶
-PostgreSQL on Choreo¶
-MySQL on Choreo¶
-Choreo-Managed Cache¶
-
-
-
-
-
-
Choreo-managed MySQL Databases¶
-Create a Choreo-managed MySQL database¶
-
-
-Connect to your Choreo-managed MySQL database¶
-
-
-High Availability and Automatic Backups¶
-
-
-
-
-
-
-
-Service Plan
-High Availability
-Backup Retention Time
-
-
-Hobbyist
-Single-node with limited availability
-None
-
-
-Startup
-Single-node with limited availability
-2 days
-
-
-Business
-Two-node (primary + standby) with higher availability
-14 days
-
-
-
-Premium
-Three-node (primary + standby + standby) with highest availability
-30 days
-Automatic Backups¶
-
-
-Connection Limits¶
-extra_connection with a value of 1 is added for system processes for all MySQL databases, regardless of the service plan.For plans under 4 GiB RAM¶
-75 per GiB:For plans with over 4 GiB RAM:¶
-100 per GiB:
-
-
-
-
-
Choreo-Managed PostgreSQL Databases and Vector Databases¶
-Create a Choreo-managed PostgreSQL database¶
-
-
-
-
-Create a Choreo-managed PostgreSQL vector database¶
-
-
-Connecting to your Choreo-managed PostgreSQL database¶
-
-
-High Availability and Automatic Backups¶
-
-
-
-
-
-
-
-Service Plan
-High Availability
-Backup Retention Time
-
-
-Hobbyist
-Single-node with limited availability
-None
-
-
-Startup
-Single-node with limited availability
-2 days
-
-
-Business
-Two-node (primary + standby) with higher availability
-14 days
-
-
-
-Premium
-Three-node (primary + standby + standby) with highest availability
-30 days
-Automatic Backups¶
-
-
-Failure Recovery¶
-
-
-
-
-
-
-Connection limits¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Service Plan
-Max Connections
-
-
-Hobbyist
-25
-
-
-Startup/Business/Premium-4
-100
-
-
-Business-16
-400
-
-
-
-Premium-8
-200
-
-
-
-
-
-
Configure Alerts¶
-
-
-Latency alerts¶
-
-
-Traffic alerts¶
-
-
-
-
-
-
-
-
Configure CIO Dashboard¶
-
-
-
-Configure the CIO Dashboard with all metrics¶
-
-
-Configuring GitHub as the incident management system¶
-
-Step 1: Authorize¶
-
-Step 2: Configure¶
-
-
-
-
-
-
-
-
-Field
-Description
-Value
-
-
-Data Plane
-Choreo collects incident details by running a scheduled job which invokes the GitHub API periodically. This job runs on the user's data plane. This configuration allows users to specify a preferred data plane to run the job, especially when they have multiple data planes.
-Select a preferred data plane from the Data Plane list.
-
-
-GitHub Account
-The GitHub account you have your repositories in.
-Select your GitHub account that includes the repository used for incident collection.
-
-
-
-GitHub Repository
-By default, Choreo will collect incident details(issues) from all repositories that already have Choreo components.
-
- Step 3: Filter label¶
-
-
-
-Type/Incident. Resolution/Invalid. You can use this label when you want to ignore issues. For example, closing an issue after identifying that it doesn't qualify as an incident issue as it was due to a user error. Step 4: Enrich incident tickets with deployment information¶
-Get deployment details
-
-
-Add deployment information to the GitHub issue
-
-
-Get deployment details) at the end of the issue body.Edit configurations¶
-
-
-
-
-
-
-
View DORA metrics¶
-Snapshot view¶
-
-Time series view¶
-Deployment frequency¶
-Snapshot view¶
-
-Deployment Frequency metric shows the deployment frequency for all components within the selected organization. The frequency is dynamically determined and rounded to the nearest measurement. For example, if there is more than one deployment daily, the deployment frequency is measured in deployments per day. If the deployment frequency is less, it is measured in a higher granularity. For example, deployments per week.Time series view¶
-
-Deployment Frequency metric visualizes the deployment count as a bar chart for the selected time period. Deployment count is aggregated based on the ‘view by’ selector. Hovering over each bar shows the counts for the aggregated period.
-Using this chart, organizations can identify deployment patterns, such as days of the week/months of the year where more deployments are likely to happen (near quarterly release days) and periods with fewer deployments. Decision-makers can then take steps to investigate and improve performance.
-This chart displays the pattern before and after a process change so you can use it to evaluate the team's performance after a significant process change. Lead Time for Change¶
-Deployment Frequency charts.Snapshot view¶
-
-Time series view¶
-
-Change failure rate¶
-Snapshot view¶
-
-Time series view¶
-
-Mean Time to Recover(MTTR)¶
-Snapshot view¶
-
-Time series view¶
-
-granularity mean would be used as the aggregation factor. Hovering over the line chart displays the actual counts for the aggregated period.
-This view helps leadership understand timely trends on mean time to recovery, such as higher values during holiday periods when there is less staff. Also, you can use this measurement to evaluate the effectiveness of process changes such as introducing an incident response plan. The trend view clearly shows the before and after statistics and the effectiveness of the process change.
-
-
-
-
-
Generate Custom Reports¶
-Metrics¶
-
-
-Group-by¶
-
-
-
-
-Download Reports¶
-
-
-
-
-
-
Insights Overview¶
-
-
-View insights¶
-
-
-View Organization Insights permission under OBSERVABILITY-MANAGEMENT with the mapping level defined at the Organization level.View Organization Insights permission by default and can view organization-wide insights.Analyze statistics¶
-Overview¶
-
-
-Traffic¶
-
-
-
-
-
-
-
-Filtering Option
-Description
-
-
-By API
-In the API field, you can select one or more APIs for which you want to view analytics. All is selected by default. Once you select an API, you can further filter by a specific application that uses the selected API via the Application field described below.
-
-
-
-By Application
-In the Application field, you can select the applications for which you want to view analytics. All is selected by default. The available applications are all the applications that have subscribed to one or more of the APIs you selected in the API field.
-
-
-Errors¶
-
-
-
-
-
-
-
-Filtering Option
-Description
-
-
-By API
-In the API field, select the APIs for which you want to view analytics. By default, all APIs are selected. You can select one or multiple APIs from this selector and view the aggregated result.
-
-
-By Category
-The Category field is displayed when you click Category in the upper right corner of the page. In this field, you can select one or all of the following error categories:
-
Authentication: Any kind of authentication error falls into this category including expired/missing/invalid credentials.
Target Connectivity: Any kind of back-end error falls into this category including connection time-outs/other back-end errors (for example, 4xx and 5xx status codes).
Throttling: Any request that fails due to rate-limiting falls into this category including application throttling/subscription throttling.
Other: All other errors fall into this category including mediation errors/resource not found errors.
-
-
-By Status Code
-The Status Code field is displayed when you click Status Code in the upper right corner of the page. In this field, you can select all or any available HTTP status code categories (4xx, 5xx, etc.). These status codes represent the response status of the API Gateway.
-Viewing errors by category
-
-
-Viewing errors by status code
-
-
-Latency¶
-
-
-
-
-
-Cache¶
-
-
-Devices¶
-
-
-Alerts¶
-
-
-Reports¶
-Download custom reports
-
-
-
-
-
-
-
-
-
-Item
-Description
-
-
-Generated Time
-The date and the time the report was generated.
-
-
-Organization
-The organization to which the report applies. Each report always applies to a specific organization.
-
-
-Environment
-The environment to which the report applies. Each report always applies to a specific environment.
-
-
-Tenant
-The tenant to which the report applies. Each report always applies to a specific tenant.
-
-
-Reporting period
-The time interval for which the report is generated.
-
-
-
-Total request count
-The total request count received by all selected APIs during the report time interval.
-
-
-
-
-
-
-
-Item
-Description
-
-
-API
-The name of the API.
-
-
-Application
-The name of the application. The name of the subscriber is also provided within brackets.
-
-
-
-Usage
-The usage count.
-Download pregenerated reports
-Geo Map¶
-Viewing the number of requests by country
- on the top right corner.
-
-x-forwarded-for header to each request to preserve the source IP address. If you do not configure this correctly, the Geo Map page will not show any data. To test this, you can manually add an x-forwarded-for header to the request.
-
-
-
-
-
Integrate Choreo with Moesif¶
-
-
-Step 1: Generate an API key in Moesif¶
-Step 1.1: Generate a key in Moesif as a new user¶
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization Name
-The name of your company or team.
-
-
-
-Application Name
-The name of your application that represents one project or environment.
-Step 1.2: Access the API key in Moesif as an existing user¶
-
-
-Step 2: Integrate Choreo with Moesif¶
-
-
-Step 3: Invoke an API and observe the data on the Moesif Dashboard¶
-
-
-
-
-
-
-
-
-
-
View Private Data Plane (PDP) Logs¶
-Prerequisites¶
-
-
-Release ID and the Namespace. Save it for later.View Private Data Plane (PDP) logs with Azure Log Analytics¶
-
-
-<START_TIME_STAMP EX: 2023-04-10T07:07:31.684Z> and <END_TIME_STAMP EX: 2023-04-21T07:27:31.684Z> values as required. Replace the '<OPTIONAL SEARCH PHRASE> with your search term, or leave it blank if you don't require any search filtering.let startDateTime = datetime('<START_TIME_STAMP EX: 2023-04-10T07:07:31.684Z>');
-let endDateTime = datetime('<END_TIME_STAMP EX: 2023-04-21T07:27:31.684Z>');
-let releaseId = '<RELEASE_ID>';
-let namespace = '<NAMESPACE>';
-let searchPhrase = '<OPTIONAL SEARCH PHRASE>';
-let startDateTimeKPI = iff(datetime_diff('second', endDateTime, startDateTime) > 60, startDateTime, endDateTime - 2m);let endDateTimeKPI = iff(datetime_diff('second', endDateTime, startDateTime) > 60, endDateTime, startDateTime + 2m);let filteredLogLevels = dynamic([]);
-let hasNoLevelFilter = array_length(filteredLogLevels) == 0;
-let commonKeys = dynamic(['time', 'level', 'module', 'traceId', 'spanId', 'message']);
-let ContainerIdList = KubePodInventory
-| where TimeGenerated > startDateTimeKPI and TimeGenerated < endDateTimeKPI
-| where Namespace == namespace
-| where extractjson('$.[0].release_id', PodLabel) == releaseId
-| distinct ContainerID;
-let data = ContainerLog
-| where TimeGenerated > startDateTime and TimeGenerated < endDateTime
-| where ContainerID in (ContainerIdList)
-| where searchPhrase == "" or LogEntry contains searchPhrase
-| top 126 by TimeGenerated desc
-| extend logs = parse_json(LogEntry)
-| project TimeGenerated,
-LogLevel = iif(isempty(logs['level']), iff(LogEntrySource == 'stderr', 'ERROR', 'INFO'), logs['level']),
-LogEntry = iif(isempty(logs['message']), logs, logs['message']),
-KeyValuePair = bag_remove_keys(logs, commonKeys)
-| where hasNoLevelFilter or LogLevel in (filteredLogLevels);
-let lastTimeStamp = data
-| top 1 by TimeGenerated asc | project TimeGenerated;
-let trimmedData = data | where TimeGenerated > toscalar(lastTimeStamp)| sort by TimeGenerated desc;
-let selected = iff(toscalar(data | count) == 126, 'trimmedData', 'data');
-let choose = (selector:string){ union (trimmedData | where selector == 'trimmedData'), (data | where selector == 'data')};
-choose(selected);
-View Private Data Plane (PDP) logs with Amazon CloudWatch¶
-
-
-
-
-
-
-
-
-
- <RELEASE_ID> with the values you copied by following the steps in the prerequisites section. Replace the <OPTIONAL SEARCH PHRASE> with your search term, or leave it blank if you don't require any search filtering.
-
-
-
-
-
Observability Overview¶
-
-
-Throughput and latency graphs¶
-Diagnostics view¶
-
-
-Logs¶
-
-
-
-
-
-
View Logs¶
-Runtime logs¶
-
-
-Understand runtime logs¶
-Application logs
-
-
-timestamp: The time when the request is received by the component.level: Indicates the severity of the log message. Possible values are Debug, Info, Warn, and Error.componentVersion: The version of the invoked component.componentVersionId: The identifier of the invoked component’s version.envName: The environment of the inbound request. For example, Development, Production, etc.Gateway logs
-
-
-timestamp: The time when the request is received by the gateway component.logLine: Contains the following details about the request, including inbound and outbound information from the gateway perspective.
-
-Method: The HTTP method of the request.RequestPath: The path of the inbound request.ServicePath: The path of the outbound request.UserAgent: The user-agent header of the request.CorrelationID: The request identifier of the inbound request. This is useful to track a request.ServiceHost: The host IP of the backend.Duration: The time taken for the gateway to serve the request. gatewayCode: Indicates the state of the request from the gateway perspective. Possible values are as follows:
-
-BACKEND_RESPONSE: Indicates successful processing of the request by the gateway with a response to the client from the backend application.CORS_RESPONSE: Denotes a CORS (Cross Origin Resource Sharing) request.AUTH_FAILURE: Indicates a request failure at the gateway due to authentication or authorization issues, such as an invalid token.NO_HEALTHY_BACKEND: Indicates a request failure at the gateway due to a non-existent backend.RATE_LIMITED: Indicates a request failure at the gateway due to surpassing the rate limit enforced within the component.RESOURCE_NOT_FOUND: Indicates a request failure at the gateway due to the absence of a matching API resource for the inbound request. This can be caused by a mismatch in the HTTP method, path, or host.BACKEND_TIMEOUT: Indicates a request timeout when calling the backend application from the gateway.GATEWAY_ERROR: Indicates a request failure due to an erroneous behavior in the gateway.gatewayCode is displayed as UNKNOWN.statusCode: The HTTP status code returned to the client.componentVersion: The version of the invoked component.envName: The environment of the inbound request. For example, Development, Production, etc.Audit logs¶
-
-
-
-
-Audit log retention¶
-Manage audit log access¶
-Step 1: Create a role with audit log access permission
-
-
-Step 2: Assign the created role to an organization member
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Access the Choreo Insights API¶
-Become a member of the Choreo System organization¶
-
-
-Choreo System organization via https://devportal.choreo.dev/choreosystem/applications and sign in using your preferred method.Choreo System organization, click Request Access.Create an application and generate keys¶
-
-
-
-
-
-
-
-
- Choreo System organization, click + Create Application.
-
-Insights and click Add.
-
-curl --location --request POST 'https://sts.choreo.dev/oauth2/token' \
---header 'Authorization: Basic <BASE64_ENCODED_CONSUMER_KEY_AND_CONSUMER_SECRET_OF_YOUR_APP_HERE>' \
---header 'Content-Type: application/x-www-form-urlencoded' \
---data-urlencode 'grant_type=client_credentials' \
---data-urlencode 'orgHandle=<YOUR_ORG_HANDLE_HERE>' \
---data-urlencode 'scope=apim:api_manage'
-
-
-curl --location --request POST 'https://choreocontrolplane.choreo.dev/93tu/insights/1.0.0/query-api' \
---header 'Content-Type: application/json' \
---header 'Authorization: Bearer <TOKEN_HERE>' \
---data-raw '{"query":"query ($org: OrgFilter!) {listEnvironments(org: $org){id\n name}}","variables":{"org":{"orgId":"<ORG_UUID_HERE>"}}}'
-
-
-
-
-
-
Choreo Insights API¶
-Try out¶
-Query¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-listAllAPI
-[API]
-
-
-Fetches all the APIs with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
-can configure the
-provider parameter to further filter the APIs by a specific provider.
-
-
-
-provider
-String
-
-
-The name of the API provider.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-listApplications
-[Application]
-
-
-Fetches all the applications with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
-can configure the
-applicationFilter parameter to further filter the applications by a specific application filter.
-
-
-
-applicationFilter
-ApplicationFilter
-
-
-The application filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-listProviders
-[Provider]
-
-
-Fetches all the API providers with the given combination of tenant ID, environment ID, and organization ID.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-listSubscribers
-[Subscriber]
-
-
-Fetches all the API subscribers with the given combination of tenant ID, environment ID, and organization ID. Optionally, you
-can configure the
-subscriberFilter parameter to further filter the subscribers.
-
-
-
-subscriberFilter
-SubscriberFilter
-
-
-The subscriber filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-listOrganizations
-[Organization]
-
-
-Fetches all the organizations of a user.
-
-
-
-
-listEnvironments
-[Environment]
-
-
-Fetches all the environments of an organization.
-
-
-
-
-org
-OrgFilter!
-
-
-The organization filter.
-
-
-
-
-projectId
-String
-
-
-The project ID by which the results need to be filtered. It is optional to specify a value for this
-parameter. Note that providing a project ID with an on-prem key is not allowed.
-
-
-
-
-listTenants
-[String]
-
-
-Fetches all the tenants with the given combination of environment ID and organization ID.
-
-
-
-
-tenantDataFilter
-TenantDataFilter!
-
-
-The tenant filter.
-
-
-
-
-getTotalTraffic
-Int
-
-
-Returns the total traffic during the given time range for the specified combination of tenant ID, environment ID,
-and organization ID.
-
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTotalErrors
-Int
-
-
-Returns the total number of errors that occurred during the given time range for the specified combination of tenant
-ID, environment ID, and organization ID.
-
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getOverallLatency
-Float
-
-
-Returns the overall response latency (95th percentile value) during the given time range for the specified
-combination of tenant ID, environment ID, and organization ID.
-
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getLatencySummary
-LatencySummary
-
-
-Returns the response latency value (95th percentile value) for each time granularity within the specified time range
-for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-
-latencySummaryFilter parameter to further filter the results.
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-latencySummaryFilter
-LatencySummaryFilter
-
-
-The latency summary filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getSuccessSummary
-SuccessSummary
-
-
-Returns the number of successful (2xx response code) hit count for each time granularity within the specified time
-range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-
-granularity parameter to override the default granularity value.
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-granularity
-String
-
-
-The granularity value.
-
-
-
-
-getErrorSummary
-ErrorSummary
-
-
-Returns the number of unsuccessful hits (i.e., the total of both
-4xx and 5xx response codes) for each time
-granularity within the specified time range for the given combination of tenant ID, environment ID, and organization
-ID. Optionally, you can configure the granularity parameter to override the default granularity value.
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-granularity
-String
-
-
-The granularity value.
-
-
-
-
-getErrorsByCategory
-ErrorsByCategory
-
-
-Returns the number of proxy errors (i.e., the total of both
-4xx and 5xx response codes) by each error category
-for each time granularity within the specified time range for the given combination of tenant ID, environment ID,
-and organization ID. Optionally, you can configure the errorsByCategoryFilter parameter to further filter the
-results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-errorsByCategoryFilter
-ErrorsByCategoryFilter
-
-
-The errors by category filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getErrorsDetails
-DetailsOfErrors
-
-
-Returns details of each proxy error (for both
-4xx and 5xx response codes) within the specified time range for
-the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-errorsDetailsFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-errorsDetailsFilter
-ErrorsDetailsFilter
-
-
-The error details filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getProxyTargetErrorsOverTime
-[ErrorsByStatusCodeCategory]
-
-
-Returns a list of hit counts for proxy and target errors for each time granularity within the specified time range
-for the given combination of tenant ID, environment ID, and organization ID. The errors in each proxy and target
-result set are grouped as
-4xx, 5xx, and total. Optionally, you can configure the errorsByStatusCodeFilter
-parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-errorsByStatusCodeFilter
-ErrorsByStatusCodeFilter
-
-
-The errors by status code filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getErrorsByStatusCode
-ErrorsByStatusCode
-
-
-Returns the hit count for each error response code (
-401, 404, and 500 etc.,) for each API within the specified
-time range for the given combination of tenant ID, environment ID, and organization ID.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-errorCountByStatusCodeFilter
-ErrorCountByStatusCodeFilter!
-
-
-The error count by status code filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTotalErrorsByAPI
-TotalError
-
-
-Returns the total proxy error hit count for an API across for the given combination of tenant ID, environment ID,
-and organization ID. Optionally, you can configure the
-filter parameter to further filter the results by a given
-time range.
-
-
-
-filter
-TimeFilter
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-apiId
-ID!
-
-
-The API ID.
-
-
-
-
-getAPIUsageOverTime
-[APIUsageOverTime]
-
-
-Returns a list of details related to the usage of each API over time for each time granularity within the specified
-time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can
-configure the
-apiUsageOvertimeFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-apiUsageOvertimeFilter
-APIUsageOverTimeFilter
-
-
-The API usage overtime filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getAPIUsageByAppOverTime
-APIUsageByAppOverTime
-
-
-Returns API usage by each application over time for each time granularity within the specified time range for the
-given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-
-apiUsageOvertimeFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-apiUsageOvertimeFilter
-APIUsageOverTimeFilter
-
-
-The API usage overtime filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getAPIUsageByBackendOverTime
-APIUsageByBackendOverTime
-
-
-Returns API usage by each backend over time for each time granularity within the specified time range for the given
-combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-
-apiUsageByBackendOverTimeFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-apiUsageByBackendOverTimeFilter
-APIUsageByBackendOverTimeFilter
-
-
-The API usage by backend overtime filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getResourceUsage
-ResourceUsages
-
-
-Returns API usage by resource within the specified time range for the given combination of tenant ID, environment
-ID, and organization ID. Optionally, you can configure the
-resourceUsageFilter parameter to further filter the
-results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-resourceUsageFilter
-ResourceUsageFilter
-
-
-The resource usage filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTotalTrafficByAPI
-Int
-
-
-Returns the total hit count for an API for the given combination of tenant ID, environment ID, and organization ID.
-Optionally, you can configure the
-filter parameter to further filter the results by a given time range.
-
-
-
-filter
-TimeFilter
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-apiId
-ID!
-
-
-The API ID.
-
-
-
-
-topSlowestAPIs
-[SlowAPI]
-
-
-Returns a list of top slowest APIs based on the response latency (95th percentile value) within the specified time
-range for the given combination of tenant ID, environment ID, and organization ID.
-
-
-
-
-filter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-limit
-Int!
-
-
-The limit for the slow APIs list.
-
-
-
-
-getLatency
-APILatency
-
-
-Returns different latency category values (95th percentile values) for a given API over time for each time
-granularity within the specified time range for the given combination of tenant ID, environment ID, and organization
-ID.
-
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-latencyFilter
-LatencyFilter!
-
-
-The latency filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getOverallLatencyByAPI
-OverallLatency
-
-
-Returns the overall response latency (95th percentile value) for an API for the given combination of tenant ID,
-environment ID, and organization ID. Optionally, you can configure the
-filter parameter to further filter the
-results by a given time range.
-
-
-
-filter
-TimeFilter
-
-
-The time filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-apiId
-ID!
-
-
-The API ID.
-
-
-
-
-getCacheHitsAndMisses
-CacheHits
-
-
-Return the total number of response cache hits, misses, and hit percentage for an API over time for each time
-granularity within the specified time range for the given combination of tenant ID, environment ID, and
-organization ID.
-
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-cacheFilter
-CacheFilter
-
-
-The cache filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTopPlatforms
-[Platform]
-
-
-Returns a list of top platforms ranked based on the hit count within the specified time range for the given
-combination of tenant ID, environment ID, and organization ID. The result list includes the top nine platforms with
-the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit count.
-Optionally, you can configure the
-deviceFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-deviceFilter
-DeviceFilter
-
-
-The device filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTopUserAgents
-[UserAgent]
-
-
-Returns a list of top user agents ranked based on the hit count within the specified time range for the given
-combination of tenant ID, environment ID, and organization ID. The result list includes the top nine user agents
-with the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit
-count. Optionally, you can configure the
-deviceFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-deviceFilter
-DeviceFilter
-
-
-The device filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getAPIUsageByGeoLocation
-[UsageByGeoLocation]
-
-
-NOTE: Currently, this operation returns data only for on-premise environments.
-
-Returns API usage by country within the specified time range for the given combination of tenant ID, environment ID,
-and organization ID. Optionally, you can configure the
-geoLocationFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-geoLocationFilter
-GeoLocationFilter
-
-
-The geolocation filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getAPIsUsageByApplications
-[APIUsageByApplication]
-
-
-Returns details relating to the usage of each API by application within the specified time range for the given
-combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the
-
-apiUsageByAppFilter parameter to further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-apiUsageByAppFilter
-APIUsageByAppFilter
-
-
-The API usage by app filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getTopAPIsByAlertCount
-TopAPIsByAlertCount
-
-
-Returns top APIs ranked based on the alert count within the specified time range for the given combination of tenant
-ID, environment ID, and organization ID. Optionally, you can configure the
-topAPIsByAlertCountFilter parameter to
-further filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-topAPIsByAlertCountFilter
-TopAPIsByAlertCountFilter
-
-
-The top APIs by alert count filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getAlertSummary
-AlertSummaries
-
-
-Returns a summary for each alert within the specified time range for the given combination of tenant ID,
-environment ID, and organization ID. Optionally, you can configure the
-alertSummaryFilter parameter to further
-filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-alertSummaryFilter
-AlertSummaryFilter
-
-
-The alert summary filter.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-getSuccessAPIsUsageByApplications
-[SuccessAPIUsageByApplication]
-
-
-NOTE: This operation can only be invoked via using an on-prem key as the authentication header.
-
-Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API,
-grouped by each application. Optionally, you can configure the
-successAPIUsageByAppFilter parameter to further
-filter the results.
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-successAPIUsageByAppFilter
-SuccessAPIUsageByAppFilter
-
-
-The successful API usage by application filter.
-
-
-
-
-getSuccessAPIsUsageByApplicationsWithOnPremKey
-[SuccessAPIUsageByApplication]
-
-
-Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API,
-grouped by each application. Optionally, you can configure the
-successAPIUsageByAppFilter parameter to further
-filter the results.
-
-
-
-onPremKey
-String!
-
-
-The value of the On-Prem key.
-
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-successAPIUsageByAppFilter
-SuccessAPIUsageByAppFilter
-
-
-The successful API usage by application filter.
-
-
-
-
-getCustomReportOvertime
-CustomReportOvertime
-
-
-Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-metric
-Metric!
-
-
-The metric for which data needs to be retrieved.
-
-
-
-
-groupByFields
-[GroupByField]!
-
-
-The column/field by which data needs to be retrieved.
-
-
-
-
-groupByValues
-[String]!
-
-
-The value used to filter by the
-groupByField.
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-
-
-getCustomReportTopOvertime
-CustomReportTopOvertime
-
-
-Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans for
-the top N values for the selected groupByField.
-
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-timeFilter
-TimeFilter!
-
-
-The time filter.
-
-
-
-
-metric
-Metric!
-
-
-The metric for which data needs to be retrieved.
-
-
-
-
-groupByFields
-[GroupByField]!
-
-
-The column/field by which the data should be grouped.
-
-
-
-
-groupByValues
-[String]!
-
-
-The value used to filter by the
-groupByField.
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-
-
-getGroupByValues
-[[String]]
-
-
-Returns a list of value sets by which you can group the data available for the selected
-groupBy fields.
-
-
-
-dataFilter
-DataFilter!
-
-
-The data filter.
-
-
-
-
-groupByFields
-[GroupByField]!
-
-
-The column/field for which the API needs to retrieve distinct values.
-
-
-
-
-
-groupByValues
-[String]!
-
-
-The value used to filter by the
-groupByField.
-
-Objects¶
-API¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-id
-ID!
-
-
-The ID of the API.
-
-
-
-
-name
-String!
-
-
-The API name.
-
-
-
-
-version
-String!
-
-
-The API version.
-
-
-
-
-
-provider
-String!
-
-
-The API provider name.
-
-
-APILatency¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-summary
-[Latency]
-
-
-A list containing latency category values over time. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-APIUsage¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-
-count
-Int!
-
-
-The API usage count.
-
-
-APIUsageByApp¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-applicationId
-ID!
-
-
-The application ID.
-
-
-
-
-applicationName
-String!
-
-
-The application name.
-
-
-
-
-applicationOwner
-String!
-
-
-The name of the application owner.
-
-
-
-
-
-usage
-[APIUsage]
-
-
-A list containing the APIs usage values. Returns an empty array if no data is available.
-
-
-APIUsageByAppOverTime¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[APIUsageByApp]
-
-
-A list containing the API usage values across APIs, grouped by the application. Returns an empty array if no data is
-available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-APIUsageByApplication¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-String!
-
-
-The ID of the API.
-
-
-
-
-applicationId
-String!
-
-
-The Application ID.
-
-
-
-
-applicationName
-String!
-
-
-The application name.
-
-
-
-
-applicationOwner
-String!
-
-
-The name of the application owner.
-
-
-
-
-
-count
-Int!
-
-
-The usage of the API by the application.
-
-
-APIUsageByBackend¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-backend
-String!
-
-
-The name of the backend.
-
-
-
-
-
-usage
-[APIUsage]
-
-
-A list containing the APIs usage values. Returns an empty array if no data is available.
-
-
-APIUsageByBackendOverTime¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[APIUsageByBackend]
-
-
-A list containing the API usage values across APIs by each backend. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-APIUsageOverTime¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID
-
-
-The ID of the API.
-
-
-
-
-usage
-[APIUsage]
-
-
-A list containing the API usage values. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-AlertSummaries¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[AlertSummary]
-
-
-A list containing the alert summary for each alert. Returns an empty array if no data is available.
-
-
-
-
-
-pagination
-Pagination!
-
-
-The pagination details.
-
-
-AlertSummary¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID!
-
-
-The ID of the API.
-
-
-
-
-timestamp
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-category
-String!
-
-
-The alert category. Possible values are
-LATENCY and TRAFFIC.
-
-
-
-metric
-String!
-
-
-The alert metric. Possible values are
-RESPONSE_LATENCY and TOTAL_TRAFFIC.
-
-
-
-severity
-String!
-
-
-The severity level of the alert. Possible values are
-LOW, MEDIUM, and HIGH.
-
-
-
-
-message
-String!
-
-
-The alert details.
-
-
-Application¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-id
-ID!
-
-
-The Application ID.
-
-
-
-
-name
-String!
-
-
-The application name.
-
-
-
-
-
-owner
-String!
-
-
-The name of the application owner.
-
-
-CacheHit¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-hits
-Int!
-
-
-The number of times the response cache was hit.
-
-
-
-
-misses
-Int!
-
-
-The number of times the response cache was missed.
-
-
-
-
-
-hitPercentage
-Float!
-
-
-The response cache hits as a percentage of the sum of hits and misses.
-
-
-CacheHits¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-summary
-[CacheHit]
-
-
-A list containing cache hits, misses, and the hit percentage over time. Returns an empty array if no data is
-available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-CustomReportGroupBy¶
-groupByValue.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-groupByValue
-ID!
-
-
-The distinct group-by value that is used as an ID.
-
-
-
-
-
-usage
-[CustomReportUsage]
-
-
-A list containing the usage values. This returns an empty array if no data is available.
-
-
-CustomReportOvertime¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[CustomReportUsage]
-
-
-A list containing the usage values. This returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-CustomReportTopOvertime¶
-groupByValues.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[CustomReportGroupBy]
-
-
-A list containing the usage values grouped by the selected
-groupByField. This returns an empty array if no data is
-available.
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-CustomReportUsage¶
-CustomReports.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-
-value
-Int!
-
-
-The usage value (Hit Count/ Latency).
-
-
-DetailsOfErrors¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[ErrorDetails]!
-
-
-A list containing error details over time. Returns an empty array if no data is available.
-
-
-
-
-
-pagination
-Pagination!
-
-
-The pagination details.
-
-
-Environment¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-id
-String!
-
-
-The environment ID.
-
-
-
-
-externalEnvId
-String!
-
-
-The external environment ID.
-
-
-
-
-internalEnvId
-String
-
-
-The internal environment ID.
-
-
-
-
-sandboxEnvId
-String
-
-
-The sandbox environment ID.
-
-
-
-
-name
-String!
-
-
-The environment name.
-
-
-
-
-
-type
-EnvironmentType!
-
-
-The environment type. A Choreo environment is labeled as
-CHOREO, a private Choreo environment is labeled as
-CHOREO_PRIVATE, and the on-premise environment is labeled as ON_PREM.
-
-ErrorCountByCategory¶
-null value is shown for the other categories that are not selected.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-auth
-Int
-
-
-The count of authorization errors.
-
-
-
-
-targetConnectivity
-Int
-
-
-The count of target connectivity errors.
-
-
-
-
-throttled
-Int
-
-
-The count of throttling errors.
-
-
-
-
-
-other
-Int
-
-
-The count of other errors.
-
-
-ErrorCountByCode¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-statusCode
-String!
-
-
-The error status code.
-
-
-
-
-
-count
-Int!
-
-
-The error count.
-
-
-ErrorCountByCodeForAPI¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID!
-
-
-The ID of the API.
-
-
-
-
-
-errorCountByCode
-[ErrorCountByCode]
-
-
-A list containing the error count for each error status code. Returns an empty array if no data is available.
-
-
-ErrorDetails¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID
-
-
-The ID of the API.
-
-
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-applicationId
-String
-
-
-The Application ID.
-
-
-
-
-applicationName
-String
-
-
-The application name.
-
-
-
-
-applicationOwner
-String
-
-
-The name of the application owner.
-
-
-
-
-reason
-String!
-
-
-The reason for the error.
-
-
-
-
-
-count
-Int!
-
-
-The error count.
-
-
-ErrorStatusCodeCategoryCounts¶
-4xx or 5xx) and the total error count.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-_4xx
-Int
-
-
-The number of client errors.
-
-
-
-
-_5xx
-Int
-
-
-The number of server errors.
-
-
-
-
-
-total
-Int
-
-
-The total number of client and server errors.
-
-
-ErrorSummary¶
-4xx and 5xx response codes) summary across all APIs.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-summary
-[ErrorValue]!
-
-
-A list containing unsuccessful usage values. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-ErrorValue¶
-4xx and 5xx response codes) for a single timestamp. The timestamp
-is calculated based on the granularity value provided.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-
-errorCount
-Int
-
-
-Represents the error request count.
-
-
-ErrorsByCategory¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-errors
-[ErrorCountByCategory]
-
-
-A list containing the error count for each error category over time. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-ErrorsByStatusCode¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-errors
-[ErrorCountByCodeForAPI]!
-
-
-A list containing the error count for each status code for each API. Returns an empty array if no data is available.
-
-
-
-
-
-pagination
-Pagination!
-
-
-Pagination details.
-
-
-ErrorsByStatusCodeCategory¶
-4xx, 5xx, and total) for both proxy and target errors for a
-single timestamp. The timestamp is calculated based on the granularity value provided.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-proxy
-ErrorStatusCodeCategoryCounts
-
-
-Represents proxy-related errors categorized as client errors (
-4xx response codes) or server errors (5xx response
-codes), and the total of both categories.
-
-
-
-
-target
-ErrorStatusCodeCategoryCounts
-
-
-Represents target-related errors categorized as client errors (
-4xx response codes) or server errors (5xx
-response codes), and the total of both categories.
-
-Latency¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-response
-Int
-
-
-The response latency (95th percentile) in milliseconds (ms).
-
-
-
-
-backend
-Int
-
-
-The backend latency (95th percentile) in milliseconds (ms).
-
-
-
-
-requestMediation
-Int
-
-
-The request mediation latency (95th percentile) in milliseconds (ms).
-
-
-
-
-responseMediation
-Int
-
-
-The response mediation latency (95th percentile) in milliseconds (ms).
-
-
-
-
-responseMedian
-Int
-
-
-The median (50th percentile) of the response latency in milliseconds (ms).
-
-
-
-
-backendMedian
-Int
-
-
-The median (50th percentile) of the backend latency in milliseconds (ms).
-
-
-
-
-requestMediationMedian
-Int
-
-
-The median (50th percentile) of the request mediation latency in milliseconds (ms).
-
-
-
-
-
-responseMediationMedian
-Int
-
-
-The median (50th percentile) of the response mediation latency in milliseconds (ms).
-
-
-LatencySummary¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-summary
-[LatencyValue]!
-
-
-A list containing latency values. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-LatencyValue¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-
-latencyTime
-Float!
-
-
-Represents the latency (95th percentile) time in milliseconds (ms).
-
-
-Organization¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-id
-String!
-
-
-The organization ID.
-
-
-
-
-uuid
-ID!
-
-
-The organization UUID.
-
-
-
-
-handle
-String!
-
-
-The organization handle name.
-
-
-
-
-
-name
-String!
-
-
-The organization name.
-
-
-OverallLatency¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-
-response
-Float
-
-
-The response latency (95th percentile value) in milliseconds (ms).
-
-
-Pagination¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-total
-Int!
-
-
-The total number of results.
-
-
-
-
-limit
-Int!
-
-
-The number of items in the result set.
-
-
-
-
-offset
-Int!
-
-
-The offset value for the result set.
-
-
-
-
-sortBy
-String!
-
-
-The sorting column name of the result set.
-
-
-
-
-
-sortOrder
-String!
-
-
-The sorting order of the result set. Possible values are
-asc and desc.
-
-Platform¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-platform
-String!
-
-
-The name of the platform.
-
-
-
-
-
-count
-Int!
-
-
-The usage of the platform.
-
-
-Provider¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-
-name
-String!
-
-
-The API provider name.
-
-
-ResourceUsage¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID!
-
-
-The ID of the API.
-
-
-
-
-apiResourceTemplate
-String!
-
-
-The API resource template.
-
-
-
-
-apiMethod
-String!
-
-
-The API method.
-
-
-
-
-
-count
-Int!
-
-
-The usage of the API resource.
-
-
-ResourceUsages¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[ResourceUsage]
-
-
-A list with the usage of each API resource. Returns an empty array if no data is available.
-
-
-
-
-
-pagination
-Pagination!
-
-
-Pagination details.
-
-
-SlowAPI¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID!
-
-
-The ID of the API.
-
-
-
-
-
-latency
-Int!
-
-
-Represents the latency (95th percentile) time in milliseconds (ms).
-
-
-Subscriber¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-
-name
-String!
-
-
-The name of the API subscriber.
-
-
-SuccessAPIUsageByApplication¶
-2xx response code) of an API by an application.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-String!
-
-
-The ID of the API.
-
-
-
-
-apiName
-String!
-
-
-The name of the API.
-
-
-
-
-apiVersion
-String!
-
-
-The version of the API.
-
-
-
-
-apiCreatorTenantDomain
-String!
-
-
-The tenant domain of the API creator.
-
-
-
-
-applicationId
-String!
-
-
-The application ID.
-
-
-
-
-applicationName
-String!
-
-
-The name of the application.
-
-
-
-
-applicationOwner
-String!
-
-
-The name of the application owner.
-
-
-
-
-
-count
-Int!
-
- SuccessSummary¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-summary
-[SuccessValue]!
-
-
-A list containing successful usage values. Returns an empty array if no data is available.
-
-
-
-
-
-granularity
-String!
-
-
-The granularity value for which data is retrieved.
-
-
-SuccessValue¶
-2xx response code) for a single
-timestamp. The timestamp is calculated according to the granularity value provided.
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-timeSpan
-String!
-
-
-Represents a timestamp value that is calculated based on the specified granularity value. For example, if the
-granularity value is
-1d, the timestamp represents the start of the day calculated adhering to the timezone
-provided in the time filter.
-e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30'
-
-
-
-
-requestCount
-Int!
-
-
-Represents the successful request count.
-
-
-TopAPIByAlertCount¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-apiId
-ID!
-
-
-The ID of the API.
-
-
-
-
-
-count
-Int!
-
-
-The alert count.
-
-
-TopAPIsByAlertCount¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-usage
-[TopAPIByAlertCount]
-
-
-A list containing top APIs by alert count. Returns an empty array if no data is available.
-
-
-
-
-
-pagination
-Pagination!
-
-
-The pagination details.
-
-
-TotalError¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-
-proxy
-Int
-
-
-The proxy-related error count.
-
-
-UsageByGeoLocation¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-country
-String!
-
-
-The name of the country.
-
-
-
-
-
-count
-Int!
-
-
-The usage of the API.
-
-
-UserAgent¶
-
-
-
-
-
-
-
-
-Field
-Argument
-Type
-Description
-
-
-userAgent
-String!
-
-
-The name of the user agent.
-
-
-
-
-
-count
-Int!
-
-
-The usage of the user agent.
-
-
-Inputs¶
-APIUsageByAppFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-
-
-appIds
-[String]
-
-
-The results are filtered for the list of applications you specify here. A maximum of five application IDs can be
-defined.
-
-
-
-
-
-subscribers
-[String]
-
-
-The results are filtered for the list of subscribers you specify here. A maximum of five subscriber IDs can be
-defined.
-
-
-APIUsageByBackendOverTimeFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-APIUsageOverTimeFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-
-
-appIds
-[String]
-
-
-The results are filtered for the list of applications you specify here. A maximum of five application IDs can be
-defined.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-AlertSummaryFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-paginationFilter
-PaginationFilter
-
-
-The pagination filter.
-
-
-
-
-searchFilter
-SearchFilter
-
-
-The search filter.
-
-
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-
-
-
-category
-String
-
-
-The alert category by which the results need to be filtered. The available categories to select are
-TRAFFIC and
-LATENCY.
-
-ApplicationFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-owner
-String
-
-
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-CacheFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The results are filtered by the API ID specified here.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-DataFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-orgId
-String!
-
-
-The organization by which the results need to be filtered. It is required to specify a value for this parameter.
-
-
-
-
-environmentId
-String
-
-
-The environment ID by which the results need to be filtered. It is required to specify a value for this parameter.
-
-
-
-
-environmentIds
-[String]
-
-
-The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter.
-
-
-
-
-tenant
-String!
-
-
-The name of the tenant by which the results need to be filtered. It is required to specify a value for this
-parameter.
-
-
-
-
-
-projectId
-String
-
-
-The project ID by which the results need to be filtered. It is optional to specify a value for this
-parameter. Note that providing a project ID with an on-prem key is not allowed.
-
-
-DeviceFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-ErrorCountByStatusCodeFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The results are filtered by the API ID specified here.
-
-
-
-
-errorType
-ErrorType!
-
-
-The type of the error. It is required to specify a value for this parameter.
-
-
-
-
-errorCodeType
-ErrorCodeType
-
-
-The error code type. If this parameter is not configured, both client-related error response codes (
-401, 404,
-etc.) and server-related response codes (500, 501, etc.) are included in the result set.
-
-
-
-
-paginationFilter
-PaginationFilter
-
-
-The pagination filter.
-
-
-ErrorsByCategoryFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The ID of the API.
-
-
-
-
-categories
-[String]
-
-
-The list of categories by which the results need to be filtered. Category values that you can specify here are
-
-AUTH, TARGET_CONNECTIVITY, THROTTLED, and OTHER.
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-ErrorsByStatusCodeFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The results are filtered by the API ID specified here.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-ErrorsDetailsFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The results are filtered by the API ID specified here.
-
-
-
-
-appId
-String
-
-
-The application ID by which the results need to be filtered.
-
-
-
-
-category
-String
-
-
-The error category by which the results need to be filtered. The error category that you can specify here must be
-one of the
-AUTH TARGET_CONNECTIVITY, THROTTLED, and OTHER values.
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-
-
-paginationFilter
-PaginationFilter
-
-
-The pagination filter.
-
-
-
-
-
-searchFilter
-SearchFilter
-
-
-The search filter.
-
-
-GeoLocationFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here.
-
-
-LatencyFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String!
-
-
-The results are filtered by the API ID specified here. It is required to specify a value for this parameter.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-LatencySummaryFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiId
-String
-
-
-The results are filtered by the API ID specified here.
-
-
-
-
-
-granularity
-String
-
-
-The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity
-for the related time range is applied. The possible granularity values that you can specify are
-1m, 15m, 1h,
-1d, and 7d.
-
-OrgFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-
-orgId
-String!
-
-
-The ID of the organization by which the results need to be filtered. It is required to specify a value for this
-parameter.
-
-
-PaginationFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-limit
-Int
-
-
-The total number of rows in the result set. This value must be a positive integer. If this limit value is not set,
-the total number of rows is five by default.
-
-
-
-
-offset
-Int
-
-
-The offset value to set when filtering results. This value must be zero or a positive integer. If you do not specify
-an offset value, the default offset value (i.e.,
-0) applies.
-
-
-
-sortBy
-String
-
-
-The column name by which the results are sorted. If the
-sortBy value is not set, the default column of the related
-operation that is available for sorting purposes is used.
-
-
-
-
-sortOrder
-String
-
-
-The order in which the results are sorted. Possible values are
-asc (to sort in ascending order) and desc (to
-sort in descending order). If no value is specified, the results are sorted in ascending order by default (except
-for count-specific operations such as getTopAPIsByAlertCount where the results are always sorted in descending
-order).
-
-ResourceUsageFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-paginationFilter
-PaginationFilter
-
-
-The pagination filter.
-
-
-
-
-
-searchFilter
-SearchFilter
-
-
-The search filter.
-
-
-SearchFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiIds
-[String]
-
-
-The list of API IDs that need to be searched with the given search text. Note that it is not possible to define API
-IDs without a search text in the search filter.
-
-
-
-
-
-searchText
-String!
-
-
-Text which needs to be searched among the results. It is required to specify a value for this parameter.
-
-
-SubscriberFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-
-apiIds
-[String]
-
-
-The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined.
-
-
-SuccessAPIUsageByAppFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-apiIds
-[String]
-
-
-The list of API IDs by which the results need to be filtered.
-
-
-
-
-
-tenantDomains
-[String]
-
-
-The tenant domain name by which the results need to be filtered.
-
-
-TenantDataFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-orgId
-String!
-
-
-The ID of the organization by which the results need to be filtered. It is required to specify a value for this
-parameter.
-
-
-
-
-envId
-String
-
-
-The ID of the environment by which the results need to be filtered. It is required to specify a value for this
-parameter.
-
-
-
-
-
-environmentIds
-[String]
-
-
-The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter.
-
-
-TimeFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-from
-String!
-
-
-The start date of the time range. The date specified here must be a date earlier than the date specified via the
-
-to parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is
-required to specify a value for this parameter.
-e.g., '2021-08-16T12:00:00.000+05:30'.
-
-
-
-
-to
-String!
-
-
-The end date of the time range. The date specified here must be a date later than the date specified via the
-from
-parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is
-required to specify a value for this parameter.
-e.g., '2021-08-16T12:30:00.000+05:30'.
-
-TopAPIsByAlertCountFilter¶
-
-
-
-
-
-
-
-
-Field
-Type
-Description
-
-
-paginationFilter
-PaginationFilter
-
-
-The pagination filter.
-
-
-
-
-
-searchFilter
-SearchFilter
-
-
-The search filter.
-
-
-Enums¶
-EnvironmentType¶
-
-
-
-
-Value
-Description
-
-
-
-
-CHOREO
-
-
-The Choreo environments.
-
-
-
-
-CHOREO_PRIVATE
-
-
-The private data-plane Choreo environments.
-
-
-
-
-
-ON_PREM
-
-
-The On-Premise environments.
-
-
-ErrorCodeType¶
-
-
-
-
-Value
-Description
-
-
-
-
-_4XX
-
-
-The client-side errors.
-
-
-
-
-
-_5XX
-
-
-The server-side errors.
-
-
-ErrorType¶
-
-
-
-
-Value
-Description
-
-
-
-
-PROXY
-
-
-The proxy-related errors.
-
-
-
-
-
-TARGET
-
-
-The target-related errors.
-
-
-GroupByField¶
-groupByField used in CustomReports.
-
-
-
-Value
-Description
-
-
-
-
-API_NAME
-
-
-The API name.
-
-
-
-
-API_VERSION
-
-
-The API version.
-
-
-
-
-API_RESOURCE_TEMPLATE
-
-
-The API resource template.
-
-
-
-
-API_METHOD
-
-
-The API method.
-
-
-
-
-API_CREATOR
-
-
-The API creator.
-
-
-
-
-APPLICATION_NAME
-
-
-The name of the application.
-
-
-
-
-APPLICATION_OWNER
-
-
-The owner of the application.
-
-
-
-
-DESTINATION
-
-
-The destination.
-
-
-
-
-USER_AGENT
-
-
-The user Agent.
-
-
-
-
-PLATFORM
-
-
-The platform.
-
-
-
-
-
-TARGET_RESPONSE_CODE
-
-
-The target response code.
-
-
-Metric¶
-CustomReports.
-
-
-
-Value
-Description
-
-
-
-
-HIT_COUNT
-
-
-The number of API calls.
-
-
-
-
-RESPONSE_CACHE_HIT
-
-
-The number of API calls that used the response cache.
-
-
-
-
-REQUEST_MEDIATION_LATENCY
-
-
-The request mediation latency.
-
-
-
-
-RESPONSE_MEDIATION_LATENCY
-
-
-The response mediation latency.
-
-
-
-
-BACKEND_LATENCY
-
-
-The backend latency.
-
-
-
-
-TOTAL_LATENCY
-
-
-The total latency.
-
-
-
-
-API_ERRORS
-
-
-The number of hits for which API errors are returned.
-
-
-
-
-
-TARGET_ERRORS
-
-
-The number of hits for which target errors are returned.
-
-
-Scalars¶
-Boolean¶
-Boolean scalar type represents true or false.Float¶
-Float scalar type represents signed double-precision fractional values as specified by IEEE 754.ID¶
-ID scalar type represents a unique identifier, often used to re-fetch an object or as the key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value is accepted as an ID.Int¶
-Int scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.String¶
-String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
-
-
-
-
-
-
-
-
-
-
Deploy a Web Application that Consumes a Backend Service¶
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create a project¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Display Name
-
-Sample project
-
-Name
-
-sample-project
-
-
-Project Description
-
-My sample projectStep 2: Connect your sample repository and configure the sample service¶
-
-
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-sample-book-list-app
-
-
-
-Branch
-
-mainreading-list-service.
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-Reading List Service
-
-
-Component Name
-reading-list-service
-
-
-Path
-reading-list-service
-
-
-Component Type
-Service
-
-
-Buildpack
-NodeJS
-
-
-
-Language Version
-20.x.x
-Reading List Service component to the Configured Components pane.Reading List Service component listed under Component Listing on the project home page.Step 3: Build the service¶
-
-
-Reading List Service component listed under Component Listing. This takes you to the component overview page.Step 4: Deploy the service¶
-
-
-Step 5: Test the service¶
-
-
-
-
-
-
-
-
-
-Parameter
-Value
-
-
-author
-Bram Stoker
-
-
-status
-to_read
-
-
-
-title
-Dracula
-201 HTTP code.Step 6: Consume the service¶
-Reading List Service is deployed and available in the Choreo Marketplace, application developers can discover the service via the Marketplace and consume it. Step 6.1: Create a web application to consume the service¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-Reading List Web App
-
-
-Component Name
-reading-list-web-app
-
-
-
-Description
-Front-end application for the reading list service
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-sample-book-list-app
-
-
-
-Branch
-main
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Directory
-/choreo-sample-book-list-app/reading-list-front-end-with-managed-auth
-
-
-Build Command
-npm install && npm run build
-
-
-Build Path
-dist
-
-
-
-Node Version
-18
-Step 6.2: Create a connection between the web application and the deployed service¶
-
-
-Reading List Service.`
-
-
-
-
-
-
-Field
-Value
-
-
-Name
-Reading List Connection
-
-
-
-Description
-Connection to the reading list
-Step 6.3: Build the web application component¶
-
-
-Step 6.4: Configure and deploy the web application¶
-
-
-config.js file mount.
-
-<Service URL> with the value that you copied when creating a connection to the Reading List Service in step 6.2./app/public as ./public/config.js within your web application.
-
-
-
-
-
-
-Field
-Value
-
-
-Post Login Path
-/
-
-
-Post Logout Path
-/
-
-
-
-Error Path
-/
-
-
-
-
-
-
-Step 7: Test the front-end application¶
-
-
-
-
-
-
-
-
-
-Title
-Author
-Status
-
-
-The Museum of Innocence
-Orhan Pamuk
-reading
-
-
-The Remains of the Day
-Kazuo Ishiguro
-to_read
-
-
-
-David Copperfield
-Charles Dickens
-read
-
-
-
-
-
-
-
-
Deploy Your First Service¶
-
-
-Nodejs buildpack. It runs on port 8080.Prerequisites¶
-
-
-
-
-Stark Industries.Learn the repository file structure¶
-<choreo-sample-book-list-service>/.
-
-
-
-
-
-
-Filepath
-Description
-
-
-app.mjs
-The Node.js (JavaScript) based service code.
-
-
-.choreo/endpoints.yaml
-Choreo-specific configuration that provides information about how Choreo exposes the service.
-
-
-
-openapi.yaml
-OpenAPI contract of the service. This is required to publish our service as a managed API. This openapi.yaml file is referenced by the .choreo/endpoints.yaml.
-Step 1: Create a project¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Display Name
-Book List Project
-
-
-Name
-book-list-project
-
-
-
-Project Description
-My sample project
-Step 2: Create a service component¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Component Display Name
-Book List
-
-
-
-Description
-Gets the book list
-
-
-
-
-
-
-
-
-
-Field
-Description
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-sample-book-list-service
-
-
-
-Branch
-main
-
-
-
-
-
-
-
-Field
-Description
-
-
-NodeJS Project Directory
-/
-
-
-
-Language Version
-20.x.x
-Step 3: Build and deploy¶
-Step 3.1: Build¶
-
-
-Book List component listed under Component Listing. This takes you to the component overview page.Step 3.2: Deploy¶
-
-
-Step 4: Test the service¶
-
-
-
-
-
-
-
-
Deploy Your First Static Web Application¶
-
-
-Prerequisites¶
-
-
-
-
-Stark Industries.Step 1: Create a project¶
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Project Display Name
-
-Sample project
-
-Name
-
-sample-project
-
-
-Project Description
-
-My sample projectStep 2: Create a Web Application component¶
-
-
-
-
-
-
-
-
-
-
-
-Field
-Value
-
-
-Organization
-Your GitHub account
-
-
-Repository
-choreo-sample-todo-list-app
-
-
-
-Branch
-
-main
-
-
-
-
-
-
-Field
-Value
-
-
-NodeJS Project Directory
-/
-
-
-Language Version
-20.x.x
-
-
-
-Port
-
-8080Step 3: Build your web application¶
-
-
-Step 4: Deploy and access your web application¶
-
-
-
-
-
-
-
-
Choreo Limitations¶
-API management limits¶
-
-
-
-
-
-
-
-Resource
-Limit
-
-
-Maximum request payload
-10 MB
-
-
-URL size
-2 KB
-
-
-Request header
-
-
-
-Total request duration
-
-
-
-Size for API Definition (OpenAPI document)
-10 Mb
-
-
-Number of APIs for PDP
-1000 API deployments
-
-
-Number of APIs per organization (free tier)
-5 APIs for free users
-
-
-
-Number of Developer Portal applications per organization (free tier)
-10 applications for free users
-Choreo Cloud Data Plane limits¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resource
-Limit
-
-
-Request size limit (including headers, cookies, and payloads)
-256 KB
-
-
-Response body size limit
-20 MB
-
-
-
-Number of open ports permitted per web application
-1
-
While it is possible to have multiple ports open for project-level communication within a data plane, incoming internet traffic can only be directed to a single port. This contrasts with Service-type components, which allow for multiple endpoints.
-
-
-
-
-
Frequently Asked Questions¶
-General¶
-Q: What is Choreo?¶
-Q: What is an organization in Choreo?¶
-Q: What is a project in Choreo?¶
-Q: What is a component in Choreo?¶
-Q: What is the difference between an internal and external API?¶
-Q: What is a connector in Choreo Marketplace?¶
-Q: What is a trigger in Choreo Marketplace?¶
-Q: What is a sample/template in Choreo?¶
-Q: What are the support options in Choreo?¶
-free, basic, and enterprise options at https://wso2.com/choreo/customer-support/.Q: How can I perform log monitoring or analytics for the Azure environment?¶
-Q: What is the maximum request payload size supported by Choreo?¶
-Q: What source control software does Choreo support?¶
-Q: Why don't I see the undeployed builds for my component in Choreo?¶
-Q: What is Ballerina?¶
-Q: What is Asgardeo?¶
-Q: Why don’t I see the region selector on the project creation page?¶
-Q: As a Cloud Data Plane user, how can I create components in multiple data planes?¶
-Security and data protection¶
-Q: How is data managed in Choreo?¶
-Q: What is the WSO2 Subprocessor list?¶
-Q: How do we secure WSO2 Private and Public Clouds?¶
-Q: How can I connect a Choreo component with a protected third-party application?¶
-
-
-
-
-
-
-
-
-Data planes¶
-Q: What is a Choreo control plane?¶
-Q: What is a data plane?¶
-Q: Which regions support the Choreo data plane(CDP)?¶
-Q: Which regions support private data planes(PDPs)?¶
-Q: If I want to use my Azure AKS instances as the private data plane, what are the minimum requirements I should meet?¶
-Q: Are the Choreo control plane and data planes highly available? Are they running on multiple clusters?¶
-Environments¶
-Q: As a Choreo cloud data plane user, why can't I create environments?¶
-Q: I am a Pay-As-You-Go (PAYG) customer using the Choreo cloud data plane. How many environments can I create?¶
-Q: I am an Enterprise subscription customer using the Choreo private data plane. How many environments do I get?¶
-Q: As a Choreo cloud data plane user, why don’t I see both US & EU data planes in the data plane selector when creating an environment?¶
-Q: I am a customer who use Choreo in a private data plane. How many environments can I create?¶
-Billing and support¶
-Q: Whom do I reach out to if I have a billing question?¶
-Q: What's a Developer plan?¶
-Q: How do I calculate the infrastructure costs?¶
-
-
-Q: What are the component limitations?¶
-
-
-Q: How do I read the bill?¶
-Q: Is support included in the Choreo Enterprise plan?¶
-Q: I am an Enterprise subscription customer who wants to use the Choreo private data plane. What costs will I incur in addition to the subscription and support plan?¶
-Q: I want to upgrade from PAYG to an Enterprise subscription. Will there be an outage during the upgrade?¶
-Choreo CLI¶
-Q: How do I uninstall the CLI?¶
-.choreo directory in the
-home directory of your operating system.Q: How do I update the CLI?¶
-Q: What are the supported component types in the CLI?¶
-Q: How do I get help with a specific command in the CLI?¶
-Q: What are the build configurations required when creating components using the CLI?¶
-choreo create component <name> --project <name> --build-configs='key1=value1,key2=value2'
-choreo create component <name> --project <name> --build-configs='key1=value1' --build-configs='key2=value2'
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Component Type
- Buildpack
- Required Configurations
-
-
- Service
- Python
-
-
-
-
-
-
- Node.js
-
-
-
-
-
-
- Java
-
-
-
-
-
-
- Go
-
-
-
-
-
-
- PHP
-
-
-
-
-
-
- Ruby
-
-
-
-
-
-
- Docker
-
-
-
-
-
-
- Ballerina
-
-
-
-
-
-
- WSO2 MI
-
-
-
-
-
-
- .Net
-
-
-
-
-
-
- Webapp
- Python
-
-
-
-
-
-
- Node.js
-
-
-
-
-
-
- Go
-
-
-
-
-
-
- PHP
-
-
-
-
-
-
- Ruby
-
-
-
-
-
-
- .Net
-
-
-
-
-
-
- Docker
-
-
-
-
-
-
- Static website
-
-
-
-
-
-
- React
-
-
-
-
-
-
- Angular
-
-
-
-
-
-
- Vue
-
-
-
-
-
-
- Webhook
- Python
-
-
-
-
-
-
- Node.js
-
-
-
-
-
-
- Java
-
-
-
-
-
-
- Go
-
-
-
-
-
-
- PHP
-
-
-
-
-
-
- Ruby
-
-
-
-
-
-
- Docker
-
-
-
-
-
-
- Ballerina
-
-
-
-
-
-
- WSO2 MI
-
-
-
-
-
-
- Scheduled Task
- Python
-
-
-
-
-
-
- Node.js
-
-
-
-
-
-
- Java
-
-
-
-
-
-
- Go
-
-
-
-
-
-
- .Net
-
-
-
-
-
-
- PHP
-
-
-
-
-
-
- Ruby
-
-
-
-
-
-
- Docker
-
-
-
-
-
-
- Ballerina
-
-
-
-
-
-
- WSO2 MI
-
-
-
-
-
-
- Manual Task
- Python
-
-
-
-
-
-
- Node.JS
-
-
-
-
-
-
- Java
-
-
-
-
-
-
- Go
-
-
-
-
-
-
- .Net
-
-
-
-
-
-
- PHP
-
-
-
-
-
-
- Ruby
-
-
-
-
-
-
- Docker
-
-
-
-
-
-
- Ballerina
-
-
-
-
-
-
-
-WSO2 MI
-
-
-
-
-
-
-
-
-
-
Private Data Plane Management Models¶
-WSO2 fully managed (infrastructure and PDP in WSO2 subscription) model¶
-
-
-
-
-
-
-
-
-Task
-Task description
-Responsible party
-Accountable
-Consulted
-Informed
-
-
-Subscription prerequisites
-- Create subscriptions
- - Check quota and service limits
- - Run the Choreo compatibility prerequisite script
-WSO2
-WSO2
-Customer (If required)
-Customer (If required)
-
-
-Remote access for installation
-Provide owner access
-WSO2
-WSO2
-WSO2
-WSO2
-
-
-Network management
-- Obtain customers backend CIDR in case of VPN/peering
- - Check end-to-end connectivity (primary and failover)
-WSO2/Customer
-WSO2/Customer
-Customer
-Customer
-
-
-Firewall rules/access control
-Set up firewall and required rules depending on the security tier
-WSO2
-WSO2
-Customer
-Customer
-
-
-Infrastructure provisioning
-- Provision Bastion
- - Provision Kubernetes clusters
-WSO2
-WSO2
--
-Customer(If required)
-
-
-Kubernetes cluster management
-- Manage Kubernetes versions
- - Increase node pool size
-WSO2
-WSO2
-Customer
-Customer
-
-
-Infrastructure monitoring
-Set up alerts
-WSO2
-WSO2
--
-Customer(If required)
-
-
-DNS management for Choreo system
-- Manage DNS infrastructure
- - Manage SSL certificates for Choreo system components
-WSO2/Customer
-WSO2/Customer
-Customer
-Customer
-
-
-Choreo system components deployment
-Set up PDP agents via Helm
-WSO2
-WSO2
--
--
-
-
-Choreo system components management
-Upgrade/patch/debug versions
-WSO2
-WSO2
--
-Customer(If required)
-
-
-Choreo system components monitoring
-- Set up continuous monitoring 24x7
- - Provide monthly uptime reports
-WSO2
-WSO2
--
-Customer
-
-
-Choreo system security monitoring
-If basic tier
- - CSPM
- - Apply security patches
- - Manage supply chain security (Image scanning, SAST)
- - Manage security incidents
- If standard tier/premium tier
- - CSPM
- - Apply security patches
- - Manage supply chain security
- - Monitor runtime security alerts (Azure Defender)
- - Monitor security incident and event management (SIEM) alerts
- - Manage security incidents
- - Adhere to compliance standards
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-
-
-Choreo application creation/deployment
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application management
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application monitoring
-
- Customer
-Customer
-Customer
-Customer
-
-
-
-Choreo application logs
-
- Customer
-Customer
-Customer
-Customer
-WSO2 fully managed (infrastructure and PDP in customer subscription) model¶
-
-
-
-
-
-
-
-
-Task
-Task description
-Responsible party
-Accountable
-Consulted
-Informed
-
-
-Subscription prerequisites
-- Create subscriptions
- - Check quota and service limits
- - Run the Choreo compatibility prerequisite script
-Customer
-Customer
-WSO2
--
-
-
-Remote access for installation
-Provide access
-Customer
-Customer
-WSO2
-WSO2
-
-
-Network management
-- Obtain customers backend CIDR in case of VPN/peering
- - Check end-to-end connectivity (primary and failover)
-WSO2/Customer
-WSO2/Customer
-Customer
-Customer
-
-
-Firewall rules/access control
-Set up firewall and required rules depending on the security tier
-WSO2/Customer
-WSO2/Customer
-Customer
-Customer
-
-
-Infrastructure provisioning
-- Provision Bastion
- - Provision Kubernetes clusters
-WSO2
-WSO2
-Customer
-Customer
-
-
-Kubernetes cluster management
-- Manage Kubernetes versions
- - Increase node pool size
-WSO2
-WSO2
-Customer
-Customer
-
-
-Infrastructure monitoring
-Set up alerts
-WSO2
-WSO2
--
-Customer(If required)
-
-
-DNS management for Choreo system
-- Manage DNS infrastructure
- - Manage SSL certificates for Choreo system components
-WSO2/Customer
-WSO2/Customer
-Customer
-Customer
-
-
-Choreo system components deployment
-Set up PDP agents via Helm
-WSO2
-WSO2
-Customer
--
-
-
-Choreo system components management
-Upgrade/patch/debug versions
-WSO2
-WSO2
--
-Customer(If required)
-
-
-Choreo system components monitoring
-- Set up continuous monitoring 24x7
- - Provide monthly uptime reports
-WSO2
-WSO2
--
-Customer
-
-
-Choreo system security monitoring
-If basic tier
- - CSPM
- - Apply security patches
- - Manage supply chain security (Image scanning, SAST)
- - Manage security incidents
- If standard tier/premium tier
- - CSPM
- - Apply security patches
- - Manage supply chain security
- - Monitor runtime security alerts (Azure Defender)
- - Monitor security incident and event management (SIEM) alerts
- - Manage security incidents
- - Adhere to compliance standards
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-
-
-Choreo application creation/deployment
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application management
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application monitoring
-
- Customer
-Customer
-Customer
-Customer
-
-
-
-Choreo application logs
-
- Customer
-Customer
-Customer
-Customer
-Customer self-managed (WSO2 provides installation script and updates) model¶
-
-
-
-
-
-
-
-
-
-
-
-
-
-Task
-Task description
-Responsible party
-Accountable
-Consulted
-Informed
-
-
-Subscription prerequisites
-- Create subscriptions
- - Check quota and service limits
- - Run the Choreo compatibility prerequisite script
-Customer
-Customer
-WSO2
-WSO2
-
-
-Remote access for installation
-Provide owner access
-Customer
-Customer
-WSO2
--
-
-
-Network management
-- Obtain customers backend CIDR in case of VPN/peering
- - Check end-to-end connectivity (primary and failover)
-Customer
-Customer
-WSO2
-WSO2
-
-
-Firewall rules/access control
-Set up firewall and required rules depending on the security tier
-Customer
-Customer
-WSO2
-WSO2
-
-
-Infrastructure provisioning
-- Provision Bastion
- - Provision Kubernetes clusters
-Customer
-Customer
-WSO2
-WSO2(If required)
-
-
-Kubernetes cluster management
-- Manage Kubernetes versions
- - Increase node pool size
-Customer
-Customer
-WSO2
-WSO2(If required)
-
-
-Infrastructure monitoring
-Set up alerts
-Customer
-Customer
-WSO2
--
-
-
-DNS management for Choreo system
-- Manage DNS infrastructure
- - Manage SSL certificates for Choreo system components
-Customer
-Customer
-WSO2
--
-
-
-Choreo system components deployment
-Set up PDP agents via Helm
-Customer
-Customer
-WSO2
--
-
-
-Choreo system components management
-Upgrade/patch/debug versions
-Customer
-Customer
-WSO2
--
-
-
-Choreo system components monitoring
-- Set up continuous monitoring 24x7
- - Provide monthly uptime reports
-Customer
-Customer
-WSO2
--
-
-
-Choreo system security monitoring
-If basic tier
- - CSPM
- - Apply security patches
- - Manage supply chain security (Image scanning, SAST)
- - Manage security incidents
- If standard tier/premium tier
- - CSPM
- - Apply security patches
- - Manage supply chain security
- - Monitor runtime security alerts (Azure Defender)
- - Monitor security incident and event management (SIEM) alerts
- - Manage security incidents
- - Adhere to compliance standards
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-WSO2/Customer
-
-
-Choreo application creation/deployment
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application management
-
- Customer
-Customer
-Customer
-Customer
-
-
-Choreo application monitoring
-
- Customer
-Customer
-Customer
-Customer
-
-
-
-Choreo application logs
-
- Customer
-Customer
-Customer
-Customer
-
-
-
-
-
-
Private Data Plane Security Levels¶
-
-
-
-
-
-
-
-
-Basic tier
-Standard tier
-Premium tier
-
-
-Distributed denial-of-service (DDoS) protection basic *
-Distributed denial-of-service (DDoS) protection basic *
-Distributed denial-of-service (DDoS) protection premium *
-
-
-Controlled admin access *
-Controlled admin access *
-Controlled admin access *
-
-
-End-to-end data encryption in transit
-End-to-end data encryption in transit
-End-to-end data encryption in transit
-
-
-Data encryption at rest *
-Data encryption at rest *
-Data encryption at rest *
-
-
-Secret management
-Secret management
-Secret management
-
-
-Foundational CSPM *
-Foundational CSPM *
-Premium CSPM *
-
-
-Static application security testing (SAST)
-Static application security testing (SAST)
-Static application security testing (SAST)
-
-
-Infrastructure as code (IaC) scanning
-Infrastructure as code (IaC) scanning
-Infrastructure as code (IaC) scanning
-
-
-Software composition analysis
-Software composition analysis
-Software composition analysis
-
-
-Docker image security scanning
-Docker image security scanning
-Docker image security scanning
-
-
-N/A
-Kubernetes runtime protection *
-Kubernetes runtime protection *
-
-
-N/A
-Web application firewall (WAF) *
-Web application firewall (WAF) *
-
-
-
-N/A
-N/A
-Network firewall *
-
-
-
-
-
-
Troubleshoot Choreo¶
-Troubleshoot component build errors¶
-
-
-Deploying an Angular web application displays the Nginx welcome page instead of the application's homepage.¶
-
-
-dist/<project-name>.An error occurs in the container Trivy scan when building a BYOC component.¶
-.trivyignore file to overcome the issue, ensure to add it to the Docker build context path specified when creating the component. For example, {buildContextPath}./trivyignore. The
-config.js file is not properly mounted in a web application.¶
-
-config.js file to the app/public directory in your repository.index.html file by adding a script tag as follows:<script src="public/config.js"></script>Troubleshoot component deployment errors¶
-
-
-The
-config.js file is not properly integrated during the deployment of a React application, causing it to render with unexpected HTML instead of the expected JavaScript configuration.¶config.js file, follow the steps given below:
-
-config.js file from the index.html file of your application by adding a script tag as follows: <script src="public/config.js"></script> config.js file is stored in your repository.<body> tag in your index.html file. You must ensure that it is not mistakenly placed within another HTML element.I'm not aware of the commits that can trigger an automatic build in Choreo.¶
-Troubleshoot web application issues¶
-
-
-After building a web application, the Nginx welcome page is displayed instead of the web application home page.¶
-index.html are copied to the Nginx root directory. To ensure that the correct files are copied during the build process, you must check the Docker build logs. The language I prefer to use is not available as a buildpack.¶
-I mistakenly used an incorrect build command when creating a web application. How can I update it before triggering a build?¶
-Troubleshoot managed-authentication issues¶
-
-
-After securing a web application with managed authentication, I’m not able to add users who can sign in to the application.¶
-Troubleshoot Tailscale proxy issues¶
-
-
-
-
-
-
-
-
- Where can I find logs to troubleshoot Tailscale proxy issues?¶
-I'm not able to connect the Tailscale proxy node to my Tailscale network due to an authentication failure.¶
-
-
-TS_AUTH_KEY:2024-06-04T10:38:53.885800940Z To authenticate, visit:
-2024-06-04T10:38:53.885802684Z
-2024-06-04T10:38:53.885815708Z https://login.tailscale.com/a/696841f011517
-2024-06-04T10:38:53.885817457Z
-2024-06-04T10:38:55.194344862Z Waiting for tailscale up to complete...
-2024-06-04T10:38:57.198970796Z Waiting for tailscale up to complete...
-2024-06-04T10:38:59.203265659Z Waiting for tailscale up to complete...
-2024-06-04T11:33:58.762363181Z 2024/06/04 11:33:58 Received error: invalid key: unable to validate API key
-2024-06-04T11:33:58.762458209Z backend error: invalid key: unable to validate API key
-I'm not able to access private endpoints although the Tailscale proxy is properly connected to my Tailscale network.¶
-
-
-Config.yaml file (mounted to Tailscale proxy during deployment) match the IP addresses in your Tailscale network.endpoints.yaml file with the port mappings in the Config.yaml file.
"},{"location":"administer/configure-a-custom-domain-for-your-organization/","title":"Configure a Custom Domain for Your Organization","text":"
"},{"location":"administer/configure-a-custom-domain-for-your-organization/#add-a-custom-domain","title":"Add a custom domain","text":"
apis.choreo.dev, the SSL file must include apis.choreo.com.apis.choreo.dev, the SSL file should use *.choreo.dev.
"},{"location":"administer/configure-a-custom-domain-for-your-organization/#approve-a-custom-url-request","title":"Approve a custom URL request","text":"
username,password,groups,first_name,last_name,email\n\"demouser\",\"password1\",\"[manager, engineering]\",\"John\",\"Doe\",\"john@acme.org\"\n.csv file. To include more user attributes, add columns as required in the .csv file.
"},{"location":"administer/configure-enterprise-login/","title":"Configure Enterprise Login","text":"
"},{"location":"administer/configure-enterprise-login/#configure-enterprise-login-for-your-choreo-organization","title":"Configure enterprise login for your Choreo organization","text":"
choreo-help@wso2.com requesting to enable enterprise login for your organization.
@ or leave it blank Time to Live (TTL) Keep the default value or use 86400 Value/Answer/Destination wso2-domain-verification:<verification_code>
"},{"location":"administer/configure-enterprise-login/#step-1-configure-asgardeo","title":"Step 1: Configure Asgardeo","text":"
"},{"location":"administer/configure-enterprise-login/#step-2-map-choreo-groups-to-enterprise-idp-groups-via-the-choreo-console","title":"Step 2: Map Choreo groups to enterprise IdP groups via the Choreo Console","text":"
"},{"location":"administer/configure-self-sign-up/#configure-developer-portal-self-sign-up","title":"Configure Developer Portal self-sign-up","text":"
https://devportal.choreo.dev/starkindustries.
"},{"location":"administer/configure-self-sign-up/#enable-auto-approval-for-new-user-registrations","title":"Enable auto-approval for new user registrations","text":"
"},{"location":"administer/control-access-in-the-choreo-console/","title":"Control Access in the Choreo Console","text":"
"},{"location":"administer/control-access-in-the-choreo-console/#step-2-create-a-new-group","title":"Step 2: Create a new group","text":"Engineering Project Name engineering-project Project Description My sample project Engineering Project Developer:
"},{"location":"administer/control-access-in-the-choreo-console/#step-3-assign-roles-to-the-group","title":"Step 3: Assign roles to the group","text":"Engineering Project Developer Group Description Users with development access within the engineering project
Add an existing user as a project developer
Try our APIs!).#C3C5CD and the primary color of the buttons to #086634).
"},{"location":"administer/inviting-members/","title":"Inviting members","text":""},{"location":"administer/inviting-members/#inviting-users","title":"Inviting users","text":"
"},{"location":"administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp/#add-asgardeo-as-an-external-idp-in-choreo","title":"Add Asgardeo as an external IdP in Choreo","text":"
"},{"location":"administer/configure-an-external-idp/configure-azure-ad-as-an-external-idp/#add-azure-active-directory-as-an-external-idp-in-choreo","title":"Add Azure Active Directory as an external IdP in Choreo","text":"
"},{"location":"api-management/api-policies/","title":"API Policies","text":"Well-Known URL of your Azure AD instance, on your Azure account, under Azure Active Directory go to App registrations, and then Endpoints. Copy the URI underOpenID Connect metadata document.
Well-Known URL, omit the v2.0 path segment from the URL. Learn more For example, convert https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration-> https://login.microsoftonline.com/<tenant-id>/.well-known/openid-configurationRequest, Response, or Error flow of an API invocation before it reaches the backend or the client. For example, you can add a policy to the response flow to transform the payload from JSON to XML and add a header to the response.
${headerName}.${fooValue}.${authzHeaderValue}.${authzHeaderValue}. ${myResourcePath}.Log Headers and Log Payload parameters. To exclude specific headers when logging, you can use the Excluded Headers parameter, which takes a comma-separated list of header names. An error will occur if payload logging is enabled but the payload cannot be read.
"},{"location":"api-management/api-policies/#attach-a-policy","title":"Attach a policy","text":"Response flow or the Error flow. Then the response is forwarded to the client.Error flow and sends an error response to the client.Request, Response, or Error flow of a REST API proxy, follow the steps given below:
${<variableName>} format. For example, you can use ${name} as an example.
"},{"location":"api-management/api-policies/#refresh-mediation-policies","title":"Refresh mediation policies","text":"
"},{"location":"api-management/api-policies/#implement-an-api-policy","title":"Implement an API policy","text":"
~/.ballerina/settings.toml file and ensure you have configured an access token to Ballerina Central. If you have not configured an access token, follow the steps given below to configure one:
Settings.toml file and copy it to your local ~/.ballerina directory.BALLERINA_CENTRAL_ACCESS_TOKEN environment variable.
"},{"location":"api-management/api-policies/#step-1-initialize-a-ballerina-project","title":"Step 1: Initialize a Ballerina project","text":"export BALLERINA_CENTRAL_ACCESS_TOKEN=<access-token> \nmediation.template as the project template, issue the following command: bal new -t choreo/mediation.template:1.0.0 <policy-name> \n
The Ballerina project that is created should have the following content: bal new -t choreo/mediation.template:1.0.0 validateHeader \n
Depending on your requirement, you can modify the Ballerina.toml and the Package.md files of the generated project. For example, you can update the org, package, package version, API documentation content, keywords, etc.
Note
To successfully publish to Ballerina Central, make sure you update the org value to your organization name.
[package]\n org = \"starkindustries\"\n name = \"validateHeader\"\n version = \"1.0.0\"\n export = [\"validateHeader\"]\n distribution = \"2201.5.5\"\n keywords = [\"choreo-apim-mediation-policy\",\"choreo-apim-mediation-request-flow\",\"choreo-apim-mediation-response-flow\",\"choreo-apim-mediation-fault-flow\"]\n"},{"location":"api-management/api-policies/#step-2-implement-the-policy","title":"Step 2: Implement the policy","text":"In this step, you will implement the policy.
Let's assume you want to implement a policy to validate an incoming header in the request and the response.
403 Bad Request response to the client.To implement the policy, open the policy.bal file in the Ballerina project and update the generated policy stubs(i.e., request, response, or fault) appropriately.
The following sections walk you through sample implementations for the Request and Response stubs:
Request flowThe following is a sample implementation for the request flow:
@mediation:RequestFlow\npublic function validateRequestHeader(mediation:Context ctx, http:Request req, string headerName, string headerValue) returns http:Response|false|error|() {\n string|http:HeaderNotFoundError header = req.getHeader(headerName);\n if (header is http:HeaderNotFoundError) {\n string message = string `Header ${headerName} is not found`;\n log:printError(message);\n return generateResponse(message, http:STATUS_BAD_REQUEST);\n }\n if (header != headerValue) {\n string validationFailedMessage = string `Header validation failed. Expected ${headerValue} but found ${header}`;\n log:printError(validationFailedMessage);\n return generateResponse(validationFailedMessage, http:STATUS_BAD_REQUEST);\n }\n log:printInfo(\"Header validation successful\");\n return ();\n};\n\nfunction generateResponse(string message, int statusCode) returns http:Response {\n http:Response response = new();\n response.setTextPayload(message); \n response.statusCode = statusCode;\n return response;\n}\n Response flow The following is a sample implementation for the response flow:
@mediation:ResponseFlow\npublic function validateResponseHeader(mediation:Context ctx, http:Request req, http:Response res, string headerName, string headerValue) returns http:Response|false|error|() { \n string|http:HeaderNotFoundError header = res.getHeader(headerName);\n if (header is http:HeaderNotFoundError) {\n string message = string `Header ${headerName} is not found`;\n log:printError(message);\n return ();\n }\n if (header != headerValue) {\n string validationFailedMessage = string `Header validation failed. Expected ${headerValue} but found ${header}`;\n log:printError(validationFailedMessage);\n return ();\n }\n return ();\n}\n Fault flow In this guide, you are not going to make any changes to the Fault flow. Therefore, you can remove the Fault flow stub from the policy.bal file.
Note
The @mediation:RequestFlow, @mediation:ResponseFlow, and @mediation:FaultFlow annotations are bound with the keywords in the Ballerina.toml. Therefore, the changes you make to the policy stubs should reflect in the Ballerina.toml file. For example, if the policy is applicable only on the request and response paths, you can remove the @mediation:FaultFlow annotation from the policy. Then, you MUST also remove the choreo-apim-mediation-fault-flow keyword from the generated Ballerina.toml file. If you do not do so, the Ballerina compiler will show an error at compile time.
Choreo supports publishing a policy as a private custom policy. Publishing a policy as a private custom policy makes the policy inaccessible outside of the organization. To publish a policy as a private custom policy, change the visibility to private prior to pushing the package to Ballerina Central as follows:
Ballerina.toml file of your policy. Set the visibility to private by adding the configuration visibility=\"private\". For example:
[package]\n org = \"orgName\"\n name = \"packageName\"\n version = \"1.0.2\"\n export = [\"packageName\"]\n distribution = \"2201.5.5\"\n keywords = [\"choreo-apim-mediation-policy\",\"choreo-apim-mediation-request-flow\",\"choreo-apim-mediation-response-flow\",\"choreo-apim-mediation-fault-flow\"]\n visibility = \"private\"\n Package and publish your policy to Ballerina Central.
When implementing a policy, it is essential to follow best practices to ensure efficiency and maintainability. Here are some recommended best practices to follow:
Request, Response, and Fault. You can remove any stub that you do not require. For example, when you create a policy that re-writes the resource paths, you can remove the Response and fault stubs. false if you want to terminate the mediation sequence with a predefined response (on the Choreo side).Once you implement a policy, you must publish it to Ballerina Central.
When you attach a policy and deploy an API, Choreo pulls the necessary packages from Ballerina Central and bundles them into the mediation application under the hood. Therefore to use policies in your APIs, you must publish them as public packages.
To publish the policy, follow the steps given below:
bal pack \nTo publish the package to Ballerina Central, issue the following command:
bal push \n Once you publish the package, it will appear as follows in the policy list:
"},{"location":"api-management/api-policies/#write-unit-tests","title":"Write unit tests","text":"You can write unit tests to test policy functions in a manner similar to how you write unit tests for a regular Ballerina function.
The following is a sample unit test for the validateRequestHeader function:
import ballerina/http;\nimport choreo/mediation;\nimport ballerina/test;\n\n@test:Config {}\npublic function testRequestHeaderValidationFailure() {\n http:Request req = new;\n http:Response|false|error|() result = validateRequestHeader(createContext(\"get\", \"/test\"), req, \"testHeader\", \"test\");\n\n if !(result is http:Response) {\n test:assertFail(\"Expected http:Response, found \" + (typeof result).toString());\n }\n\n test:assertEquals(result.statusCode, http:STATUS_BAD_REQUEST, \"Status code mismatch\");\n}\n\nfunction createContext(string httpMethod, string resPath) returns mediation:Context {\n mediation:ResourcePath originalPath = checkpanic mediation:createImmutableResourcePath(resPath);\n mediation:Context originalCtx =\n mediation:createImmutableMediationContext(httpMethod, originalPath.pathSegments(), {}, {});\n mediation:ResourcePath mutableResPath = checkpanic mediation:createMutableResourcePath(resPath);\n return mediation:createMutableMediationContext(originalCtx, mutableResPath.pathSegments(), {}, {});\n}\n The policy function modifies the same request/response/context instance that you pass to it. You can check the request/response/context instance after calling the policy function to verify changes.
"},{"location":"api-management/api-policies/#glossary","title":"Glossary","text":"Here are some of the common terms used when working with policies in Choreo:
mediation:ContextThe mediation context is used to pass parameters between policies. It is created per request and you can access it in any of the flows. For example, if a correlation ID needs to be set to the request, you can set it in the context of the request flow and access it in the response or fault flow.
The mediation context can include the following functions:
# Retrieves the value for the specified key. \npublic function get(string name) returns anydata;\n\n# Stores the provided key-value pair. If a mapping exists for the key, the value is overwritten.\npublic function put(string name, anydata value);\n\n# Removes the entry mapped by the specified key and returns the removed value.\npublic function remove(string name) returns anydata;\n\n# Retrieves the value for the specified key. If there is no mapping for the key, return the specified\npublic function getOrDefault(string name, anydata default) returns anydata;\n\n# Checks whether a mapping exists for the specified key.\npublic function hasKey(string name) returns boolean;\n\n# Returns the `mediation:Context` instance which captured the initial contextual information of the resource,\n# before the mediation flow was invoked. Calling this on an original `mediation:Context` object will return itself.\npublic function originalContext() returns Context;\n\n# The HTTP method of the resource method\npublic function httpMethod() returns string;\n\n# Retrieves an instance of `mediation:ResourcePath` which is an API for contextual information on the resource path\n# of this resource. It also contains methods for modifying the resource path as the user sees fit. This resource\n# path is the same path used by the mediation service for deriving the backend endpoint's resource to invoke.\n# Therefore, the default behavior of the mediation service is to invoke a resource in the backend endpoint which\n# has the same relative resource path as the corresponding mediation service resource.\npublic function resourcePath() returns ResourcePath;\n\n# Sets the given `mediation:ResourcePath` instance as the resource path of this context.\npublic function setResourcePath(ResourcePath path);\n\n# Adds a mapping between a path param name and a resolved value for it. There need not be a path parameter in the\n# resource path by the name specified in `name` for one to use this method. On its own, the path param values have\n# no bearing on the resource path.\npublic function addPathParamValue(string name, PathParamValue value);\n\n# Returns the collection of resolved values for the path parameters in this particular context, mapped\n# by the parameter name.\npublic function resolvedPathParams() returns map<PathParamValue> & readonly;\n\n# Removes the resolved path parameter value which maps to the specified name.\npublic function removePathParamValue(string name);\n\n# Adds a query parameter to the request to be sent to the backend. If there is already a query parameter by\n# with the same name, the new value will be appended to it, making it an array.\npublic function addQueryParam(string name, string value);\n\n# Removes the specified query parameter from the request. If the value of the parameter is an array, the whole\n# array will be removed.\npublic function removeQueryParam(string name);\n\n# Retrieves a map of all the query parameters in the current request context. The returned map is a read-only snapshot\n# of the map of query parameters in the context at the time this method was called.\npublic function queryParams() returns map<string[]> & readonly;\n"},{"location":"api-management/api-policies/#keywords","title":"Keywords","text":"The Ballerina.toml file needs to include the following keywords for the mediation policies to work:
The Package.md file contains information about the policy. Choreo uses this information to render the policy configuring UI. This file is written in Markdown format and should be structured as follows.
Format:
# <policy-name>\n\n## Overview\n\n<policy description>\n Example:
# ValidateHeader\n\n## Overview\n\nThis policy validates the request and response headers with the configured values.\n Policy versioning When it comes to policy versioning in Choreo or mediation dependencies, it is important to consider the major version changes in the Ballerina language. For example, transitioning from update 1 to update 2 requires a major version increment, which can introduce significant incompatibilities.
Therefore, to ensure compatibility, the recommended approach is to version the policy package in a manner that the major version gets upgraded when the Choreo/mediation dependency version is upgraded to a major version.
"},{"location":"api-management/api-rate-limiting/","title":"API Rate Limiting","text":"API rate limiting is a technique that allows you to control the rate of requests made to an API. Rate limiting helps prevent system overload and enhances API performance. When you limit the number of requests that can be made in a specific time frame, you can ensure that your API is available and responsive to all users while protecting it from malicious attacks.
This page walks you through the steps to enable rate limiting for your APIs via Choreo and also provides information on the rate-limiting options supported by Choreo.
"},{"location":"api-management/api-rate-limiting/#enable-rate-limiting-for-an-api","title":"Enable rate limiting for an API","text":"To enable rate limiting for an API, follow the steps given below:
Note
You can apply rate-limiting settings separately for each environment.
Go to the required environment card and click the view icon corresponding to the endpoint for which you want to apply rate limiting.
Info
If you are applying rate limiting for an API Proxy component, go to the required environment card, click the setting icon corresponding to API Configuration, and proceed to step 6.
In the Endpoint Details pane that opens, click the settings icon.
API-level rate limiting applies the allocated request count for the specified time unit to all operations in the API.
"},{"location":"api-management/api-rate-limiting/#operation-level-rate-limiting","title":"Operation-level rate limiting","text":"Operation-level rate limiting allows you to configure different rate-limiting values for each operation. You can use this option to define specific rate-limiting values for critical API operations that require an extra layer of protection.
"},{"location":"api-management/api-rate-limiting/#rate-limiting-response-headers","title":"Rate-limiting response headers","text":"The following table lists the response headers available when you enable rate limiting for your APIs. You can implement necessary rate-limiting scenarios depending on the response header values.
Header Name Descriptionx-ratelimit-limit Denotes the request count allocated for the specified time unit. x-ratelimit-reset Provides the time remaining to start the next rate-limiting time unit. x-ratelimit-remaining Denotes the remaining request count for the specified time unit. x-ratelimit-enforced Visible after exceeding the allocated request count."},{"location":"api-management/control-api-visibility/","title":"Control API Visibility","text":"By default, the APIs published in Choreo are visible to anyone who visits the Choreo Developer Portal. By default, Choreo sets the visibility of the API to Public. However, developers can control the visibility of their APIs by changing the default option to Private or Restricted.
Visibility settings control users from viewing and modifying APIs. API visibility can be one of the following options:
Public : The API is visible to all in the developer portal.
Private : The API is visible to the users who only sign in to the Developer Portal.
Restricted: The API is visible to only the user that has the roles that you specify. This option helps developers to enforce fine-grained access control to the API.
Under General Details, select the required visibility setting from the Visibility list.
Enable fine-grained role-based access control to the API
Restricted from the API visibility list. Once selected, you will see the roles available in your organization in the Visible Roles list. Click Save.
When an API consumer signs in to the Choreo Developer Portal to browse APIs, it is not sufficient to just have an API thumbnail along with the name and version of the API. An API consumer would expect to see more details about the API, such as the following:
To provide such information that improves the overall visibility of the API, an API developer can add such documentation to an API before publishing it to the Developer Portal.
"},{"location":"api-management/documents/#add-documents-to-an-api","title":"Add documents to an API","text":"To add documentation for an API, follow the steps given below.
Sign in to the Choreo Console.
In the Component Listing pane, click on the component for which you want to add documents.
In the left navigation menu, click Manage and then click Documents.
Specify a title for the document and provide the content in markdown syntax.
Click Add to save the document.
Depending on the information you need to add to the API, you can add one or more documents.
You can also edit existing documents and delete documents if necessary.
"},{"location":"api-management/lifecycle-management/","title":"Lifecycle Management","text":"API lifecycle management is an important aspect of API management. The API lifecycle consists of various states that an API passes through, from creation to retirement. In Choreo, there are six distinct lifecycle states: created, pre-released, published, blocked, deprecated, and retired.
By leveraging the various lifecycle states, API managers can optimize the development process and ensure that subscribers have access to the latest and most reliable APIs.
"},{"location":"api-management/lifecycle-management/#api-lifecycle-states","title":"API lifecycle states","text":"The following lifecycle states are applicable to APIs in Choreo:
API lifecycle state Use case Corresponding action CREATED The API is created but is not ready for consumption. The API is not visible to subscribers in the Developer Portal. PRE-RELEASED A prototype is created for early promotion and consumer testing. You can deploy a new API or a new version of an existing API as a prototype to provide subscribers with an early implementation of the API. The API is published to the Developer Portal as a pre-release. PUBLISHED The API is ready for subscribers to view and subscribe to via the Developer Portal The API is visible in the Developer Portal and is available for subscription. BLOCKED Access to the API is temporarily blocked. Runtime calls are blocked, and the API is not visible in the Developer Portal. DEPRECATED The old version of an API is moved to this state when a newer version of the API is PUBLISHED. The API is deployed and is available to existing subscribers. New subscriptions are disabled. Existing subscribers can continue to use it as usual until the API is retired. RETIRED The API is no longer in use when it is in this state. The API is unpublished and deleted from the Developer Portal."},{"location":"api-management/lifecycle-management/#manage-the-lifecycle-of-an-api","title":"Manage the lifecycle of an API","text":"To change the lifecycle state of an API via the Choreo Console, follow the instructions given below:
Tip
You must have publishing privileges to manage the lifecycle states of a component.
Choreo allows you to make one or more endpoints accessible through its service and integration components. These endpoints are published as individual APIs in Choreo, accessible via the Choreo Developer Portal. By default, Choreo assigns an API name by combining the component name and the endpoint name, resulting in the following format: <component name>-<endpoint name>. For example, if you create a component named Ballerina Reading List, the API is displayed as Ballerina Reading List - GraphQL Reading List 591.
Choreo provides you with the flexibility to personalize the display name of the API, enhancing its user-friendliness and readability. Once you modify the API display name within the Choreo Console, Choreo applies the change immediately. From there onwards, Choreo displays the published API by this name in the Choreo Developer Portal.
Follow the steps below to rename the API display name:
Now, you can view the updated API display name in the Choreo Developer Portal.
"},{"location":"api-management/manage-api-traffic/assign-subscription-plans-to-apis/","title":"Assign Subscription Plans to APIs","text":"API subscription plans allow API publishers to control and manage access to APIs. These plans define the rules and limitations on how clients can interact with APIs, ensuring efficient resource utilization and robust security.
Choreo allows users with the administrator role to create, update, and delete subscription plans at the organization level. For instructions on creating subscription plans, see Create API Subscription Plans.
Once created, Choreo allows API publishers to assign subscription plans to APIs, providing different levels of access based on user needs.
To assign subscription plans to an API, follow the steps given below:
Enable the Subscription Plan Status toggle corresponding to the subscription plans you want to assign to the API.
Click Save.
When an API has subscription plans assigned to it, API consumers can select the plan that best fits their requirements during the subscription process. For details, see Subscribe to an API with a Subscription Plan
"},{"location":"api-management/manage-api-traffic/subscribe-to-an-api-with-a-subscription-plan/","title":"Subscribe to an API with a Subscription Plan","text":"If an API has subscription plans assigned to it, API consumer can select the subscription plan that best fits their requirement at the time of subscribing to the API.
To subscribe to an API with a subscription plan, follow the steps given below:
Click Add Subscription.
To verify that the subscription plan works as expected, follow the steps given below:
Invoke the API until you exceed the request limit set in the subscription plan. You will see that the API throttles further requests once the limit is reached.
Mutual transport layer security (mutual TLS) is a protocol that ensures privacy, integrity, and authentication of the data transmitted between two endpoints. In mutual TLS, the client and the server authenticate each other using digital certificates, establishing trust and verifying identities. Upon successful authentication, mutual TLS encrypts the data exchanged between the client and the server, preventing unauthorized access.
In Choreo, you can use mutual TLS to establish secure connections between components within a project.
Note
If mutual TLS is not required, you can configure TLS instead. TLS provides a secure communication channel between a client and server but does not require the client to present a certificate to the server. This results in the absence of mutual authentication between the client and the server. While TLS ensures the confidentiality of data transmitted between the client and server, preventing unauthorized tampering, mutual TLS enhances TLS by introducing client-side authentication and facilitating mutual verification of identities between the client and server.
To configure TLS, you can follow the same steps as for mutual TLS as mentioned below, without having to generate a client certificate. The client only needs the root certificate to verify the server's identity.
"},{"location":"authentication-and-authorization/configure-mutual-tls-between-components/#generate-certificates-to-establish-mutual-tls","title":"Generate certificates to establish mutual TLS","text":"Root certificate: Trusted by both the client and the server, this certificate is used to verify the authenticity of other certificates presented during the mutual TLS handshake process and to issue certificates for clients and servers. For a specific project, you can generate a single root certificate using a tool like OpenSSL.
Client certificate: Contains the client\u2019s identity for authentication. The common name (CN) in the certificate identifies the client. The generated client certificate must be signed by the root certificate.
Server certificate: Clients use the server certificate to verify the trustworthiness of the server and establish a secure and authenticated connection. Similar to the client certificates, the server certificate must also be signed by the root certificate. When generating the server certificate, you must specify the server's hostname for the subject alternative name (SAN). You can obtain the hostname for the specific version of a service component from any project endpoint on the Overview page.
For example, if your project endpoint is http://my-service-3781140846:7080/todos, the hostname will be my-service-3781140846.
The approach to read mutual TLS certificates from a component can vary depending on its implementation. Typically, a component can read the certificate data from the file system or via an environment variable. For detailed instructions on adding environment variables and file mounts to your application, see Manage Configurations and Secrets.
Info
When you specify a private key, ensure you save it as a secret.
"},{"location":"authentication-and-authorization/configure-mutual-tls-between-components/#sample-for-mutual-tls-communication","title":"Sample for mutual TLS communication","text":"For a sample that demonstrates how you can deploy services that communicate using mutual TLS, see service-to-service-mtls.
"},{"location":"authentication-and-authorization/pass-end-user-attributes-to-upstream-services/","title":"Pass End-User Attributes to Upstream Services","text":"There are scenarios where a backend service needs to apply specific logic or make decisions depending on the user consuming an API. In such scenarios, you must pass end-user attributes to the backend during an API call.
Choreo provides a method to send user information to a backend service through a JSON Web Token (JWT) in an HTTP header of an API request.
"},{"location":"authentication-and-authorization/pass-end-user-attributes-to-upstream-services/#how-it-works","title":"How it works","text":"The backend JWT contains claims transferred between the parties, such as the user and the backend. A claim can be metadata of the request or data about the user. A set of claims is called a dialect, for example, http://wso2.org/claims.
For each API request, a digitally signed JWT is carried to the backend service in the following format to ensure that the authenticity of the claims list is verified:
{token header}.{claims list}.{signature}
When a request goes through Choreo, the backend JWT is appended as the\u00a0X-JWT-Assertion\u00a0header in the outgoing message. The backend service fetches the JWT and retrieves the required information about the user, application, or token.
Claims are fragments of information included in the JWT.
The following is a sample claim set added to the end-user token for an access token generated via the authorization code:
Tip
This access token is generated via Asgardeo using the authorization code grant type. Here, the Asgardeo application is configured to include the email claim in the token.
{\n\"sub\": \"11f53c32-f8ac-4810-bb79-615b2184baf5\",\n\"http://wso2.org/claims/apiname\": \"JWT Test - Endpoint 9090 803\",\n\"http://wso2.org/claims/applicationtier\": \"Unlimited\",\n\"http://wso2.org/claims/version\": \"1.0.0\",\n\"http://wso2.org/claims/keytype\": \"PRODUCTION\",\n\"iss\": \"wso2.org/products/am\",\n\"http://wso2.org/claims/applicationname\": \"jwtTest2\",\n\"http://wso2.org/claims/enduserTenantId\": \"0\",\n\"http://wso2.org/claims/applicationUUId\": \"45101ccb-865f-4f48-b7ac-18e43b07edd3\",\n\"client_id\": \"IMJB5ZiR1dHQYBdiMIRAGis1WToa\",\n\"http://wso2.org/claims/subscriber\": \"5f4a7105-a889-4f92-9612-eef5bafe4eec\",\n\"azp\": \"IMJB5ZiR1dHQYBdiMIRAGis1WToa\",\n\"org_id\": \"b554e001-761c-4d3a-a7a6-a61d73d34221\",\n\"http://wso2.org/claims/tier\": \"Unlimited\",\n\"scope\": \"email openid profile\",\n\"exp\": 1690537362,\n\"http://wso2.org/claims/applicationid\": \"45101ccb-865f-4f48-b7ac-18e43b07edd3\",\n\"http://wso2.org/claims/usertype\": \"Application_User\",\n\"org_name\": \"test\",\n\"iat\": 1690533762,\n\"email\": \"testmail@gmail.com\",\n\"jti\": \"69558555-d386-4a81-9ca0-0a23f809cd3c\",\n\"http://wso2.org/claims/apicontext\": \"/b554e001-761c-4d3a-a7a6-a61d73d34221/swog/jwt-test/endpoint-9090-803/1.0.0\"\n}\n The following table describes the information contained in the sample JWT claims set given above:
Claim Name Description Mandatory/Optionaliat The time the token was issued. Mandatory jti The unique token identifier. Mandatory exp The token expiry time. Mandatory iss The issuer of the token. Mandatory http://wso2.org/claims/apiname The name of the API in Choreo. Optional http://wso2.org/claims/version The API version. Optional http://wso2.org/claims/keytype The environment in Choreo that the API is in (Development or production). Optional http://wso2.org/claims/apicontext The API context in Choreo. Optional http://wso2.org/claims/subscriber The subscriber to the API, usually the app developer. Optional http://wso2.org/claims/applicationname The application through which the API invocation is done. Optional http://wso2.org/claims/applicationid The ID of the application through which the API invocation is done. Optional http://wso2.org/claims/applicationUUId The UUID of the application. Optional client_id The client identifier. This is copied from the original token. Optional azp The authorized party (the party to which the ID token was issued). This is copied from the original token. Optional org_id The organization ID. This is copied from the original token. Optional org_name The organization name. This is copied from the original token. Optional http://wso2.org/claims/tier The tier/price band for the subscription. Optional scope The scope of the token. This is copied from the original token. Optional http://wso2.org/claims/usertype The type of application user whose action invoked the API. Optional email The email address of the user. This is copied from the original token. Optional Note
The claims that get added to the end-user token can vary depending on the grant type used when generating the access token. For example, if you use the client-credentials grant type to generate the access token, the generated backend JWT would contain the following information:
{ \"http://wso2.org/claims/apiname\": \"DefaultAPI\", \"http://wso2.org/claims/version\": \"1.0.0\", \"http://wso2.org/claims/keytype\": \"PRODUCTION\", \"iss\": \"wso2.org/products/am\", \"http://wso2.org/claims/enduserTenantId\": \"0\", \"exp\": 1673245727, \"http://wso2.org/claims/usertype\": \"Application_User\", \"iat\": 1673242127, \"jti\": \"6e3f4392-8bd9-4900-9d08-eaab7429c510\", \"http://wso2.org/claims/apicontext\": \"/9e71ab5e-6df5-4727-92d2-80ecf1a6218d/qbky/default/1.0.0\" }\n To verify the authenticity of claims in a JWT, the claims must be validated using the public key corresponding to the private key used to sign the JWT.
JSON web key set (JWKS) is a set of keys to validate a JWT. It contains a collection of JSON web keys, which are public keys used to verify the signature of a JWT.
Typically, when a third party (such as an identity provider)issues a JWT and the recipient needs to verify its signature, they can use a JWKS. JWKS allows the issuer to rotate keys dynamically rather than hard-coding the public key in the application. The recipient can obtain the public key by accessing the JWKS endpoint.
"},{"location":"authentication-and-authorization/pass-end-user-attributes-to-upstream-services/#jwks-support-in-choreo-to-validate-the-jwt","title":"JWKS support in Choreo to validate the JWT","text":"Choreo provides an endpoint to specify the public keys for backend JWT validation. Here are the endpoint URLs for the US East and EU regions:
Note
For private data planes (PDPs), use the following JWKS endpoint URL template:
https://<PDP_GATEWAY_DOMAIN>/.wellknown/jwks
Be sure to replace <PDP-GATEWAY-DOMAIN> with the default domain configured to access the PDP APIs.
The endpoint provides one or more signing keys to validate the JWT. The JSON web keys have a kid identifier that can be matched with the same property on the JWT to decide which key to use when validating.
The following is a sample JWKS response:
{\n\"keys\": [\n{\n\"kty\": \"RSA\",\n\"e\": \"AQAB\",\n\"use\": \"sig\",\n\"kid\": \"ZjcwNmI2ZDJmNWQ0M2I5YzZiYzJmZmM4YjMwMDFlOTA4MGE3ZWZjZTMzNjU3YWU1MzViYjZkOTkzZjYzOGYyNg\",\n\"alg\": \"RS256\",\n\"n\": \"8vjeHzRhvpfMystncPnLBWy_t5F3eCxbcLbdugWnzfnIgaV6TWnqPBUagJBKpzRZs4A9Qja_ZrSVJjYsbARzCS_qiWp0Cdwkqn6ZCXpmbpfjYnKORq8N8M-zWaSZYbNvWJ5oSO4kH-LKWzODaFebwTJBpsR1vChHH95doxFuUjiZaisVaQgUJ6drRdlDtImp9r9EAX36YROuYFPoEJcvsH4_uuAR6ClJ12RE3M-YN4NTi1waVNvGbz43oNrpPy7SXgpizingxSGMqI6WU2ysRmk_f9ALgiPIpFDpufiCTYaIcRT-YcUyp9nMDlTRskMuD-dQ1sdJOa11P_yMs-glfQ\"\n}\n]\n}\n The following table describes the information contained in the JWKS response:
Property Descriptionkty The cryptographic family to which the key belongs. Choreo only supports RSA. e The exponent value of the public key. use The purpose of the key. For example, whether it is for signing or encryption. kid The identification parameter to match a specific key. alg The algorithm to use with the key. n The modulus value of the public key."},{"location":"authentication-and-authorization/pass-end-user-attributes-to-upstream-services/#enable-passing-end-user-attributes-to-the-backend","title":"Enable passing end-user attributes to the backend","text":"To enable passing end-user attributes to the backend through API calls via Choreo, follow the steps given below:
Go to the Set Up card and click Endpoint Configurations. This opens the Endpoint Configurations pane.
Note
If the component is an API Proxy, go to the Build Area card and click Security Settings. This opens the Security Settings pane.
Select the\u00a0Pass Security Context To Backend checkbox.
Optionally, specify appropriate audience values in the End User Token Audiences field. Specifying values restricts the JWT to the respective audiences, enabling the backend service to validate and confirm the intended recipients, including itself.
Note
The backend JWT does not include the audience field (aud) by default.
Click\u00a0Apply.
API security refers to the measures and practices used to protect Application Programming Interfaces (APIs) from potential threats and vulnerabilities. APIs are essential for enabling communication and data exchange between different software applications and services, making them a critical component in modern software development. However, their openness and accessibility can also make them targets for various security risks. Authentication and authorization are key aspects of API security. Authentication is ensuring that only authorized users or applications can access the API. This can involve using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization is controlling what authenticated users or applications are allowed to do within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions.
Organizations using Asgardeo for identity and access management (IAM) can seamlessly integrate it with Choreo as an external Identity Provider (IdP). This guide will walk you through setting up Choreo to authenticate API invocations through Asgardeo which is configured as an external IdP.
This guide walks you through the following steps:
To follow this guide, you need to satisfy the following prerequisites:
You can provide fine-grained access control to your API resources with scopes. Follow the steps below to assign a scope to the resources in the API:
Follow the Asgardeo API Authorization guide to create an application and an API in Asgardeo and to enable API authorization.
Note
JWT as the Access Token.Follow the steps below to consume the Choreo API and use an external IdP for authentication:
Asgardeo.Click +Add.
Note
In the left navigation menu, click Subscriptions.
Obtain an access token by invoking the token endpoint as follows:
Note
curl -X POST '<TOKEN_ENDPOINT>?grant_type=password&scope=<REQUIRED_SCOPES>&username=<USER_NAME>&password=<USER_PASSWORD>' \\\n--header 'Content-Type: application/x-www-form-urlencoded' \\\n--header 'Authorization: Basic <BASE64-ENCODED ASGARDEO_APP_CLIENT_ID:ASGARDEO_APP_CLIENT_SECRET>'\n curl -X POST 'https://dev.api.asgardeo.io/t/orgHandle/oauth2/token?grant_type=password&scope=<REQUIRED_SCOPES>&username=<USER_NAME>&password=<USER_PASSWORD>' \\\n--header 'Content-Type: application/x-www-form-urlencoded' \\\n--header 'Authorization: Basic <BASE64-ENCODED CLIENT_ID:CLIENT_SECRET>'\n Once you receive the access token, you can test invoking the resource using the OpenAPI console in Choreo by specifying the scope.
API security refers to the measures and practices used to protect Application Programming Interfaces (APIs) from potential threats and vulnerabilities. Authentication and authorization are key aspects of API security. Authentication is ensuring that only authorized users or applications can access the API. This can involve using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization is controlling what authenticated users or applications are allowed to do within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions.
Organizations using Microsoft Azure AD for identity and access management (IAM) can seamlessly integrate it with Choreo as an external Identity Provider (IdP). This guide will walk you through setting up Choreo to authenticate API invocations through Azure AD which is configured as an external IdP.
This guide walks you through the following steps:
To follow this guide, you need to satisfy the following prerequisites:
Application Developer role is required. Learn moreYou can provide fine-grained access control to your API resources with scopes. Follow the steps below to assign a scope to the resources in the API:
To enable external IdP authentication for APIs, create an API on Azure AD that represents the API on Choreo. Follow the steps below:
For more information, refer to the Azure documentation:
You can restrict users to the API as follows:
For more information, refer to the Azure documentation: Assign the app to users and groups to restrict access
"},{"location":"authentication-and-authorization/secure-api-access-with-azure-ad/#step-3-create-a-client-application-on-azure-ad-and-invoke-the-azure-web-api","title":"Step 3: Create a client application on Azure AD and invoke the Azure web API","text":"To expose the API to application developers, create an application in Azure AD. This application provides you with a client-id and client-secret that your application needs to use to invoke the API.
"},{"location":"authentication-and-authorization/secure-api-access-with-azure-ad/#step-31-create-a-client-application","title":"Step 3.1: Create a client application","text":"Follow the steps below to create the application:
Configure the platform settings. Enter your client application's redirect URI in the process.
Note
OAuth2 Authorization Grant flow applies to Web Applications.
Once you create the application, select the API and the scopes you want the application to consume. Follow the steps below:
For more information, refer to the Azure documentation: Add permissions to access your web API
"},{"location":"authentication-and-authorization/secure-api-access-with-azure-ad/#step-33-create-secrets-for-the-azure-web-application","title":"Step 3.3: Create secrets for the Azure web application","text":"To invoke the application, provide client secrets to the consuming application. Follow the steps below to generate the credentials:
Secret ID and Value for future reference. Application (client) ID and save it for future reference.For more information, refer to the Azure documentation: Add a Client Secret
"},{"location":"authentication-and-authorization/secure-api-access-with-azure-ad/#step-4-create-an-application-in-choreo-and-enable-external-idp-authentication","title":"Step 4: Create an application in Choreo and enable external IdP authentication.","text":"Follow the steps below to consume the Choreo API and use an external IdP for authentication:
Application (client) ID you copied in at Step 3.2 as the Client ID.Click +Add.
Note
In the left navigation menu, click Subscriptions.
You can now invoke the Choreo API using the authorization code grant. Choreo will authenticate the user with Azure AD and provide access to the resource.
Invoke the authorization endpoint as follows:
FormatExample{authorize_url}?client_id={client_id}&redirect_uri={redirect_url}&scope={scopes}&response_mode=query&response_type=code\n https://login.microsoftonline.com/dd912d48-b0be-401f-b18c-8ca89e9c0b6c/oauth2/authorize?client_id=5eb1de74-e449-4973-a620-52c4dc9157a9&redirect_uri=https://localhost:9000&scope=api://580b40b7-5513-4714-a4e0-8d4e784f7dc6/urn:taylordean:books:books_addt&response_mode=query&response_type=code\n curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \\\n{token_endpoint} \\\n-d 'client_id={client_id}' \\\n-d 'scope={scopes}' \\\n-d 'code={authorization_code}' \\\n-d 'redirect_uri={redirect_url}' \\\n-d 'client_secret={The client_secret value you copied from the Azure Application}'\n-d 'grant_type=authorization_code' \\ \n curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \\\nhttps://login.microsoftonline.com/dd912d48-b0be-401f-b18c-8ca89e9c0b6c/oauth2/v2.0/token \\\n-d 'client_id=5eb1de74-e449-4973-a620-52c4dc9157a9' \\\n-d 'scope=api://580b40b7-5513-4714-a4e0-8d4e784f7dc6/urn:taylordean:books:books_add' \\\n-d 'code=0.AXAASC\u2026zZUzKYm18yM_5-SXz1uvRbbGYF7F32hE9zIQFRQY35haD' \\\n-d 'redirect_uri=https://localhost:9000' \\\n-d 'grant_type=authorization_code' \\\n-d 'state=111' \\\n-d 'client_secret=l4Q8Q~4WKiRXYSQZly5E6Ess.fKf__U1yJR3IaMd'\n Once you receive the access token, you can test invoking the resource using the OpenAPI console in Choreo by specifying the scope.
To establish secure communication between the Choreo Gateway and your backend, you can configure mutual TLS.
Mutual TLS authentication involves both the client and server validating each other\u2019s certificates before establishing a connection. The following diagram depicts this scenario:
"},{"location":"authentication-and-authorization/secure-communication-between-the-choreo-gateway-and-your-backend-with-mutual-tls/#configure-mutual-tls-to-establish-secure-connectivity","title":"Configure mutual TLS to establish secure connectivity","text":"To establish secure connectivity between the Choreo Gateway and your backend using mutual TLS, you must add the certificate of the backend (server certificate) to Choreo and add the certificate of Choreo (client certificate) as a trusted certificate in the backend.
"},{"location":"authentication-and-authorization/secure-communication-between-the-choreo-gateway-and-your-backend-with-mutual-tls/#step-1-configure-the-backend-certificate","title":"Step 1: Configure the backend certificate","text":"Prerequisites.pem extension.To configure the backend certificate, follow the steps given below:
There are two approaches you can take to configure mutual TLS.
Follow the step-by-step instructions below depending on how you want to establish mutual TLS with the backend service:
Generate a key pair through ChoreoUse your own certificate pairWhen you follow these steps, Choreo generates a key pair with a self-signed certificate. You can attach this key pair to any API proxy created within the same project.
In the Add Client Certificate Pair dialog, select Generate new key pair and specify a value as the common name for the certificate pair. This value will be used to identify the certificate.
Optionally, click Show advanced options to expand the section and specify appropriate values for each of the fields.
Click the more options icon corresponding to the certificate and then click View and Download.
This opens the certificate for you to view and download.
To download the certificate in PEM format, click Download. You can add this certificate as a trusted certificate in the API backend server.
Now you can associate the certificate with the API and deploy the API.
Here, you can use your own public certificate and private certificate as client certificates.
In the Add Client Certificate Pair dialog, select Use my own key pair.
Upload the private key and public certificate in PEM format or copy and paste the content of the private key and public certificate.
Click the more options icon corresponding to the certificate and then click View and Download.
This opens the certificate for you to view and download.
To download the certificate in PEM format, click Download. You can add this certificate as a trusted certificate in the API backend server.
Now you can associate the certificate with the API and deploy the API.
"},{"location":"authentication-and-authorization/secure-communication-between-the-choreo-gateway-and-your-backend-with-mutual-tls/#step-3-associate-the-certificate-with-the-api","title":"Step 3: Associate the certificate with the API","text":"To associate a certificate with the API, follow the steps given below:
Select the certificate you want to associate with the API.
Click Save.
To deploy the API, follow the steps given below:
Once the deployment is complete, you can test the API.
"},{"location":"authentication-and-authorization/secure-communication-between-the-choreo-gateway-and-your-backend-with-mutual-tls/#change-the-certificate-for-the-production-environment","title":"Change the certificate for the production environment","text":"If the API backend changes depending on the environment, the respective certificate must be updated for each environment.
Here, let's take a look at the steps to update the certificate for the production environment:
The managed authentication capability of Choreo simplifies adding authentication and authorization to a single-page web application.
As a developer, you can easily set up Choreo's managed authentication to seamlessly integrate authentication into your web application. You just need to enable Choreo\u2019s managed authentication, configure the built-in identity provider, and connect to Choreo without having to deal with the complexities of underlying OIDC/OAuth2.0 protocols.
Choreo's managed authentication follows the backend for frontend (BFF) architecture, which is a secure pattern recommended for browser-based applications that utilize OIDC/OAuth2.0 for authentication and authorization. This architecture ensures that OAuth tokens remain secure from browser-side code, making them immune to potential attacks like cross-site scripting (XSS).
Note
Choreo's managed authentication is currently available only for web applications created with React, Angular, or Vue.js buildpacks.
Warning
Managed authentication uses the 'SAMESITE' cookie attribute to prevent CSRF attacks. Therefore, it is recommended to use managed authentication with modern browsers that support the 'SAMESITE' attribute.
"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-1-set-up-managed-authentication-for-your-web-application","title":"Step 1: Set up managed authentication for your web application","text":"To secure your web application, you must implement authentication and authorization for it.
To easily set up authentication for your web application with Choreo's managed authentication, follow the steps given below. Before you move on to the next section, see Develop Web Applications Locally with Choreo\u2019s Managed Authentication to ensure a seamless authentication experience when developing your web application on your local machine. You can also refer to the sample\u00a0React app with managed authentication.
"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-11-implement-the-sign-in-functionality","title":"Step 1.1: Implement the sign-in functionality","text":"To allow Choreo to manage the sign-in functionality for your web application, you must implement a sign-in button that redirects users to the /auth/login path on click. You can use the following code snippet or any custom button component from a preferred UI component library:
<button onClick={() => {window.location.href=\"/auth/login\"}}>Login</button>\n This code snippet works as follows:
When a user clicks sign in on your web application, Choreo will redirect the user to the configured identity provider and handle the authentication process, conforming to the OICD/OAuth2.0 protocols. On successful sign-in, Choreo will set the relevant session cookies and redirect the user to the post-sign-in path (default is /). The user can then invoke any Choreo-deployed APIs depending on the permission granted.
Note
Refer to configure the identity provider section for details on configuring an identity provider for the web application.
Optional: Pass additional query parameters to the identity providerIf you want to pass additional query parameters to the identity provider, include them in the /auth/login request. Choreo appends these parameters to the authorize request sent to the identity provider.
For example,
<button onClick={() => {window.location.href=\"/auth/login?fidp=myfederatedidp\"}}>Login</button>\n"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-12-obtain-user-information-claims","title":"Step 1.2: Obtain user information claims","text":"Choreo's managed authentication allows you to access user information claims that the identity provider returns post-sign-in, either via a cookie or by invoking a GET resource.
Obtain user information via theuserinfo cookie Upon successful sign-in, Choreo's managed authentication establishes a userinfo cookie that is accessible from the post-sign-in path you configured (by default, set to /). This userinfo cookie, provided by the identity provider, contains encoded user information claims.
Note
userinfo cookie is intentionally set to have a short lifespan of only 2 minutes.js-cookie library for cookie parsing. You can use any cookie-parsing library of your choice.\u00a0The recommended approach is to retrieve user information from the cookie and subsequently clear the cookie. The following is a sample code snippet that you can include in your post-sign-in path to retrieve user information from the cookie and subsequently clear the cookie:
import Cookies from 'js-cookie';\n// Read userinfo cookie value.\nconst encodedUserInfo = Cookies.get('userinfo')\n// Decode the value. \nconst userInfo = JSON.parse(atob(encodedUserInfo))\n// Store the value in a preferred browser-based storage if needed.\n// Clear the cookie.\nCookies.remove('userinfo', { path: <post-login-path> })\n Obtain user information via a GET endpoint Choreo's managed authentication provides the GET endpoint /auth/userinfo in addition to the userinfo cookie that it sets after successful sign-in. You can use this endpoint to query information about users who have signed in. It also serves as a mechanism to check the state of a user who has signed in.
The following is an example of a request to this endpoint:
const response = await fetch('/auth/userinfo')\n If a user has signed in, the server sends a 200 OK response with the user information in JSON format in the response body. However, if the user is not signed in, the server sends a 401 Unauthorized response.
To allow Choreo to manage the sign-out functionality of your web application, you can implement a sign-out button to redirect users to the /auth/logout path along with the session_hint cookie value on click. You can use the following code snippet or any custom button component from a preferred UI component library:
Note
js-cookie library for cookie parsing. You can use any cookie-parsing library of your choice.\u00a0 <button onClick={async () => {\nwindow.location.href = `/auth/logout?session_hint=${Cookies.get('session_hint')}`;\n}}>Logout</button>`\n When a user clicks the sign-out button, Choreo will clear the session cookies and redirect the users to the OIDC logout endpoint of the configured identity provider (if available).\u00a0\u00a0
"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-14-invoke-apis","title":"Step 1.4: Invoke APIs","text":"To invoke Choreo APIs within the same organization as your web application, you can use the relative path /choreo-apis/<api-suffix>, regardless of whether managed authentication is enabled for the web application or not.
Note
To invoke a Choreo API from a web application, you need to create a Connection from the web application to the Choreo API.
For example, if the API URL is https://2d9ec1f6-2f04-4127-974f-0a3b20e97af5-dev.e1-us-east-azure.choreoapis.dev/rbln/item-service/api-e04/1.0.0, the <api-suffix> would be /rbln/item-service/api-e04/1.0.0. You can invoke the API using the /choreo-apis/rbln/item-service/api-e04/1.0.0 relative path from your single-page application.
Info
To copy the exact service URL of a Connection, you can follow the steps given below: 1. In the Choreo Console, go to the appropriate web application component. 2. In the left navigation menu, click Connections under Dependencies. 3. Click on the required Connection and copy the service URL.
If you enable Choreo's managed authentication, you don't have to manually add any logic to attach an access token to the API call because Choreo APIs accept the cookies set by Choreo's managed authentication. You can directly invoke the API as follows:
const response = await fetch('/choreo-apis/<api-suffix>')\n If Choreo's managed authentication is disabled, you must ensure that your web application attaches a valid access token to the API call.
"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-15-handle-session-expiry","title":"Step 1.5: Handle session expiry","text":"When a user session exceeds the configured session expiry time, it automatically expires. A 401 Unauthorized response status code for a Choreo API request from a logged-in user indicates that the session may have expired, requiring the user to re-login.
To programmatically handle session expiry and automatically re-login upon receiving a 401 Unauthorized response from a Choreo API, you can encapsulate the request with re-login logic. The following sample code snippet shows how to wrap GET requests:
export const performGet = async (url) => {\ntry {\n// API call\nreturn await fetch('/choreo-apis/<api-suffix>');\n} catch (error) {\nif (error instanceof HttpError && error.status === 401) {\n// Re-login\nwindow.location.href = \"/auth/login\";\n} else {\nthrow error;\n}\n}\n};\n"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-16-set-up-a-custom-error-page","title":"Step 1.6: Set up a custom error page","text":"You can set up Choreo's managed authentication to redirect to a customized error page within your web application by defining the error path in the configuration. In the event of an error during a redirection-based process, such as sign in or sign out, Choreo will automatically redirect the user to the designated custom error page.
Note
If you have not configured an error path, Choreo's managed authentication will use its default error page whenever an error occurs.
Choreo's managed authentication will include the following query parameters in the URL when redirecting to the custom error page:
Parameter Description code A short textual error code indicating the error message The description of the errorNow have successfully implemented Choreo's managed authentication for your web application. The next step is to enable managed authentication for the component, and subsequently deploy it.
"},{"location":"authentication-and-authorization/secure-web-applications-with-managed-authentication/#step-2-enable-managed-authentication-and-configure-the-paths","title":"Step 2: Enable managed authentication and configure the paths","text":"To ensure that your web application functions seamlessly with managed authentication, it is essential to enable managed authentication for your web application component within Choreo.
You can enable managed authentication for your web application component at the time you deploy the component.
Tip
Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks.
Specify appropriate values for the following fields:
Field Description Default value Post Login Path The relative path that the application will be redirected to on successful sign-in. In your code, you must implement the necessary logic to obtain signed-in user's information from theuserinfo cookie set by managed authentication. See Obtain user information via the userinfo cookie section in Obtain user information claims. / Post Logout Path The relative path to which Choreo redirects you on successful sign-out. / Error Path The relative path to which Choreo redirects you when an error occurs during a redirection-based flow (i.e., sign in or sign out). See Set up a custom error page. Built-in error page Session Expiry Time The time in minutes after which the user session expires. For a seamless experience, the session expiry value should match the refresh token expiry time of the OIDC application in your identity provider. 10080 Minutes (7 Days) Additional Scopes All additional scopes required by the web application. The openid, profile, and email scopes are added by default together with the scopes required to invoke subscribed APIs. none Note
If you need to change these configurations after you deploy the component, you can click Authentication Settings on the Set Up card, make the necessary changes, and deploy the component once again.
You can configure your web application to work with the Choreo built-in identity provider, Asgardeo, or any external identity provider which supports OIDC/OAuth2.0 .
Note
The identity provider configured in this step should contain the users for the web application.
Click the respective tab for details depending on which identity provider you need to configure:
Configure Choreo built-in identity providerConfigure AsgardeoConfigure an external identity providerFollow the steps given below to configure the built-in identity provider by generating authentication keys:
Note
Choreo built-in identity provider is configured by default. Therefore, this step is optional.
Click Generate Secret.
Note
If the Regenerate Secret button is shown instead of the Generate Secret button, it indicates that OAuth keys are already generated for the component for the selected environment.
Tip
Refer to Configure a User Store with the Built-In Identity Provider for details on adding test users in Choreo built-in identity provider.
Tip
If you need to invoke APIs secured with role-based access control, you can test this within Choreo by creating roles for the application and mapping those roles to relevant permissions (scope) and user groups. For more information, see create roles and assign permissions and assign roles to user groups sections in Test Secure API Access with Choreo Built-In Security Token Service.
Step 3.1: Create and configure an OIDC/OAuth2.0 application in Asgardeo
Click the Protocol tab and follow these steps:
Code and Refresh Token as the Allowed grant types.JWT as the Token type.Click Update.
Tip
If you need to invoke APIs secured with role-based access control, you must create roles in the application and map those roles to relevant permissions (scope). Then those roles should be assigned to user groups. For more information, see the Asgardeo API authorization guide.
Copy the Client ID and Client Secret of the application. You will need to use these values in the next step to link the OIDC/OAuth2.0 application to your Choreo component.
Step 3.2: Link the OIDC/OAuth2.0 application to the Choreo web application component
Step 3.1: Create and configure an OIDC/OAuth2.0 application in the external identity provider
Configure the OIDC/OAuth2.0 application as follows:
Code and Refresh Token as allowed grant types.Specify the access token type as JWT.
Tip
If you want to invoke APIs secured with role-based access control, you must ensure that users are assigned a role mapping that grants the necessary permission for API invocation. The approach of mapping application roles to users can vary depending on the identity provider.
Step 3.2: Link the OIDC/OAuth2.0 application to the Choreo component
API security can protect APIs from potential threats and vulnerabilities, with authentication and authorization playing key roles. Authentication ensures that only authorized users or applications can access the API. This involves using API keys, tokens, or more advanced authentication methods like OAuth 2.0. Authorization governs the actions permitted for authenticated users or applications within the API. Authorization mechanisms restrict access to specific resources and actions based on user roles or permissions.
Choreo simplifies security testing for developers, allowing them to easily test APIs with permissions in non-critical environments. With its integrated security token service, Choreo provides authorization features that generate scopes based on the correlation between scopes, roles, and user groups. Developers can create roles, assign permissions, and set up user-group mappings using Choreo's built-in identity provider (IdP).
This guide walks you through the following steps to test the invocation of secured APIs with permissions using Choreo's built-in authorization capability:
Before you try out this guide, ensure you have set up the following:
You can provide fine-grained access control to your API resources with permissions. Follow the steps below to assign permissions to the resources in the API:
To apply the latest permissions to the deployed component, you must redeploy it. Follow the steps below to redeploy:
To publish your API to the Choreo Developer Portal, follow the steps given below:
The permissions assigned to your API need to be associated with roles. Follow the steps below to create roles and assign permissions to the roles.
Select the permissions you want to assign to the role, and then click Create.
Tip
The permissions(scopes) defined for APIs exposed via components in the project and the permissions(scopes) required by connections created for components in the project are listed here.
You must assign roles to the user groups defined in your Choreo built-in IdP to ensure that authenticated users can obtain access tokens with the required permissions.
Click the Application Security tab and then click Role Management.
Tip
The roles defined within different projects in the organization are listed here.
Click Map Groups corresponding to a role that you want to assign to a group.
To test an API invocation, you must first create a connection to your API. To do this, you must have a web application created. You can use the web application you created while setting up the prerequisites.
To create a connection to the web application, follow the steps given below:
Now you can proceed to deploy the web application.
When deploying, if your web application is a single-page application (SPA), you have the option to allow Choreo to handle authentication on behalf of the application. This approach eliminates the need to incorporate OAuth protocol-specific logic into your application.
"},{"location":"authentication-and-authorization/test-secure-api-access-with-choreo-built-in-security-token-service/#test-the-invocation-when-choreo-managed-authentication-is-enabled","title":"Test the invocation when Choreo-managed authentication is enabled","text":"If managed authentication is enabled for your web application, Choreo automatically handles obtaining the necessary permission for API invocation. This occurs during the request for access tokens, allowing you to seamlessly invoke the subscribed APIs through your web application without additional intervention.
Note
If you change the permissions of an existing connection or create a new connection with permissions, you must redeploy your web application to ensure proper API invocation with managed authentication.
"},{"location":"authentication-and-authorization/test-secure-api-access-with-choreo-built-in-security-token-service/#test-the-invocation-when-the-application-manages-the-authentication","title":"Test the invocation when the application manages the authentication","text":"If your application manages authentication independently, follow the steps below to generate the necessary OAuth credentials to obtain access tokens:
code and refresh grant types are selected. This is required to obtain access tokens with an authorization code grant.The Choreo Command Line Interface (CLI) is a command-line tool that helps you easily work with Choreo using commands. By utilizing commands, it significantly improves the development experience for Choreo users. This versatile tool simplifies different stages of the development process, making interactions more efficient and user-friendly.
Choreo serves as a comprehensive internal platform-as-a-service. The Choreo CLI serves as a pivotal tool aimed at enhancing its capabilities. With the Choreo CLI, you can leverage the following benefits:
Streamline Deployment Processes: Choreo CLI simplifies the entire process from creating a component in Choreo, building it, to deploying, testing, and monitoring independent of the language and framework used to implement the component.
Versatile workflow across frameworks: Regardless of your chosen framework, Choreo CLI offers a uniform end-to-end process. Choreo seamlessly integrates with different web application types (SPA, SSR, SSG, or simple static files), services (REST, GraphQL, gRPC), scheduled jobs, manual triggers, API proxies, and more. This versatility enables you to orchestrate a wide range of cloud-native components seamlessly.
Create and Manage Resources: Simplify project and component management. You can easily initiate and organize projects in Choreo through simple commands.
Create Builds and Deployments: Simplifies the process of creating builds and deploying components. You can build and promote components to environments easily with simple commands, ensuring a seamless transition from development to deployment.
Note
The Choreo CLI currently supports the following component types:
Monitor with Logs : The integrated log functionality in the Choreo CLI allows you to effectively monitor your components. You can access valuable insights into your components behavior and performance directly from the command line.
For troubleshooting tips and answers to frequently asked questions, see the Choreo CLI FAQ.
"},{"location":"choreo-cli/get-started-with-the-choreo-cli/","title":"Get Started with the Choreo CLI","text":"This guide walks you through the following sample use case:
This guide utilized a simple to-do app built with Next.js and two basic environments: Development and Production.
"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#prerequisites","title":"Prerequisites","text":"Follow the steps below to install the CLI:
Install the Choreo CLI by running the command specific to your operating system:
For Linux and Mac OS
curl -o- https://cli.choreo.dev/install.sh | bash\n For Windows (via PowerShell)
iwr https://cli.choreo.dev/install.ps1 -useb | iex\n Verify the installation by running the following command:
choreo --version\n Run the following command to login to Choreo:
choreo login\n Follow the instructions on the console to open the link in the browser and login to Choreo.
"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-2-create-a-project","title":"Step 2: Create a project","text":"A project in Choreo is a logical group of related components that typically represent a single cloud-native application. A project consists of one or more components.
Create a multi-repository project named \u2018web-app-project\u2019 by running the following command:
choreo create project web-app-project --type=multi-repository\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-3-create-a-web-application-component","title":"Step 3: Create a Web Application component","text":"In Choreo, a component within your project represents a singular unit of work in a cloud-native application. It can be a microservice, API, web application, or job/task. Each component is associated with a directory path in a Git repository containing the source code for the program.
Note
The Choreo CLI currently supports the following component types:
Fork the repository https://github.com/wso2/choreo-sample-todo-list-app. This contains a sample web application that you can use for this guide.
To initiate the creation of a Web Application component within your project, use the following command: This triggers a wizard prompting you to provide details for your Git repository and other configurations for your component.
choreo create component my-web-app --project=web-app-project --type=webApp\n Select the option Enter remote repository URL manually.
Enter the following values for the prompts.
Prompt value Configure source repositoryEnter remote repository URL manually Remote repository URL Your forked repository Branch main Directory . Build-pack nodejs Language Version 20.x.x Port 8080 Note
The prompts may vary based on the type of component and the chosen build pack.
To view comprehensive information about the component, including basic details and service endpoint URLs once the services are deployed, you can use the following command:
choreo describe component \"my-web-app\" --project=\"web-app-project\"\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-5-build-the-component","title":"Step 5: Build the component","text":"You must build the components before deploying them to a specific environment. Execute the following command to trigger the build:
choreo create build \"my-web-app\" --project=\"web-app-project\"\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-51-view-build-status","title":"Step 5.1: View build status","text":"To check the status of a specific build, run the following command, replacing with the actual build ID obtained from the previous command:
Note
Typically, a build takes approximately 2 to 5 minutes to complete.
choreo describe build <build-id> --project=\"web-app-project\" --component=\"my-web-app\"\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-52-view-build-logs","title":"Step 5.2: View build logs","text":"Once the build is complete, you can view the build logs for verification or debugging purposes. In the unlikely case, the build encounters any issues, the logs will help you troubleshoot.
choreo logs --type=build --project=\"web-app-project\" --component=\"my-web-app\" --deployment-track=\"main\" --build-id=<build_id>\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-6-deploy-to-the-development-environment","title":"Step 6: Deploy to the Development environment","text":"Once the build status indicates successful you can deploy the component in the Development environment by running the following command:
choreo create deployment \"my-web-app\" --env=Development --project=\"web-app-project\" --build-id=<build-id>\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-61-verify-the-deployment-in-the-development-environment","title":"Step 6.1: Verify the deployment in the Development environment","text":"After deploying the component, you can retrieve the URL of the deployed web application and open the publicly available web page to verify its behavior. Use the following command to retrieve the URL:
choreo describe component \"my-web-app\" --project=\"web-app-project\"\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-62-view-runtime-logs","title":"Step 6.2: View runtime logs","text":"To observe runtime application logs of the web application in the Development environment, execute the following command:
choreo logs --type component-application --component my-web-app --project web-app-project --env Development --follow\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-7-deploy-to-the-production-environment","title":"Step 7: Deploy to the Production environment","text":"Once you verify your application in the Development environment, you can proceed to deploy it to the Production environment with the following command:
choreo create deployment \"my-web-app\" --env=Production --project=\"web-app-project\" --build-id=<build-id>\n"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#step-71-verify-the-deployment-in-the-production-environment","title":"Step 7.1: Verify the deployment in the Production environment","text":"To ensure a successful deployment to the Production environment, retrieve the URL of the deployed web application using the following command:
choreo describe component \"my-web-app\" --project=\"web-app-project\"\n Congratulations! You successfully deployed your web application in Choreo using the Choreo CLI.
"},{"location":"choreo-cli/get-started-with-the-choreo-cli/#view-all-cli-functions","title":"View all CLI functions","text":"Discover other functionalities of Choreo by running the following command.
choreo --help\n"},{"location":"choreo-concepts/choreo-marketplace/","title":"Choreo Marketplace","text":"The Choreo Marketplace promotes and facilitates reusing and sharing services. It allows you to share all the services deployed in Choreo. You can easily browse and search available services within the Marketplace and refer to the service definitions, documentation, instructions on how you can use it, etc.
"},{"location":"choreo-concepts/choreo-marketplace/#discover-services","title":"Discover services","text":"The Marketplace includes all services deployed in your organization. This may be a large number of services. Therefore, effective discoverability is desirable.
You can use the search or apply various filter criteria to explore the services available.
"},{"location":"choreo-concepts/choreo-marketplace/#search","title":"Search","text":"The top search bar provides universal searching to find the services. It allows you to search for a text in the following search attributes:
The Choreo Marketplace provides a filtering capability through the left-hand side filter panel. It allows you to filter with the following filter attributes:
Type: This filter enables you to categorize services based on their type, with two available options: \"Internal\" and \"Third-party\". \"Internal\" refers to services deployed within Choreo, while \"Third-party\" refers to services running externally to Choreo, independently added to the Marketplace.
Network Visibility: This filter enables you to categorize services based on their network visibility level, with three choices: \"Public,\" \"Organization,\" and \"Project\". \"Public\" filters services exposed publicly, \"Organization\" represents services exposed across the entire organization, and \"Project\" represents services exposed at the project level.
You can click on the service card to open the detailed view of the service. The detailed service page features the service name, summary, version, labels, and service icon as the header.
Choreo organizes the service content into four tabs. The four tabs contain information as follows:
Overview: Choreo displays the service overview provided by the service developer. If the service developer has not provided any content at service creation, this section will be disabled. The service developer can provide the overview content via the Manage \u2192 Marketplace section of the component.
API definition: Includes the service's API definition, extracted from the user repository using the component-config file or endpoints.yaml file. If the user does not specify an API definition, this tab remains empty.
How to use: Includes instructions on how to use the selected service. This includes instructions on creating a connection.
Related documents: Includes any additional content the user has provided as documents through the Manage -> Marketplace section of the component.
You can add services to the Marketplace as Choreo services as follows:
"},{"location":"choreo-concepts/choreo-marketplace/#add-a-choreo-service","title":"Add a Choreo service","text":"In Choreo, a service exposed through the platform is termed a Choreo service, with each service being identifiable by an endpoint within a Choreo service component. The Marketplace showcases a service for each endpoint within a service component.
Upon deployment to the initial environment, services get automatically added to the Marketplace. Choreo effortlessly collects essential details such as component name, endpoint name, description, and service definitions during this deployment, utilizing them to generate the corresponding service entries in the Marketplace.
The service name follows the convention of component name - endpoint name, while all other details remain unchanged.
In the Choreo Marketplace, service versions are displayed in their major version format. Each service in the Choreo Marketplace represents the latest version of the service within its major version, following semantic versioning principles.
For example, if a Choreo service has versions v1.0, v1.1, v1.2, and v2.0, the Choreo Marketplace displays services with versions v1 and v2 representing the latest versions v1.2 and v2.0 respectively.
When you deploy a new minor version of a service already deployed in Choreo, the corresponding service in the marketplace automatically updates to reflect the latest version within the same major version.
"},{"location":"choreo-concepts/choreo-marketplace/#semantic-version-based-intelligent-routing-in-the-choreo-marketplace","title":"Semantic-version-based intelligent routing in the Choreo Marketplace","text":"When you use a service from the Choreo marketplace as a dependency, the dependent service's traffic automatically routes to the latest version of the corresponding service within the same major version. This ensures that your dependencies remain up-to-date without requiring manual updates within a major version.
For example, if you create a connection to connect your Choreo component\u00a0named Foo\u00a0to a Choreo service\u00a0named Bar, which is currently available in the Choreo Marketplace as version\u00a0v1, and if\u00a0the latest version of the service Bar within the\u00a0v1\u00a0range is\u00a0v1.2, the component Foo will automatically connect to\u00a0Bar\u00a0v1.2. Subsequently, when Bar\u00a0releases version\u00a0v1.3, traffic from\u00a0Foo\u00a0will automatically route to\u00a0Bar v1.3.
You can edit services in the Choreo Marketplace. During redeployment to any environment, Choreo automatically updates service definitions, visibility, and descriptions.
"},{"location":"choreo-concepts/ci-cd/","title":"CI/CD","text":"Choreo provides a streamlined continuous integration and continuous deployment(CI/CD) experience to deploy applications and services efficiently across multiple environments.
Choreo creates environments for each project, where all components within the project share the environments. An environment is an isolated deployment area with restricted network and resource access. Services deployed in one environment cannot communicate with services deployed in another.
The Choreo cloud data plane provides two default environments (i.e., development and production). However, if you are in a private data plane organization, you can customize and create multiple environments based on your requirements.
Choreo adopts a build once, deploy many strategy to manage components across multiple environments. An application is built only once (i.e., per commit if automatic build on commit is enabled or based on the selected commit during a manual build). Then it is promoted to subsequent environments. This allows testing changes in lower, non-production environments like development before promoting the build to production.
Choreo injects configurations and secrets that you maintain at the environment level into components at runtime. This ensures a strict separation of environment-specific configurations from source code. Although configurations can vary across environments, the code and the built container remain unchanged. Configurations and secrets include:
All configurations and secrets are encrypted at rest and in transit and stored in a secure vault. In a private data plane organization, you can store configurations and secrets in your infrastructure.
"},{"location":"choreo-concepts/ci-cd/#build","title":"Build","text":"Choreo auto-generates build pipelines that may slightly differ depending on the component type you create. Generally, all build pipelines work as follows:
Choreo can replicate builds from an identical code version (Git commit). This means that multiple builds initiated from the same Git commit will generate Docker images with the same behavior.
Note
In the event of multiple builds from the same code version, Choreo preserves only the most recent version of the Docker image created from the particular code version.
"},{"location":"choreo-concepts/ci-cd/#trigger-a-build","title":"Trigger a build","text":"On the Build page, click Build Latest. If necessary you have the option to select a particular commit and build an image.
If you want to automatically trigger a build with each commit, you can enable\u00a0Auto\u00a0Build\u00a0on Commit.
"},{"location":"choreo-concepts/ci-cd/#build-logs","title":"Build logs","text":"You can view build logs for specific builds on the Build page.
To view details of a specific build, click View Details corresponding to the build.
"},{"location":"choreo-concepts/ci-cd/#deployment","title":"Deployment","text":"Once you build an image in Choreo, you can deploy it via the Deploy page. To deploy an image, you can follow one of the approaches given below:
Manually deploy: In the Deploy page, go to the Set Up card and click Deploy.
Automatically deploy on build: In the Deploy page, go to Set Up card and enable Auto\u00a0Deploy on\u00a0Build. This automatically initiates deployment upon the completion of an automatic build.
Info
To enable Auto\u00a0Deploy on\u00a0Build, you must enable Auto\u00a0Build\u00a0on Commit. This is because automatic\u00a0deployment is not necessary or useful in scenarios where automatic build is not enabled.
Note
In the deploy phase, Choreo uses a setup area to merge the Docker image with its environment-independent configurations. Choreo then deploys this composite to the environment. This is known as the initial deployment.
"},{"location":"choreo-concepts/ci-cd/#immutable-deployments","title":"Immutable deployments","text":"Once Choreo deploys a component with configurations, the configurations become immutable. Any subsequent change results in a new deployment.
"},{"location":"choreo-concepts/ci-cd/#promote-a-component-to-a-higher-environment","title":"Promote a component to a higher environment","text":"Choreo builds a container once per GitHub commit and then promotes it to subsequent higher environments.
You can go to the Deploy page of a component and promote it manually across environments.
"},{"location":"choreo-concepts/ci-cd/#configurations","title":"Configurations","text":"Choreo allows you to define both environment-independent configurations and environment-specific configurations.
"},{"location":"choreo-concepts/ci-cd/#environment-independent-configurations","title":"Environment-independent configurations","text":"These configurations apply to all environments.
To change environment-independent configurations, go to the Deploy page of the component, make the necessary configuration changes via the Set Up card, and then trigger a new deployment to the initial environment. From there, you can proceed to promote the component to higher environments.
"},{"location":"choreo-concepts/ci-cd/#environment-specific-configurations","title":"Environment-specific configurations","text":"These configurations apply to a particular environment.
To change environment-specific configurations, go to the Deploy page of the component, make the necessary configuration changes via the specific environment card, and trigger a new deployment.
To learn more about managing these configurations, see Configuration Management.
"},{"location":"choreo-concepts/ci-cd/#task-execution","title":"Task execution","text":"The information on the Execute page is only applicable to scheduled and manual task components.
To track and monitor executions associated with a deployed scheduled task or manual task, go to the left navigation menu and click\u00a0Execute.
You can view current and historic execution details along with a quick snapshot of recent activity via the total count of executions within the last 30 days. For each execution, you can view vital details such as the unique execution ID, the time it was triggered, and relevant revision information. Furthermore, you can dive deeper into the details by clicking on a specific execution to access its associated logs. This information enhances transparency, troubleshooting capabilities, and overall execution management, allowing you to easily monitor and analyze workflows.
"},{"location":"choreo-concepts/ci-cd/#zero-downtime-deployments","title":"Zero-downtime deployments","text":"Choreo performs rolling updates to ensure zero downtime between deployments and promotions.
A new build undergoes a health check before traffic is switched to it from the current build.
If you configure the necessary health checks for a component, it can prevent deploying and promoting unhealthy versions of a component.
"},{"location":"choreo-concepts/component/","title":"Component","text":"A component within a project represents a single unit of work in a cloud native application. A component is usually a single microservice, API, or job/task. Each component in Choreo is attached to a given directory path in a Git repository which either contains program source code or a Dockerfile with build instructions. A component is Choreo\u2019s unit of deployment. Each component maps to a single pod in the Kubernetes cluster (data plane) at deployment time. Therefore, you can deploy, manage, and scale each component in Choreo independently.
Choreo supports different component types for various use cases. These include component types such as services, API proxies, integrations, web applications, and so on. Each component type hosts unique features based on its characteristics. For example, a scheduled integration component can accept a cron expression as a configuration to schedule an integration job/task.
"},{"location":"choreo-concepts/connections/","title":"Connections","text":"Services can exist in two main forms: standalone and integrated. Connecting services is an integral part in creating integrated solutions. Choreo allows you to connect services using Connections.
Using Connections, you can integrate the service you intend to deploy on Choreo with other services on Choreo or external resources. Upon creating a connection to a service on Choreo, Choreo provides you a Connection ID along with a set of connection parameters. Thereafter, you have the capability to configure your service to establish a connection using this Connection ID and map connection parameters to environment variable names in your Choreo component. You can read these environment variable names in your service implementation to retrieve the values, to create a programmatic connection to the service you want to consume.
At runtime, Choreo dynamically injects values into the environment variables based on the configured mapping. This approach ensures that the connection parameter values and the service connection creation remain loosely coupled, providing developers with flexibility and ease of maintenance.
You can add Connections in different visibility levels: Project and Component. The visibility levels are described below:
"},{"location":"choreo-concepts/connections/#project-connections","title":"Project Connections","text":"Project Connections are Connections you create to connect to services within a particular project. The Connections can be used by any component within the project.
For example, if you want to share a third-party service like Twilio across the project for all the components within that project to reuse, you can create a project connection. Components can refer to Project Connections using the connection ID. Project connections created to consume Choreo services under the OAuth security scheme will share the same OAuth application across the project. Any component reusing such a connection will use the same client ID and client secret.
"},{"location":"choreo-concepts/connections/#component-connections","title":"Component Connections","text":"Component Connections are Connections you define at the component level and used by only that component.
For example, create a component connection if you want to connect a legacy service to a given component. Components can refer to the Component Connection using the connection ID. If your component consumes more than one Choreo service, the Component connections created to consume those Choreo services under the OAuth security scheme can share the same OAuth application by sharing the same client ID and secret between all such connections.
Learn how you can share and reuse services using connections in Choreo.
"},{"location":"choreo-concepts/data-planes/","title":"Data Planes","text":"Choreo's architecture comprises two key components: the control plane and the data plane. The control plane handles essential tasks such as administering organizations, users, and projects. In addition, it also governs the entire journey of application development, from the initial stages of creation, progressing to deployment, including measures to enforce governance and the provision for observability. The Choreo control plane is a SaaS that manages all cloud data planes and private data planes. It caters to diverse user personas, including CIOs, architects, and developers, as well as DevOps, site reliability engineers, and platform engineers.
The data plane is the environment where user applications are deployed based on configurations set in the control plane. These applications can range from services and web applications to APIs, integrations, and scheduled tasks. The applications can be written in various programming languages, allowing for a polyglot approach. Importantly, all traffic related to the runtime of user applications is restricted to the Choreo data plane, ensuring strict containment of user data within its boundaries.
Choreo's architecture features two distinct data plane types: cloud data planes and private data planes. A cloud data plane utilizes a multi-tenanted infrastructure model for deploying user applications, creating a shared yet secure environment for application runtime. In contrast, a private data plane(PDP) provides dedicated infrastructure for a single organization to run its user applications. This ensures an added layer of privacy and control for organizations with specific requirements.
"},{"location":"choreo-concepts/data-planes/#private-data-planes","title":"Private data planes","text":""},{"location":"choreo-concepts/data-planes/#infrastructure","title":"Infrastructure","text":"Choreo private data planes can be deployed with almost all major cloud providers, such as Azure, AWS, and GCP, and are also compatible with on-premises infrastructure.
The essential requirements for a private data plane include upstream-compatible Kubernetes clusters, a container registry, a key vault (secret store), and a logging service or log storage.
"},{"location":"choreo-concepts/data-planes/#system-components","title":"System components","text":"Setting up the Choreo PDP system involves using a Helm installation on the Kubernetes infrastructure. The following software components are installed during the helm execution:
All of these software components receive automatic updates, including security patches and bug fixes through the flux controller connected to the Choreo Update Management System.
"},{"location":"choreo-concepts/data-planes/#connectivity-with-the-control-plane","title":"Connectivity with the control plane","text":"The private data plane requires communication with the Choreo control plane to manage various activities. All these communications are outbound from the private data plane, ensuring that there is no need to open any specific IP:Port from its perspective for these interactions. However, if an organization's network restricts all outbound traffic, it is necessary to permit outbound traffic to the public IP range of the Choreo control plane.
The following table outlines the inbound and outbound connections from a private data plane:
Data plane component Endpoint Direction Protocol Choreo PDP agent Choreo control plane (CP) (mizzen server) Outbound WSS Kubernetes API server Outbound (cluster internal) HTTPS, WS APIM/local adaptor Global adaptor Outbound HTTPS Azure Service Bus (CP) Outbound AMQP APIM/Enforcer Event hub (CP) Outbound AMQP Choreo secret resolver Cloud secret store Outbound (VPC internal) HTTPS Container registry Container registry (public) Inbound HTTPS Container registry Outbound (VPC internal) HTTPS Certificate manager Azure DNS service Outbound HTTPS LetsEncrypt Outbound HTTPS Flux source controller GitHub Outbound HTTPS Flux Helm controller Choreo container registry Outbound HTTPSAll communication between the control plane and the private data plane is secured using TLS.
"},{"location":"choreo-concepts/data-planes/#observability-architecture","title":"Observability architecture","text":"The following diagram depicts the architecture overview of Choreo's in-data-plane log and observability in Azure PDP:
The private data plane observability architecture is centered around a strong commitment to data privacy and compliance. This is achieved through a strategic decision to retain logs and observability data within the data planes itself. Key aspects of this architecture include:
The Choreo private data plane ensures extensive, production-grade security, ranging from infrastructure and architecture to zero-trust network security. All incoming traffic is protected by a firewall and must undergo authentication and authorization via the API Gateway. It also provides end-to-end network traffic encryption using Cilium transparent encryption, ensuring efficient data path encryption.
For details on the private data plane security levels supported in Choreo pricing plans, see Private Data Plane Security Levels.
"},{"location":"choreo-concepts/data-planes/#management-models","title":"Management models","text":"Choreo supports the following management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios:
To explore each management model in detail so that you can make informed decisions depending on the supported cloud-based operations and security, see Private Data Plane Management Models.
"},{"location":"choreo-concepts/deployment-tracks/","title":"Deployment Tracks","text":"Deployment Tracks in Choreo are structured pathways for simplified software component deployment. They act like advanced CI/CD pipelines, ensuring your components reach their destinations seamlessly, whether from source code or prebuilt images. They establish an organized and structured approach that minimizes the chances of errors and challenges that are typically associated with deployment workflows.
"},{"location":"choreo-concepts/deployment-tracks/#the-significance-of-deployment-tracks","title":"The significance of Deployment Tracks","text":"Deployment Tracks offer practical solutions to enhance the API consumer experience by addressing two critical challenges:
Streamlined deployment: Deployment Tracks serve as well-designed routes for your software components, enhancing the organization and reliability of the deployment process, similar to a well-structured express route.
Efficient API versioning: Especially beneficial for managed APIs, Deployment Tracks provide a straightforward method for creating API versions that seamlessly interact with previous iterations. This simplified version management benefits both API creators and consumers alike.
For streamlined deployments, Choreo dissects two integral approaches that leverage Deployment Tracks: the comprehensive CI/CD integration and the focused CD-Only strategy.
"},{"location":"choreo-concepts/deployment-tracks/#cicd-with-deployment-tracks","title":"CI/CD with Deployment Tracks","text":"A deployment track is linked to a particular branch within a GitHub repository. This connection is useful for handling deployments to various environments. On Choreo's Deploy page, you can easily visualize the deployments to specific environments associated with your selected deployment track. Moreover, the deployment track has a functionality that initiates automatic deployments for the linked branch. When activated, merging a pull request (PR) triggers a deployment to the development environment.
"},{"location":"choreo-concepts/deployment-tracks/#cd-only-strategy-with-deployment-tracks","title":"CD-Only strategy with Deployment Tracks","text":"If you're inclined to use your own Continuous Integration (CI) systems and want to harness the deployment track as a Continuous Deployment (CD) pipeline, you can seamlessly link deployment tracks to a container registry repository. This configuration empowers users to effortlessly deploy images sourced directly from the linked container registry repository.
"},{"location":"choreo-concepts/deployment-tracks/#efficient-api-versioning","title":"Efficient API versioning","text":"This section applies to only service components. When working with service components in Choreo, it is important to have an effective API versioning mechanism. Choreo follows a versioning mechanism based on Semantic Versioning (SemVer) but only includes the major version and minor version with the prefix v.
For example, v1.2.
You can follow the approach given below when you version APIs in Choreo:
What is Semantic Versioning?
Semantic Versioning (SemVer) is a specification that defines how to assign and increment version numbers for software products, including APIs. For more information, see Semantic Versioning specification.
One of the primary concerns when dealing with SaaS APIs is to minimize disruption for API consumers while continuously developing and deploying updates.
In compliance with SemVer, changes that don't introduce breaking or additive modifications to the API are categorized as patch updates. Hover, from the perspective of API consumers, these changes should ideally not disrupt their API clients. Typically, API consumers are most concerned with major API version alterations, but there might be instances where minor version changes are communicated to them.
Therefore, in the context of deployment tracks, API developers only need to specify the major and minor versions being delivered from a particular deployment track. This information is treated as the API version attribute of a deployment track. If the publisher requires versioning for internal tracking purposes, this can be accomplished in Git through the use of Git tags, on GitHub with GitHub releases, and so forth.
"},{"location":"choreo-concepts/endpoint/","title":"Endpoint","text":"An Endpoint is a network-exposed function that resides within a component. In Choreo, service and integration components expose one or more endpoints. Each endpoint in a component can have a service contract (OpenAPI, GraphQL SDL) associated with it. This contract is used to expose the endpoint to consumers. In the absence of a contract, Choreo uses /* exposed on all HTTP verbs as the default contract to expose the service or the integration.
Each endpoint exposed in a component is considered a single API. Therefore, Choreo allows you to do API management per endpoint for a given component. For example, you can perform lifecycle management and configure security settings per endpoint in a given component.
See Configure Endpoints to learn how to configure endpoints when developing components in Choreo.
"},{"location":"choreo-concepts/environments/","title":"Environments","text":"Choreo offers developers one or more environments to run their applications within a given data plane. By default, the Choreo cloud data plane provides two environments (i.e., development and production). Each project in Choreo is associated with one or more environments available in the organization. For example, project A may choose to utilize dev, staging, and production environments, while project B may only use development and production environments.
You can promote components within a project across available environments. When you promote a component, its configuration values can be overridden with environment-specific values.
The following diagram illustrates how a component is promoted across environments.
"},{"location":"choreo-concepts/organization/","title":"Organization","text":"An organization in Choreo is a logical grouping of users and user resources. A first-time user must create an organization and be a member of it when signing in to Choreo. Users and resources in an organization cannot access resources in another organization unless an admin of the other organization invites them and adds them as a member of that organization. A user cannot create more than one organization.
"},{"location":"choreo-concepts/organization/#switch-organizations","title":"Switch organizations","text":"If you are a member of more than one organization, you can switch from one organization to another when necessary. To do this, select the required organization from the Organization list in the Choreo Console header.
"},{"location":"choreo-concepts/organization/#inviting-users","title":"Inviting users","text":"An organization administrator can invite users to the organization by assigning them specific groups. Invited users receive an invitation via email. An invited user must accept the invitation to join the organization and access the resources of that organization.
"},{"location":"choreo-concepts/organization/#manage-user-permission","title":"Manage user permission","text":"Choreo manages user permissions with groups and roles.
"},{"location":"choreo-concepts/organization/#groups","title":"Groups","text":"A group in Choreo is a collection of users, each with one or more roles assigned to them. Users within a group inherit the permissions associated with the roles assigned to that group. For instance, if a user is added to the API Publisher group, they will automatically receive the API Publisher role.
Choreo comes with predefined groups already configured with specific roles, as follows:
When creating a new group to invite members, be sure to assign a role to the group to ensure users have the required permissions.
"},{"location":"choreo-concepts/organization/#roles","title":"Roles","text":"Choreo roles are defined as follows:
The Organization ID serves as a unique identifier for each organization. To get the organization ID, follow the steps below:
The organization handle is a unique string that directly corresponds to your organization's name. To get the organization handle, follow the steps below:
A project in Choreo is a logical group of related components that typically represent a single cloud native application. A project consists of one or more components. All components within a project can ideally be (but is not restricted to) in a single GitHub repository under different paths. This is also known as the monorepo architecture.
At deployment time, all components within a given project are deployed into a single namespace of the Kubernetes cluster. Components within a project can be exposed to the public internet, internally to the rest of the organization, or privately within the project only. A project in Choreo is represented as a cell with regard to the Cell-based architecture. The following diagram illustrates a project and how the components within a project are laid out at runtime:
"},{"location":"choreo-concepts/resource-hierarchy/","title":"Resource Hierarchy","text":"The following diagram depicts the high-level resources and their relationships in Choreo.
"},{"location":"choreo-concepts/resource-hierarchy/#organizations-and-data-planes","title":"Organizations and data planes","text":"Data planes are connected to the organization and are available for all the projects in the organization. When you create an environment in a project, the data plane connected to the organization is linked with an automatically generated Kubernetes namespace.
"},{"location":"choreo-concepts/resource-hierarchy/#environments-and-data-planes","title":"Environments and data planes","text":"Choreo allows multiple Kubernetes clusters to be associated with an environment.
This allows you to build highly resilient and resource-efficient solutions that utilize multiple clusters. Choreo synchronizes your applications and workloads between associated clusters in an environment. This allows you to perform multi-cluster deployment with a single click.
The following diagram depicts how multiple clusters associate with different environments:
Note
It is not necessary to use a different cluster per environment. You can create multiple environments on the same cluster. The above diagram is only an example of a specific solution. Your application architecture may require an entirely different configuration than what is depicted in the diagram.
"},{"location":"choreo-concepts/resource-hierarchy/#components-and-environments","title":"Components and environments","text":"Components belong to a project in Choreo and environments are provisioned per project as well. When a component is deployed, it is deployed as a container to the specified environment. Once deployed, you can promote the container image across the environments available in the project.
"},{"location":"consuming-services/consuming-a-sevice/","title":"Consume a Service","text":"Choreo is a platform that allows you to create, deploy, and consume services seamlessly. The Choreo Developer Portal simplifies discovering and using APIs for API consumers.
Typically, an application developer who may be internal or external to your organization would want to consume the APIs published in the Developer Portal to develop their applications. In this guide, you will learn how to discover, generate credentials, and test the consumption of a service published in the Choreo Developer Portal. You will also learn how to invoke the service via a web application.
This guide walks you through the following steps:
Before you try out this guide, if you do not have a published service that you would want to consume via the Developer Portal, follow Develop a Service documentation to publish and deploy a sample REST API.
"},{"location":"consuming-services/consuming-a-sevice/#discover-apis","title":"Discover APIs","text":"In the Choreo Developer Portal, developers can use the search option to find APIs by name. The APIs and services that are created and published through the Choreo Console become visible in the Developer Portal depending on the API's visibility as follows:
Public: The API is visible to all in the developer portal.
Private: The API is visible to the users who only sign in to the Developer Portal.
Restricted: The API is visible to only the user that has the roles that you specify. This option helps developers to enforce fine-grained access control to the API.
To learn more about API visibility, see Control API Visibility.
The Choreo Developer Portal lists APIs based on their major version.
The overview page of an API displays the subscribed versions of the API along with the respective subscription details such as the subscribed application and the application creation date.
Tip
If you want to use an API, the recommended approach is to use the latest version of it. You can copy the major version pattern provided as the value of Endpoints(s) on the API overview page and use it in your client application. This ensures that your application always invokes the latest API version.
"},{"location":"consuming-services/consuming-a-sevice/#create-an-application","title":"Create an application","text":"An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application.
This section walks you through the steps to create an application in Choreo.
Let's get started!
"},{"location":"consuming-services/consuming-a-sevice/#step-1-create-an-application","title":"Step 1: Create an application","text":"To create an application in the Choreo Developer Portal, follow the steps given below:
This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API.
"},{"location":"consuming-services/consuming-a-sevice/#step-2-generate-keys","title":"Step 2: Generate keys","text":"Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API.
Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application.
The following section walks you through the steps to generate an API access token in Choreo.
Generate environment-specific keys and tokensYou can generate keys and tokens to invoke production and non-production endpoints separately.
Note
The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints.
Click to expand Advanced Configurations and review the options.
Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials.
You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint.
To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token.
Warning
Make sure you do not use the test token in your production environment.
"},{"location":"consuming-services/consuming-a-sevice/#subscribe-to-an-api","title":"Subscribe to an API","text":"You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API\u2019s major version.
The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage.
To subscribe to an API via an application, follow the steps given below:
Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs.
Tip
When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version.
Once you subscribe to an API, you can invoke the API using the application keys.
You can invoke the API/service using the credentials you created above. Since Choreo services are secured, you need to invoke the services securely with the help of your IdP. To invoke the API/service you created securely, you need to follow the steps below:
In this guide, you will be using the following products and examples:
Info
You can use your own web application implementation in place of the sample web application. For this exercise, let's use the choreo-samples/reading-list-app/reading-list-front-end as the web application.
To host the front-end application in Choreo, you must create a web application component. To create a web application component, follow the steps given below.
Enter a unique name and a description for the web application. You can enter the name and description given below:
Field Value NameReading List Web App Description Frontend application for the reading list service Click Next.
In the Connect Repository pane, enter the following information:
Field Description GitHub Account Your account GitHub Repositorychoreo-samples Branch main Buildpack Click React since the frontend is a React application built with Vite Build Context Path reading-list-app/reading-list-front-end Build Command npm install && npm run build Build Output dist Node Version 18 Click Create. This initializes the service with the implementation from your GitHub repository and takes you to the Overview page of the component.
Let's consume the service through the web app. Choreo services are by default secured. To consume a service in Choreo you need an access token. Let's configure the web application to connect to an IdP (For this guide, let's use Asgardeo) to generate an access token for a user.
"},{"location":"consuming-services/consuming-a-sevice/#step-2-create-an-oauth-application-in-the-idp","title":"Step 2: Create an OAuth application in the IdP","text":"To invoke the service/API in Choreo you require a token. To obtain a token you need to create an OAuth application in the IdP. If you use any other IdP other than Asgardeo, create an OAuth application and set the following:
Choreo uses Asgardeo as the default identity provider for Choreo applications. When you create an application in the Choreo Developer Portal, it automatically creates a corresponding application in Asgardeo. You can go to the Asgardeo application to specify the configurations required for end users to sign in to the front-end application. Follow the steps below to configure the Asgardeo OAuth application:
Click the Protocol tab and apply the following changes:
In this step, you are adding the configurations needed for the web app to successfully invoke the Reading List Service REST API. These configurations need to be updated for each environment you deploy the web app. Here you will be updating the configurations for the development environment.
Note
The web application is reading the environment-specific configurations from the window object at runtime. This is done via the config.js file in the root of the web application. In this section, you will mount the config.js file for the development environment. You will need to do the same for other environments as well when you deploy your web application to multiple environments.
To configure the front-end application, follow the steps given below:
Select the mount configuration options as follows and click Next:
Field Description Config Type Config Map Mount Type File MountSpecify values as follows for the mount configuration:
Field Description Config Name Web App Config Mount Path /usr/share/nginx/html/config.js. Every config that needs to be exposed through the web server should be placed inside/usr/share/nginx/html/ Copy the config details as a JSON file as shown below into the text area. Fill the placeholders with the values you copied from the previous steps as mentioned in the table below:
window.config = {\nredirectUrl: \"<web-app-url>\",\nasgardeoClientId: \"<asgardeo-client-id>\",\nasgardeoBaseUrl: \"https://api.asgardeo.io/t/<your-org-name>\",\nchoreoApiUrl: \"<reading-list-service-url>\"\n};\n Field Description redirectUrl The web app URL you copied earlier. asgardeoClientId The Client ID of your OAuth application. In Asgardeo, you can find it on the Protocol tab of the readingListApp application asgardeoBaseUrl Specify the IdP API URL (For example, Asgardeo API URL) with your organization name. i.e., https://api.asgardeo.io/t/<ORG_NAME>. choreoApiUrl The reading list service URL. Copy the Public URL of the Reading List Service component from the endpoint table in the overview page for the relevant environment Click Create.
Now you can proceed to deploy the web application.
"},{"location":"consuming-services/consuming-a-sevice/#step-4-deploy-the-web-application","title":"Step 4: Deploy the web application","text":"To deploy the web application component, follow the steps below:
That's it! You can use a user created in your IdP and invoke the service through your web application.
"},{"location":"consuming-services/create-a-subscription/","title":"Create a subscription","text":"You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API\u2019s major version.
The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage.
To subscribe to an API via an application, follow the steps given below:
Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs.
Tip
When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version.
Once you subscribe to an API, you can invoke the API using the application keys.
An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application.
This section walks you through the steps to create an application in Choreo.
Let's get started!
"},{"location":"consuming-services/create-an-application/#step-1-create-an-application","title":"Step 1: Create an application","text":"To create an application in the Choreo Developer Portal, follow the steps given below:
This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API.
"},{"location":"consuming-services/create-an-application/#step-2-generate-keys","title":"Step 2: Generate keys","text":"Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API.
Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application.
The following section walks you through the steps to generate an API access token in Choreo.
Generate environment-specific keys and tokensYou can generate keys and tokens to invoke production and non-production endpoints separately.
Note
The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints.
Click to expand Advanced Configurations and review the options.
Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials.
You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint.
To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token.
Warning
Make sure you do not use the test token in your production environment.
"},{"location":"consuming-services/generate-an-access-token/","title":"Generate an Access Token","text":"Using access tokens for request authorization strengthens security measures, particularly in preventing certain types of denial-of-service (DoS) attacks aimed at published APIs. API consumers generate access tokens to access the API, incorporating them into their HTTP header requests as simple string values.
When you register an application on the Developer Portal, you can generate a consumer key and a consumer secret for it. The consumer key and the consumer secret represent the credentials of the application. Similar to a user's username, the consumer key becomes the unique identifier of the application so that you can use it to authenticate the request to the API. Choreo issues an access token for the application against the mentioned consumer key.
This section walks you through the steps to generate an access token for your application in Choreo.
Let's get started!
"},{"location":"consuming-services/generate-an-access-token/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, be sure you have the following:
You can follow the steps below to generate an access token for your application via cURL:
Use the following template and compile the cURL command with the values you copied in the above step.
Formatcurl -k -X POST <token_endpoint> -d \"grant_type=client_credentials\" -H \"Authorization: Basic <base64encode(consumer-key:consumer-secret)>\"\n 6. Execute the cURL command to generate an access token. You can follow the steps below to generate an access token for testing purposes:
An application in Choreo is a logical representation of a physical application such as a mobile app, web app, device, etc. To consume an API in Choreo, you need to create an application that maps to your physical application and then subscribes to the required API over a usage policy plan that gives you a usage quota. A single application can have multiple subscriptions to APIs. Using the consumer key and consumer secret, you can generate an access token that you can use to invoke all the APIs subscribed to the same application.
This section walks you through the steps to create an application in Choreo.
Let's get started!
"},{"location":"consuming-services/manage-application/#step-1-create-an-application","title":"Step 1: Create an application","text":"To create an application in the Choreo Developer Portal, follow the steps given below:
This creates the application and opens the application overview page. You can view details such as the token type, workflow status, and the application owner of the API.
"},{"location":"consuming-services/manage-application/#step-2-generate-keys","title":"Step 2: Generate keys","text":"Choreo provides an OAuth 2.0 bearer token-based authentication for API access. An API access token/key is a string that is passed as an HTTP header of an API request to authenticate access to the API.
Once you create an application in Choreo, you can generate credentials for it. When you generate credentials for the first time, Choreo provides a consumer key and consumer secret for the application. The consumer key becomes the unique identifier of the application and is used to authenticate the application.
The following section walks you through the steps to generate an API access token in Choreo.
Generate environment-specific keys and tokensYou can generate keys and tokens to invoke production and non-production endpoints separately.
Note
The capability to access production endpoints depends on your role. If you have permission to access production endpoints, you can generate keys and tokens to invoke production endpoints.
Click to expand Advanced Configurations and review the options.
Click Generate Credentials. This opens the Application Keys pane with values populated for the credentials.
You can use this consumer key and consumer secret values to generate an API access token by invoking the token endpoint. You can also revoke the access token by invoking the revoke endpoint.
To generate a test token for testing purposes, you can click Generate Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client and obtain a test token.
Warning
Make sure you do not use the test token in your production environment.
"},{"location":"consuming-services/manage-application/#grant-types","title":"Grant types","text":"Choreo authentication is based on OAuth 2.0. In OAuth 2.0, grant types are methods that allow client applications to obtain an access token depending on the type of the resource owner, the type of the application, and the trust relationship between the authorization server and the resource owner.
"},{"location":"consuming-services/manage-application/#authorization-code-grant","title":"Authorization code grant","text":"The Authorization code flow provides a secure way for a client application to obtain an access token without exposing the user's credentials to the client application. The user only authenticates with the authorization server, which then issues an authorization code that can be exchanged for an access token.
This helps to protect user credentials and prevents credentials from being compromised by malicious client applications.
"},{"location":"consuming-services/manage-application/#refresh-token-grant","title":"Refresh token grant","text":"A refresh token is a token that you can use to get a new access token when your current access token is expired or when you need a new access token. You can use the refresh token grant type for this purpose. Issuing a refresh token is optional for the authorization server. If the authorization server issues a refresh token, it includes it in the response with the access token. You can use this refresh token and send it to the authorization server to obtain a new access token. Choreo's default authorization server, Asgardeo, issues refresh tokens for all grant types other than the client credentials grant type, as recommended by the OAuth 2.0 specification.
Note
The client credentials flow provides a secure way for client applications to obtain an access token without user authentication. This is useful in scenarios where the client application needs to access its own resources, such as data storage or APIs, but does not require access to user data. However, it is important to ensure that the client credentials are kept secure because any party who has these credentials can obtain access tokens and access the client's resources.
"},{"location":"consuming-services/manage-application/#implicit-grant","title":"Implicit grant","text":"The implicit grant flow is an OAuth 2.0 grant type that enables a client application to obtain an access token directly from the authorization server without an intermediate authorization code exchange. This flow is commonly used in browser-based applications where the client application runs in a web browser.
However, it is important to note that the access token is exposed in the browser's URL fragment, which can make it vulnerable to certain types of attacks, such as cross-site scripting (XSS). As a result, this flow is typically not recommended for applications that require high security.
"},{"location":"consuming-services/manage-application/#password-grant","title":"Password grant","text":"The password grant flow is an OAuth 2.0 grant type that enables a client application to obtain an access token by presenting the user's username and password directly to the authorization server. This flow is generally considered less secure than other grant types, as it requires the client application to handle and transmit the user's credentials.
The password grant is primarily used in scenarios where the client application is highly trusted, and the user experience is prioritized over security concerns. It is generally not recommended for use in public-facing applications or scenarios where sensitive data is accessed.
"},{"location":"consuming-services/manage-application/#revoke-access-tokens","title":"Revoke access tokens","text":"Revoking JWT access tokens can be challenging due to their self-validating nature. Once a token is issued, it contains all the necessary information within itself to validate its authenticity, without requiring additional server-side lookups or interactions.
It is recommended to use an expiry time that is not more than 900 seconds.
In traditional session-based authentication, the server can easily revoke a session by invalidating its associated session ID. However, in the case of JWTs, there is no central authority that maintains a list of valid or invalid tokens. As a result, revoking a JWT token requires the use of denylist or allowlist techniques, which can add additional complexity to the authentication flow and may not always be foolproof.
To mitigate these challenges, it is recommended to use short-lived JWT access tokens and regularly refresh them. This reduces the risk of unauthorized access if a token is stolen or leaked, as the token will expire after a short period of time. Additionally, implementing other security measures such as strong encryption and secure token storage can further enhance the security of JWT-based authentication.
The Choreo Developer Portal keeps the lifespan of a token to 15 minutes (900 seconds) by default. Application Developers can increase the time if necessary, but as mentioned above, it is recommended to keep it to the minimal possible value.
"},{"location":"consuming-services/manage-subscription/","title":"Manage Subscriptions","text":"You must subscribe to a published API to use it in your application. New API subscriptions cover all minor versions within the subscribed API\u2019s major version.
The subscription process is designed to ensure the secure authentication of API requests via application keys. Alternatively, you can generate credentials for an API without an explicit subscription to an application. However, this approach limits the capability to control advanced configurations such as access token expiry time, revoke token expiry time, ID token expiry time, and enabling access to the API without a secret. Generating keys in the API is recommended for testing or short-term usage but not for long-term production usage.
To subscribe to an API via an application, follow the steps given below:
Click Add to subscribe to an API. Depending on your requirement, you can subscribe to one or more APIs.
Tip
When a new minor version of an API is published, the major version-based invocation URL will automatically route to the latest minor version within the subscribed API's major version. This ensures that existing client applications can continue to function without disruption while benefiting from the improvements or additions in the newer minor version.
Once you subscribe to an API, you can invoke the API using the application keys.
Choreo's application-sharing feature allows you to share your applications with members within your organization. This facilitates collaborative efforts when there is a need for multiple members to work on the same application.
Follow the steps given below to share an application with members of your organization:
In the Share Application dialog, enter one or more email addresses depending on the members with whom you want to share the applications.
Note
You must type an email address and press enter for it to get added.
Click Confirm. This will share the application in read-only mode with the specified members.
To see the members with whom the application is shared, go to the Application Overview page and take a look at the email addresses in the Shared with field.
"},{"location":"develop-components/bring-your-own-image/","title":"Bring Your Own Image (BYOI)","text":"Choreo allows you to deploy and manage prebuilt container images from external container registries as Choreo components. This enables you to deploy and effectively manage your container images within the Choreo environment.
Info
This feature is currently only available on private data planes (PDPs) for the following component types:
Before you try out this guide, ensure you have the following:
A container registry: Ensure you have a container registry containing the images you want to deploy. Choreo is compatible with various container registries, including but not limited to GCR (Google Container Registry), ACR (Azure Container Registry), GitHub Container Registry, and Docker Hub.
An image in the registry: You need an image ready for deployment.
(Optional) An external build/CI pipeline: This is to initiate automatic deployments during the build process outside of Choreo.
When using a container registry to deploy a component, Choreo cannot create an image from the source code (Git) or initiate a new deployment when a new image is ready. However, you can use your existing build process to trigger a deployment on Choreo by sending an HTTP POST request to a webhook with the new image details.
This feature is currently only available on private data planes (PDPs). You can find this option under Deploy an image from a container registry in the Select Source step during component creation for service components, web applications, scheduled tasks, and manual tasks.
"},{"location":"develop-components/bring-your-own-image/#step-1-register-a-container-registry","title":"Step 1: Register a container registry","text":"To get started, establish a connection between your container registry and Choreo.
Info
When you use your Choreo credentials, Choreo does not pull your images into its control plane. Instead, it functions as an orchestrator, facilitating your data plane's ability to retrieve images from an external container registry. Choreo passes on these credentials to the data plane for authentication and access.
To register your container registry, follow these steps:
Choreo provides the following authentication options:
Public (anonymous) accessYou can use this option to establish a connection with a container registry that permits unrestricted public or anonymous access (for example, Public Docker Hub). In this case, only the registry host information is necessary.
For example, the following are the Docker Hub registry hosts for reference:
Vendor Registry host Docker Hub (public repositories)registry.hub.docker.com Docker Hub (private repositories) registry.docker.com * If necessary, you can use other mirrors instead of the above.
Basic authenticationTo use basic authentication to authenticate to the container registry, you must provide the username and password.
Docker configYou can provide a Docker config in JSON format to authenticate to the container registry. This option only allows you to register one container registry. That is, it only allows a single registry under auths.
You must provide the credentials directly within the configuration. Choreo cannot utilize references to executable authentication plugins.
Sample Docker config format:
{\n\"auths\": {\n\"index.docker.io/v1/\": {\n\"auth\": \"c3R...zE2\"\n}\n}\n}\n Vendor-specific authentication This option is specifically for private data planes, where your cloud provider manages authentication at the Kubernetes level. Choreo requires knowledge of the registry host because the data plane already possesses implicit (preconfigured) access to the registry.
Follow the guidelines below based on your container registry:
ACRGARAWS ECRDocker Hub (Private)GHCRAzure Container Registry
Recommended authentication options:
Service principal-based basic authentication
Vendor-specific authentication on Azure private data planes
Contact Choreo support to enable infrastructure-level private access to your registry from your Azure private data plane on AKS. If you are on a self-managed PDP on Azure, follow this guide.
Google Artifact Registry
Recommended authentication options:
Service account-based basic authentication
Use the service account key in JSON format (_json_key) as the username and specify the minified JSON contents of the service account key as the password.
You can use jq as follows to minify the service account JSON key file:
jq -c . <service-account.json>
Vendor-specific authentication on GCP private data planes
Contact Choreo support to enable infrastructure-level private access to your registry from your GCP private data plane on GKE. If you are on a self-managed PDP on GCP, see https://cloud.google.com/artifact-registry/docs/access-control#grant-project.
Elastic Container Registry
ECR does not allow the creation of static access passwords for basic authentication. The passwords (that is, access tokens) provided by AWS are only valid for 10 hours and must be manually regenerated. However, when an ECR is attached to an EKS cluster at an infrastructure level, this limitation does not apply because the authentication is handled by AWS internally. For details, see https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html.
Choreo recommends using ECR when you are exclusively on an AWS private data plane using the vendor-specific authentication option. Contact Choreo support to enable a private connection between your ECR and the underlying EKS clusters on your data plane. If you are on a self-managed PDP, you can follow this guide.
Recommended authentication options:
Basic authentication
Use your Docker Hub username/password or an access token. You can generate an access token from your Docker Hub account settings and use it in place of the password. For details, see https://docs.docker.com/docker-hub/access-tokens/.
Docker config
Sign in to the Docker CLI and copy the contents of the docker config JSON. Note that external credential stores and multiple repositories within the same config object are not supported. For more information, see https://docs.docker.com/engine/reference/commandline/login/.
GitHub Container Registry
Recommended authentication option:
Basic authentication using a PAT token
Create a personal access token (PAT) and use it in place of the password. You cannot use your own GitHub password. You must provide a PAT token.
Enter a display name, a unique name, and a description for the component.
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Click either the Docker Hub tab or the Container Registry tab depending on your vendor.
Enter the full image URL. The image URL format in general is as follows: [container-registry-host]/[repository-name]/[image-name]:[tag]
Tip
When a public image from Docker Hub lacks a specified repository name, it typically defaults to /library/. For example, you can access the public Nginx image https://hub.docker.com/_/nginx as registry.hub.docker.com/library/nginx:1.25.
To deploy the component and bring your image to Choreo, follow the steps given below:
Click Update.
Info
In this example, you deploy a Ballerina service as a REST endpoint. Therefore, Choreo generated the REST endpoint automatically. If you deploy a non-Ballerina service, you must manually add the REST endpoint and set the network visibility to Public.
Select your update image option. Refer to the update options listed below.
You have the capability of updating the image when you are deploying the component in Choreo in one of the following three ways:
Option Description Update Image Tag This option allows you to update the tag of the image. Update Image URL With this option, you can change the image name, tag, and the image repository of the image URL. Previous Images This option allows you to select a previous image and redeploy the image.Click Deploy. This deploys the service to the development environment.
Info
This section only applies to service components.
After creating a service component in Choreo, you have the option to define the endpoints for your service when manually deploying a new image.
endpoints.yaml file by its file name, similar to the Git-based Choreo components. The endpoints template follows the standard definitions for defining endpoints in Choreo. For more details, see Configure Endpoints.Choreo does not have automatic detection and deployment for newly added images or tags in the linked container registry. To overcome this limitation, Choreo allows you to integrate your own CI pipelines and initiate deployments manually. This approach enables you to use your existing CI setup or build a pipeline for image creation and pushing. You can then trigger automatic deployments using a webhook.
Follow the steps below to configure your CI/build pipeline:
Generate a token for your CI pipeline from the Manage Tokens section.
Note
To trigger an automatic deployment to your development environment, you can initiate an HTTP POST request to the Choreo webhook endpoint with the updated image details. Alternatively, you can use the provided Webhook snippets. This action will seamlessly deploy the image to the development environment.
Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way.
Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint.
Field Description Name A unique identifier for the endpoint within the service component. Port The network port on which the endpoint is accessible. Type The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP. Network Visibility Determines the level of visibility of an endpoint. Possible values are:The method of defining endpoints depends on the buildpack. For buildpacks other than Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.
When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
When you create a service component with the Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.
Note
Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an endpoint.yaml file to define dynamic endpoint parameters.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
The endpoints.yaml file has a specific structure and contains the following details:
endpoints.yaml file. name Required A unique name for the endpoint, which Choreo will use to generate the managed API. port Required The numeric port value that gets exposed via this endpoint. type Required The type of traffic this endpoint is accepting, such as REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type. networkVisibility Required The network level visibility of this endpoint, which defaults to Public if not specified. Accepted values are Project, Organization, or Public. context Required The context (base path) of the API that Choreo exposes via this endpoint. schemaFilePath Required The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context. Sample endpoints.yaml File location:
<docker-build-context-path>/.choreo/endpoints.yaml\n Note
For components built with Ballerina buildpack docker-build-context-path should be replaced with component-root. For example: <component-root>/.choreo/endpoints.yaml
For components built with WSO2 MI buildpack docker-build-context-path should be replaced with <Project Path>. For example: <Project Path>/.choreo/endpoints.yaml
File content:
# +required Version of the endpoint configuration YAML\nversion: 0.1\n# +required List of endpoints to create\nendpoints:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via this endpoint\nport: 9090\n# +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, UDP, TCP\ntype: REST\n# +optional Network level visibility of this endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Project\n# +optional Context (base path) of the API that is exposed via this endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional Path to the schema definition file. Defaults to wild card route if not provided\n# This is only applicable to REST endpoint types.\n# The path should be relative to the docker context.\nschemaFilePath: greeting_openapi.yaml\n"},{"location":"develop-components/configure-endpoints-body/#apply-advanced-component-connection-configurations","title":"Apply advanced component connection configurations","text":"The component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
Beta release
component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. The component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
Inbound configurations: This configuration section is for you to define inbound connections, Similar to endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace.
Note
component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.component-config.yaml file","text":"The component-config.yaml file has a specific structure and contains the following details:
component-config.yaml file defaults to core.choreo.dev/v1beta1. kind Required The resource type of the file defaults to ComponentConfig. spec.inbound Optional The list of inbound connection configurations. spec.outbound Optional The list of outbound connection configurations. Inbound connection configurations (spec.inbound) In the spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.
spec.outbound) In the spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.
The serviceReferences schema has a specific structure and contains the following details:
Note
Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value.
Sample component-config.yamlFile location:
<docker-build-context-path>/.choreo/component-config.yaml\n Note
docker-build-context-path with the component-root. For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>. For example, <Project Path>/.choreo/component-config.yaml.File content:
apiVersion: core.choreo.dev/v1beta1\nkind: ComponentConfig\nspec:\n# +optional Incoming connection details for the component (AKA endpoints).\ninbound:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via the endpoint\nport: 9090\n# +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, TCP, UDP.\ntype: REST\n# +optional Network level visibility of the endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Public\n# +optional Context (base path) of the API that gets exposed via the endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional The path to the schema definition file. Defaults to wildcard route if not specified.\n# This is only applicable to REST endpoint types.\n# The path should be relative to the Docker context.\nschemaFilePath: greeting_openapi.yaml\n# +optional Outgoing connection details for the component.\noutbound:\n# +optional Defines the service references from the Internal Marketplace.\nserviceReferences:\n# +required Name of the service reference.\n- name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC\n# +required Name of the connection instance.\nconnectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412\n# +optional Environment variables injected to the component for connection configuration.\nenv:\n# +required Key name of the connection configuration.\n- from: ServiceURL\n# +required Environment variable injected to the container.\nto: SERVICE_URL\n"},{"location":"develop-components/configure-endpoints-body/#expose-endpoints-as-managed-apis","title":"Expose endpoints as managed APIs","text":"Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design.
Note
This feature is not available for gRPC, UDP, and TCP endpoints.
If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including:
Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features.
"},{"location":"develop-components/configure-endpoints-body/#understand-the-default-component-url","title":"Understand the default component URL","text":"The default URL of a component corresponds to the default endpoint of the component and is structured as follows:
<domain>/<project-name>/<component-name>
This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows:
<domain>/<project-name>/<component-name>/<endpoint-name>
If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint.
"},{"location":"develop-components/configure-endpoints-body/#change-the-default-endpoint-of-a-component","title":"Change the default endpoint of a component","text":"To change the default endpoint of a component, follow the steps given below:
Note
Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way.
Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint.
Field Description Name A unique identifier for the endpoint within the service component. Port The network port on which the endpoint is accessible. Type The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP. Network Visibility Determines the level of visibility of an endpoint. Possible values are:The method of defining endpoints depends on the buildpack. For buildpacks other than Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.
When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
When you create a service component with the Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.
Note
Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an endpoint.yaml file to define dynamic endpoint parameters.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
The endpoints.yaml file has a specific structure and contains the following details:
endpoints.yaml file. name Required A unique name for the endpoint, which Choreo will use to generate the managed API. port Required The numeric port value that gets exposed via this endpoint. type Required The type of traffic this endpoint is accepting, such as REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type. networkVisibility Required The network level visibility of this endpoint, which defaults to Public if not specified. Accepted values are Project, Organization, or Public. context Required The context (base path) of the API that Choreo exposes via this endpoint. schemaFilePath Required The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context. Sample endpoints.yaml File location:
<docker-build-context-path>/.choreo/endpoints.yaml\n Note
For components built with Ballerina buildpack docker-build-context-path should be replaced with component-root. For example: <component-root>/.choreo/endpoints.yaml
For components built with WSO2 MI buildpack docker-build-context-path should be replaced with <Project Path>. For example: <Project Path>/.choreo/endpoints.yaml
File content:
# +required Version of the endpoint configuration YAML\nversion: 0.1\n# +required List of endpoints to create\nendpoints:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via this endpoint\nport: 9090\n# +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, UDP, TCP\ntype: REST\n# +optional Network level visibility of this endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Project\n# +optional Context (base path) of the API that is exposed via this endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional Path to the schema definition file. Defaults to wild card route if not provided\n# This is only applicable to REST endpoint types.\n# The path should be relative to the docker context.\nschemaFilePath: greeting_openapi.yaml\n"},{"location":"develop-components/configure-endpoints/#apply-advanced-component-connection-configurations","title":"Apply advanced component connection configurations","text":"The component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
Beta release
component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. The component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
Inbound configurations: This configuration section is for you to define inbound connections, Similar to endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace.
Note
component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.component-config.yaml file","text":"The component-config.yaml file has a specific structure and contains the following details:
component-config.yaml file defaults to core.choreo.dev/v1beta1. kind Required The resource type of the file defaults to ComponentConfig. spec.inbound Optional The list of inbound connection configurations. spec.outbound Optional The list of outbound connection configurations. Inbound connection configurations (spec.inbound) In the spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.
spec.outbound) In the spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.
The serviceReferences schema has a specific structure and contains the following details:
Note
Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value.
Sample component-config.yamlFile location:
<docker-build-context-path>/.choreo/component-config.yaml\n Note
docker-build-context-path with the component-root. For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>. For example, <Project Path>/.choreo/component-config.yaml.File content:
apiVersion: core.choreo.dev/v1beta1\nkind: ComponentConfig\nspec:\n# +optional Incoming connection details for the component (AKA endpoints).\ninbound:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via the endpoint\nport: 9090\n# +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, TCP, UDP.\ntype: REST\n# +optional Network level visibility of the endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Public\n# +optional Context (base path) of the API that gets exposed via the endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional The path to the schema definition file. Defaults to wildcard route if not specified.\n# This is only applicable to REST endpoint types.\n# The path should be relative to the Docker context.\nschemaFilePath: greeting_openapi.yaml\n# +optional Outgoing connection details for the component.\noutbound:\n# +optional Defines the service references from the Internal Marketplace.\nserviceReferences:\n# +required Name of the service reference.\n- name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC\n# +required Name of the connection instance.\nconnectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412\n# +optional Environment variables injected to the component for connection configuration.\nenv:\n# +required Key name of the connection configuration.\n- from: ServiceURL\n# +required Environment variable injected to the container.\nto: SERVICE_URL\n"},{"location":"develop-components/configure-endpoints/#expose-endpoints-as-managed-apis","title":"Expose endpoints as managed APIs","text":"Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design.
Note
This feature is not available for gRPC, UDP, and TCP endpoints.
If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including:
Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features.
"},{"location":"develop-components/configure-endpoints/#understand-the-default-component-url","title":"Understand the default component URL","text":"The default URL of a component corresponds to the default endpoint of the component and is structured as follows:
<domain>/<project-name>/<component-name>
This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows:
<domain>/<project-name>/<component-name>/<endpoint-name>
If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint.
"},{"location":"develop-components/configure-endpoints/#change-the-default-endpoint-of-a-component","title":"Change the default endpoint of a component","text":"To change the default endpoint of a component, follow the steps given below:
Note
Using Choreo, you can easily deploy applications written in different language frameworks (such as Java, Go, NodeJS, Python, etc.) on shared or private data planes using containers.
Choreo supports deploying containerized applications for the following component types:
To connect your GitHub repository to Choreo, you should authorize the Choreo Apps GitHub application to access your account or organization. When you attempt to connect your GitHub repository via the Component creation page, the Choreo Apps authorization prompt will appear.
Connect GitHub Repository
Authorize GitHub Application
Grant Repository Access
The Choreo Apps requires the following permission:
Note
You can revoke access if you do not want Choreo to have access to your GitHub account. Choreo needs write access only to send pull requests to a user repository. Choreo does not directly push any changes to a repository.
Alternatively, you can connect a public repository without requiring authorization from the Choreo Apps GitHub application. You can paste a public repository URL in the Provide Repository URL field at the time of component creation.
Tip
Authorizing the repository with the Choreo Apps GitHub application becomes essential if you want to enable Auto Deploy for the component. If you own the repository, you can subsequently authorize it with the Choreo Apps GitHub application to enable Auto Deploy.
After granting access to the required repositories, you can choose a repository and an associated branch to connect to the Choreo component. For the containerized application deployments, you should select the Dockerfile as the Buildpack and provide Dockerfile Path and Docker Context Path for the Docker build.
The following table describes the individual fields in the Create Component pane.
Field Description GitHub Account Your GitHub account or organization. If you want to add another GitHub account, you can expand the list and click + Add. GitHub Repository Depending on the repository access you provided, the list will show available repositories to be connected. Branch The branch of the repository. Buildpack Determines the implementation of the component: Any language or other language as a Docker container. Dockerfile Path The path to your Dockerfile. This path is defined relative to the repository root.For example, if the Dockerfile is at the repository root, the value for this field is/Dockerfile. Docker Context Path The Docker build context path. To include the repository root, leave the default / value. Port* The port at which your service is running. OpenAPI Filepath* The path to an OpenAPI specification (in YAML/JSON) relative to the repository root. If you don't provide a path, the system automatically generates a default allow-all specification. Note
Fields marked with * are not visible for all component types.
To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. You can refer to the sample Dockerfile for guidance.
To ensure that the defined USER instruction is valid, it must conform to the following conditions:
10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.Choreo will automatically apply deployment configurations and settings based on the component type you select during creation. For example, if you select the Service component type, Choreo will deploy it as a Kubernetes deployment with appropriate scaling configurations.
You can run unit tests in the build pipeline by adding the relevant command to the Dockerfile. For example:
You must provide any required configurations for running the application in the Configs & Secrets section of the component's DevOps page. Alternatively, you can also review the configurations when you manually deploy via the Deploy page.
After clicking the Create button, you can select the confidentiality of the configuration and specify how to mount it to the container.
Configuration typesThe following image shows adding a ConfigMap with File Mount mount type to be read by the application.
Note
The JSON file includes ${DB_PASS} as an environment variable defined in a Secret. The application reads the JSON file and substitutes the placeholders with the corresponding environment variables.
"},{"location":"develop-components/deploy-a-containerized-application/#deployment-configurations","title":"Deployment configurations","text":"Choreo lets you configure deployment settings such as scaling, resource limits, and health checks based on your selected component type.
For more information about these configurations, see Choreo's DevOps capabilities.
You can configure the Endpoints to expose your service using the Service Component in Choreo. See Service Component Overview for more information.
"},{"location":"develop-components/deploy-a-containerized-application/#build-deploy-and-promote","title":"Build, deploy, and promote","text":"After adding the application configuration, you can build and deploy it by clicking the Deploy Manually button. Choreo will start the build process with the selected commit in the Build Area.
Note
The Auto Deploy on Commit feature, which automatically builds and deploys the application upon pushing a code change to the repository, is enabled by default. To turn off this feature, navigate to the Build Area of the Deploy page.
Choreo scans your Dockerfile for security vulnerabilities during the build phase, and if there are no issues found, it proceeds with the build process. After building the image, it scans it again for vulnerabilities before deployment to the environment. You can view the build logs from the right-side panel, as shown in the image below.
Once the build process is complete, Choreo will deploy the application automatically to the Development environment. To promote the build to higher environments, you can click the Promote button. The number of environment cards visible on the page may vary depending on your environment configurations.
"},{"location":"develop-components/deploy-a-containerized-application/#troubleshoot-security-vulnerability-scan-failures-trivy","title":"Troubleshoot security vulnerability scan failures (Trivy)","text":"By default, Choreo utilizes the Aqua Trivy (OSS) image vulnerability scanner to detect security vulnerabilities in all Dockerfile-based build pipelines. The scanner will fail the pipeline if any CRITICAL CVEs (Common Vulnerabilities and Exposures) are detected. CVEs of other severity levels are recorded but does not fail the pipeline.
If you cannot fix a critical CVE immediately, you can opt to ignore it. To ignore a critical CVE, add a trivyignore (<docker-build-context-path>/.trivyignore) file to your build context path. In the file, add the CVEs you need the pipeline to ignore, one entry per line as follows:
CVE-2023-xxxx\nCVE-2023-yyyy\n You can add comments in the file by using # in front of the comment as follows:
# comments can be added like this\nCVE-2023-xxxx\n"},{"location":"develop-components/deploy-an-application-with-buildpacks/","title":"Deploy an Application with Buildpacks","text":"Using Choreo, you can easily deploy applications written in different language frameworks (such as Java, Go, NodeJS, Python, Ruby, PHP, etc.) on shared or private data planes.
Choreo supports deploying applications with buildpacks for the following component types:
Buildpacks are a fundamental building block in modern application development. They convert your source code into a secure, efficient, production-ready container image without a Dockerfile. With Choreo, developers can take advantage of this powerful tool to effortlessly deploy their applications without the hassle of manual configuration.
Choreo uses Google Buildpacks as default buildpacks for Java, Go, NodeJS, Python, PHP, and Ruby. Choreo uses its own buildpacks for Ballerina and WSO2 MI.
"},{"location":"develop-components/deploy-an-application-with-buildpacks/#develop-a-component","title":"Develop a component","text":"To develop a service component that exposes a Service in Go, you can follow the Develop a Service guide.
Follow the guidelines below based on your language:
PythonBallerinaGo.NETJavaNodeJSPHPRubyWSO2 MISpring BootSupported Versions - 3.10.x, 3.11.x
Refer below examples for different component types. Follow the readme.md inside the example.
Supported Versions - 2201.3.5, 2201.4.1, 2201.5.0, 2201.5.1, 201.6.0, 2201.7.0
Refer below examples for different component types. Follow the readme.md inside the example.
For more examples, see Choreo samples.
Supported Versions - 1.x
Refer below examples for different component types. Follow the readme.md inside the example.
For more examples, see Choreo samples.
Supported Versions - 6.x, 7.x, 8.x
Refer below examples for different component types. Follow the readme.md inside the example.
For more examples, see Choreo samples.
Supported Versions - 8, 11, 17, 18 (OpenJDK Runtime Environment Temurin)
Refer below examples for different component types. Follow the readme.md inside the example.
Info
When working on Java projects:
Main class should be defined in the manifest file.mvn.cmd exist in the project without the .mvn directory, the build will fail. To ensure a successful build, you must either commit the .mvn directory along with any Maven files or not include any Maven files in the project if you choose not to commit the .mvn directory.A Procfile is a configuration file used to declare the commands that are run by your application's containers. If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory. In Java projects, it is optional to include a Procfile.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web: java -jar target/sample.jar
For more examples, see Choreo samples.
Supported Versions - 12.x.x, 14.x.x, 16.x.x, 18.x.x, 20.x.x
Refer below examples for different component types. Follow the readme.md inside the example.
A Procfile is a configuration file used to declare the commands that are run by your application's containers. If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory. In NodeJS projects, it is optional to include a Procfile.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web: node app.js
For more examples, see Choreo samples.
Supported Versions - 8.1.x, 8.2.x
Refer below examples for different component types. Follow the readme.md inside the example.
A Procfile is a configuration file used to declare the commands that are run by your application's containers. If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory. In PHP projects, it is optional to include a Procfile.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web:php -S 0.0.0.0:8000 index.php
For more examples, see Choreo samples.
Supported Versions - 3.1.x, 3.2.x
Refer below examples for different component types. Follow the readme.md inside the example.
A Procfile is a configuration file used to declare the commands that are run by your application's containers. If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory. In Ruby projects, it is optional to include a Procfile.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web: ruby app.rb web:bundle exec ruby app.rb -p 8080
For more examples, see Choreo samples.
Supported Versions - 4.1.0.x, 4.2.0.x
Refer below examples for different component types. Follow the readme.md inside the example.
For more examples, see Choreo samples.
Supported Java Versions - 8, 11, 17, 18 (OpenJDK Runtime Environment Temurin)
Info
You can use this buildpack only with web applications. For other component types, use the Java buildpack. Additionally, if the generated artifact is a WAR file, it is necessary to include a Procfile.
A Procfile is a configuration file used to declare the commands that are run by your application's containers. If you want to customize the default entry point of the container, you can include a Procfile with the web process type in the project root directory. In Java projects, it is optional to include a Procfile.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web: java -jar target/sample.war
A Procfile is a configuration file used to declare the commands that are run by your application's containers.
Info
In Python projects, it is mandatory to have a Procfile with the web process type in the project root directory.
Here's an example Procfile for an application:
web: <command to start your application>\n e.g.,
web: python main.py web: gunicorn --bind :8080 --workers 1 --threads 8 --timeout 0 main:app web: flask run --host=0.0.0.0
For more examples, see Choreo samples.
"},{"location":"develop-components/deploy-an-application-with-buildpacks/#configure-build-time-environment-variables","title":"Configure build-time environment variables","text":"You can configure the environment variables necessary to build the component using the Build Configurations Editor on the component Build page.
Info
The capability to configure build-time environment variables is not available for components created using Ballerina or WSO2 MI buildpacks.
During the build process, the build-time environment variables and their values are passed to the buildpack. Therefore, you can configure both buildpack-specific environment variables and those required for the component build.
For example, if you want to override the Maven command of the Java buildpack, you can use GOOGLE_MAVEN_BUILD_ARGS as the environment key and clean install as the value.
For more examples, see Google Cloud's buildpacks documentation.
"},{"location":"develop-components/develop-a-webhook/","title":"Develop a Webhook","text":"Choreo allows developers to design high-quality webhooks. To explore this capability, let's consider a scenario where a team of software engineers in an organization should be notified via email whenever someone creates a GitHub issue with the bug label in a specific repository.
In this tutorial, you will address the requirement by doing the following:
Before you try out the steps in this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.Fork the Choreo samples repository, which contains the sample integration for this guide.
To create a project, add a Webhook component to it, design the webhook, test it, and then commit it to make it available in the Choreo Console, follow these sub-steps:
First, let's create a Webhook component as follows:
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Select the Access Mode depending on your requirement.
Enter the following information:
Field Description GitHub Account Your account GitHub Repository choreo-samples Branchmain Buildpack Ballerina Project Path github-event-to-email-webhook Click Create.
Choreo creates the Webhook component with the sample implementation and opens the component Overview page.
"},{"location":"develop-components/develop-a-webhook/#step-2-deploy","title":"Step 2: Deploy","text":"Let's deploy the webhook to the development environment to make it invokable:
In the Configurations pane, enter the following information:
In the webhookSecret field, enter any value.
Note
You must save this value for later use.
In the toEmail field, enter the email address to send notification emails.
You can monitor the deployment progress in the Console pane that opens on the right of the page.
Once Choreo completes the deployment, the Development card indicates the Deployment Status as Active.
Notes
In the deployment card, you can click the icon corresponding to configurables to open the Configurations pane and edit configurations:
"},{"location":"develop-components/develop-a-webhook/#step-3-connect-the-webhook-to-the-github-repository","title":"Step 3: Connect the webhook to the GitHub repository","text":"To allow the webhook to read the labels of issues in a specific GitHub repository, you must connect the webhook to the GitHub repository. To do this, follow these steps:
In the Choreo Console left navigation menu, click Overview.
On the Overview page, copy the invoke URL. You can click the copy icon within the URL field.
Go to your GitHub account and open the repository for which you want to generate notification emails.
In the top menu, click the Settings tab.
In the left navigation menu, click Webhooks.
Click Add webhook and enter the following information:
Field Value Payload URL The invoke URL you copied in Step 3, sub-step 1. Content Type Selectapplication/json Secret The last webhook secret you configured in Step 2. Tip
Buildpack specifies the type of build to run depending on the implementation of the component. It converts the integration code into a Docker image that can run on Choreo cloud. If an integration is developed using WSO2 Integration Studio, select Micro Integrator as the buildpack. If an integration is developed using the Ballerina language, select Ballerina as the buildpack.
Project Path specifies the location of the project to build the component.
Under Which events would you like to trigger this webhook?, select Let me select individual events.
Select the Issues checkbox in the list of events displayed.
By doing so, you select GitHub issues as events that need to trigger this webhook.
In the same list of events, clear the Pushes checkbox to ensure that GitHub does not trigger your webhook when the team pushes changes to the selected GitHub repository.
Click Add webhook to save the configuration.
Now you have integrated Choreo with GitHub via the webhook you created and deployed. You can proceed to test the webhook.
"},{"location":"develop-components/develop-a-webhook/#step-4-test","title":"Step 4: Test","text":"To test your webhook, create a GitHub issue with the Bug label in the repository that you connected to the webhook.
You will receive a mail similar to the following to the email address you provided in Step 2.
"},{"location":"develop-components/develop-a-webhook/#step-5-promote","title":"Step 5: Promote","text":"To promote the webhook to the Production environment, follow these steps:
On the Deploy page, go to the Development card and click Promote.
In the Configuration Types pane, leave the default selection (i.e., Use default configuration values) unchanged.
If you have configured any default values for the configurable variables, selecting Use default configuration values allows you to proceed with those values.
If you have not configured any default values for configurable variables, follow the steps given below to specify values.
Click Next.
In the webhookSecret field, enter any value.
Note
You must save this value for later use.
In the toEmail field, enter the email address to send notification emails.
Once the component is promoted to production, the Production card displays the deployment status as Active.
Now you have successfully created, deployed, and tested a Webhook component and promoted it to production.
"},{"location":"develop-components/develop-an-api-proxy/","title":"Develop an API Proxy","text":"An API proxy acts as an intermediary between an existing API and Choreo, intercepting all requests made to the API. It also functions as a managed API, which allows you to apply essential API management features such as security policies and rate limiting.
In this guide, you will:
Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this guide, you will specify a URL to an OpenAPI definition of a sample API.
Follow the steps given below:
Specify the values given in the following table as API proxy details:
Info
In the Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Display NameHR API Name hr-api Context abc-hr Version 1.0 Target https://samples.choreoapps.dev/company/hr Access Mode External Click Create.
This creates the API proxy component and takes you to the Overview page. Now you can proceed to define resources for the API proxy.
"},{"location":"develop-components/develop-an-api-proxy/#step-2-define-resources-for-the-api-proxy","title":"Step 2: Define resources for the API proxy","text":"To add a new resource that can retrieve a department by the department ID, follow the steps given below:
/department/{departmentId} as the URI Pattern.Click to expand the added resource and specify appropriate values for the Operation ID and Description fields. You can specify the values given in the following table:
Field Value Operation IDfindDepartment Description Find a department by department ID To remove the five default resources that start with /*, click the delete icon corresponding to each resource. This marks the resources for deletion.
To deploy the API proxy to the development environment, follow the steps given below:
In the left navigation menu, click Deploy.
In the Build Area card, click Configure & Deploy. This opens the Configure & Deploy pane, where you can select the API access mode depending on how you want the API to be accessible. Here, you can select External.
Click Deploy. The Development card indicates the Deployment Status as Active when the API proxy is successfully deployed.
Now you are ready to test the API proxy.
"},{"location":"develop-components/develop-an-api-proxy/#step-3-test-the-api-proxy","title":"Step 3: Test the API proxy","text":"Choreo allows you to test your API proxy using either the integrated OpenAPI Console or cURL.
In this guide, you will use the OpenAPI Console to test the API proxy.
Follow the steps given below:
Tip
Choreo enables OAuth 2.0 to secure APIs by default. Therefore, you need an access token to invoke an API.
In the left navigation menu, click Test and then click OpenAPI Console.
Select Development from the environment drop-down list.
Expand the GET /department/{departmentId} resource and click Try it Out to test it.
Enter 1 as the departmentId and click Execute. You will see a response similar to the following:
This indicates that your API proxy is working as expected.
"},{"location":"develop-components/develop-an-api-proxy/#step-4-manage-the-api-proxy","title":"Step 4: Manage the API proxy","text":"Now that you have a tested API proxy, you can publish it and make it available for application developers to consume. Depending on your requirement, you can apply security, throttling, and other settings to the API before you publish it.
In this guide, you will apply rate limiting to the API and publish it.
"},{"location":"develop-components/develop-an-api-proxy/#step-41-apply-a-rate-limiting-level-to-the-api-proxy","title":"Step 4.1: Apply a rate limiting level to the API proxy","text":"To apply a rate limiting level to the API, follow the steps given below:
To publish the API proxy to the Choreo Developer Portal, follow the steps given below:
To generate credentials for the published API and to invoke it via the Choreo Developer Portal, follow the steps below:
To open the published API in the Choreo Developer Portal via the Lifecycle page, click Go to Devportal. This takes you to the HR API in the Choreo Developer Portal.
To generate credentials to test the API, follow the steps given below:
Click Generate Credentials. Choreo generates new tokens and populates the Consumer Key and Consumer Secret fields.
Tip
If you want to test the API via an API test tool or through code, click Generate Access Token and copy the test token that is displayed. Alternatively, click cURL and copy the generated cURL command to use via a cURL client. You do not need to generate an access token if you are testing the API via the Try Out capability in the Choreo Developer Portal.
To invoke a resource via the Try Out capability in the Choreo Developer Portal, follow the steps given below:
GET /department/{departmentId} resource and click Try it out.Enter 1 as the departmentId and click Execute. You will see a response similar to the following:
Now, you have gained hands-on experience creating, deploying, testing, and publishing an API proxy using Choreo API Manager.
To learn more about the API management capabilities supported by Choreo API Manager, see API Management.
"},{"location":"develop-components/develop-components-using-vs-code/","title":"Develop Components Using VS Code","text":"The Choreo VS Code extension provides comprehensive component management capabilities to streamline local development within Choreo.
"},{"location":"develop-components/develop-components-using-vs-code/#prerequisites","title":"Prerequisites","text":"To ensure a smooth development experience with the Choreo extension, make sure you have the following:
Visual Studio Code installed with the Choreo extension version 2.0.0 or later.
A locally cloned GitHub repository to create new components or link to existing Choreo components.
Git version 2.0.0 or later.
To use the capabilities of the Choreo extension in the VS Code editor, you need an active Choreo account. If you already have an account, follow these steps to set up the extension:
Sign in to Choreo using one of the following methods:
Sign In command provided by the Choreo extension.This redirects you to an external URI to complete the authentication process. On successful sign-in, the Choreo activity pane displays your account details along with any components detected within the VS Code workspace.
Create a new component using one of the following methods:
Create New Component command provided by the Choreo extension.If the Choreo extension cannot determine the project context of the opened workspace, it prompts you to select the organization and the project to which the new component belongs.
Specify component details such as the name, type, buildpack, etc.
On successful creation, the component details view opens, and the Choreo activity pane displays the new component.
Tip
Once the component is created, a .choreo/context.yaml file is generated in the root of the Git repository. For more details, see Understand the project context.
The component details view allows you to manage your component by performing various actions such as the following:
Context files contain metadata related to the project, allowing the extension to establish an association between local directories and Choreo projects. These files, such as the context.yamlfile, resides in the /.choreo directory within the root of the Git repository.
The Choreo extension scans the root of the opened Git repository to find the context.yaml file and lists the components of the associated project. This allows you to easily open and manage the components they are developing within the VS Code workspace.
A context.yaml file can contain multiple projects, whereas, a workspace opened via VS Code can have multiple context.yaml files with different project associations. In such cases, VS Code allows you to switch between these projects, add new project associations, or remove existing ones, allowing you as a developer to focus on components of a particular project at a time.
You can decide whether to commit the context.yaml file to the Git repository. Committing this file enables other team members working on the same repository to have a seamless developer experience with Choreo.
If the context.yaml file for a particular project is not committed to the Git repository or is unavailable for other reasons, you can easily regenerate it using one of the following methods:
Link Directory command provided by the Choreo extension.To access a range of functionalities provided by the Choreo extension, open the VS Code command palette and type Choreo.
To troubleshoot Choreo extension issues, follow these steps:
To open the OUTPUT pane, go to the VS Code editor main menu, click View, and then click Output.
Select Choreo from the drop-down menu on the right-hand side to view the Choreo output for troubleshooting.
For assistance with the Choreo VS Code extension, create GitHub issues.
"},{"location":"develop-components/develop-components-with-git/","title":"Develop Components With Git","text":"Choreo enables you to develop components by connecting your GitHub, Bitbucket, or GitLab repository. You have the flexibility to either connect an existing repository or start with an empty repository and commit the source code later. By integrating your repositories with Choreo, you can automate tasks and optimize workflows across multiple systems, all within the Choreo platform. Choreo currently supports GitHub, Bitbucket, and GitLab as Git providers.
Tip
Choreo supports both Bitbucket Server and Bitbucket Cloud. The currently supported Bitbucket Server version is 8.9.2.
In Choreo, you can connect a Git repository that contains Ballerina source code or a Docker project. To connect a Git repository to Choreo as a Docker project, your Git repository must include the following:
Once you connect your Git repository to Choreo, you can build, deploy, and manage your application easily.
"},{"location":"develop-components/develop-components-with-git/#connect-a-git-repository-to-choreo","title":"Connect a Git repository to Choreo","text":"Authorizing Choreo as a GitHub application grants Choreo the following permissions to perform the respective actions on your behalf within the repository:
Permission Read Write Description Issues Y N Read component ID label to filter the pull requests Metadata Y N List repositories Contents Y Y List branches and create a branch to commit sample code Pull Request Y Y Create a pull request if you start with a Choreo sample Webhooks Y Y Trigger automatic deployment and configuration generation"},{"location":"develop-components/develop-components-with-git/#add-git-submodules-to-a-project","title":"Add Git submodules to a project","text":"Choreo provides Git submodule support when you connect your GitHub repository to Choreo. This allows you to manage and include external repositories effectively within Choreo build pipelines. Key benefits of this capability include:
For example, when you work with the Micro Integrator (MI) runtime in Choreo, you can use Git submodules to reuse MI templates and sequences across components without duplication.
Tip
If you encounter an error stating that you cannot clone a submodule due to insufficient permissions, follow the instructions below to grant the necessary permissions:
For a personal account:
For an organization account:
Under Repository Access, grant access to the necessary repositories.
Note
Choreo currently does not support accessing private repositories in other organizations.
Authorizing using a personal access token (PAT) from Bitbucket grants Choreo the following permissions to perform the respective actions on your behalf within the repository.
Permission Read Write Description Account Y N Get user information and workspace details Repositories Y Y List branches and create a branch to commit sample code Pull Requests Y Y Create a pull request if you start with a Choreo sample Webhooks Y Y Trigger automatic deployment and configuration generation"},{"location":"develop-components/develop-components-with-git/#authorize-self-managed-gitlab-with-choreo","title":"Authorize self-managed GitLab with Choreo","text":"Authorizing using a personal access token (PAT) obtained from your GitLab self-managed server grants Choreo the following permissions to perform the respective actions on your behalf within the repository.
Permission Description API Grants full read/write access to the API, covering all groups and projects, as well as read/write access to the repository."},{"location":"develop-components/manage-deployment-tracks-for-choreo-components/","title":"Manage Deployment Tracks for Choreo Components","text":"Choreo allows you to create and manage dedicated deployment tracks for components, facilitating independent version control and deployment. This capability also allows you to unlink deployment tracks from associated branches or relink them to different branches so that you can align with your preferred Git workflows, such as the feature branch workflow or GitFlow workflow.
Info
Deployment track creation and management does not apply to API Proxy and BYOI components.
"},{"location":"develop-components/manage-deployment-tracks-for-choreo-components/#create-a-deployment-track","title":"Create a deployment track","text":"Prerequisites:
Follow the steps below to create a deployment track for a component:
If you want to detach a branch reference from a deployment track, you must unlink the branch.
Info
When you unlink the branch of a deployment track, the active deployments are unaffected. However, while you can redeploy the existing deployment, you cannot perform a new deployment.
Follow the steps below to unlink a deployment track of a component:
To associate a branch reference to an unlinked deployment track, you must link a branch.
Info
To build and deploy the contents of the linked branch, you must perform a manual build and deploy.
Prerequisites:
Follow the steps below to link a branch to an unlinked deployment track:
To switch the branch reference of a linked deployment track, you must relink to an appropriate branch.
Info
If you unlink the existing branch of a deployment track and link a different branch, you must perform a manual build and deploy to build and deploy the contents of the recently linked branch.
Prerequisites:
Follow the steps below to switch the branch reference of a linked deployment track:
Now that you understand how to create and manage deployment tracks for components, let\u2019s explore a sample scenario to see how a developer can use deployment tracks to manage version releases in Choreo.
"},{"location":"develop-components/manage-deployment-tracks-for-choreo-components/#sample-scenario-manage-version-releases-with-deployment-tracks","title":"Sample Scenario: Manage version releases with deployment tracks","text":"Let\u2019s consider the following version release scenario:
feature-x from either the main or dev branch.feature-x branch into the dev branch for testing.dev branch, the developer proceeds to merge all the changes into the main branch for production deployment.Following are the actions you need to take from a deployment track perspective to manage the version release:
main branch from the associated deployment track (let\u2019s consider this as the deployment track 1).dev branch containing the tested changes into the main branch.dev branch from the associated deployment track (let\u2019s consider this as deployment track 2).main branch for deployment.dev branch.Tip
dev to ensure a continuous development and release cycle.If you no longer need a deployment track, you can delete it.
Note
If the component exposes an endpoint or proxy and you want to delete the last version in the major version range, the recommended approach is to retire that version first. This allows consumers to transition to the next major version and prevents a sudden break in their experience. For example, if you have deployment tracks for v1.0 and v2.0, notify consumers to switch to v2.0 before deleting v1.0. Then, retire the APIs in v1.0 and proceed to delete the associated deployment track.
Prerequisites:
Follow the steps below to delete a deployment track:
Choreo allows you to use a preferred WSO2 Micro Integrator (MI) runtime version in your integration project. Currently, Choreo supports MI product versions 4.1.0 and 4.2.0. You have the flexibility to deploy WSO2 updates within these specified versions.
When you create an integration project, you can specify a required runtime version to gain control over the environment in which your integration runs. This version management capability empowers you to tailor your projects depending on your runtime requirements, enhancing the customization and adaptability of your integration workflows.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#understand-the-version-string","title":"Understand the version string","text":"WSO2 Micro Integrator (MI) utilizes a versioning system consisting of three-digit numbers, such as 4.1.0 and 4.2.0, following semantic versioning principles. The product remains committed to receiving updates from WSO2, including security fixes, bug resolutions, and enhancements. Within the Choreo platform, the MI runtime version is constructed by combining the product release version with its corresponding update level.
In Choreo, the MI runtime version is structured as a four-digit number, for example, 4.1.0.14 or 4.2.0.17. The first three digits represent the product release version, while the last digit signifies the update level of the product. The fourth digit is optional and can be omitted.
If you are using WSO2 Integration Studio to build and deploy integration artifacts in WSO2 Micro Integrator, you can create multiple runtime environments and execute projects on any selected environment. WSO2 Integration Studio also allows you to configure multiple Micro Integrator runtime environments, offering flexibility and customization in the execution of integration processes.
You can specify the Runtime version when you create an integration project in WSO2 Integration Studio. In the project creation wizard, specify the runtime version in the Runtime version field, as shown below.
An integration project is structured as a Maven project with multiple sub-modules. The root pom.xml file holds crucial information about the target runtime. The runtime version you configure when you create a new project is saved within the root pom.xml file. The version information is stored in the element under the in the pom.xml file. If there is a need to update the runtime version, you have the flexibility to modify the value to a valid runtime version and ensure that the project runs in the required runtime environment.
You can establish multiple runtime environments by utilizing updated MI instances. With a valid WSO2 subscription, you can also access and download updates to set up an updated MI server locally. This update process allows you to select a preferred update level as the runtime version. Consequently, you can run your integration on a runtime with the latest updates, ensuring optimal performance and access to new features.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#configure-a-micro-integrator-runtime-environment-in-integration-studio","title":"Configure a Micro Integrator runtime environment in Integration Studio","text":"If you are using WSO2 Integration Studio, follow these steps to set up a remote server instance with a Micro Integrator runtime environment to execute your integration project:
Note
If you have not downloaded and installed WSO2 Integration Studio, you can follow the installation instructions in the WSO2 API Manager documentation.
WSO2 directory and select WSO2 Remote Server. Enter the WSO2 Micro Integrator Management API URL in the Server URL field and click Test Connection.
Note
The Management API of WSO2 Micro Integrator is an internal REST API introduced to substitute MI\u00a0admin services. The default HTTPS port of the Management API of WSO2 Micro Integrator is 9164. If you have not manually changed the default port, you must set the Management API URL as https://localhost:9164/management. If you have changed the default HTTPS port, you must set the port number appropriately when specifying the Server URL. For more information on the default ports of WSO2 Micro Integrator, see WSO2 Micro Integrator default ports in the WSO2 API Manager documentation.
Click Finish.
Your integration project is now running in a remote server instance with the Micro Integrator runtime environment you require. If you need to make changes to the integration project, expand the remote server instance, right-click on the deployed exporter project, and select Redeploy to apply the changes.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#convention-for-version-interpretation-in-choreo-deployments","title":"Convention for version interpretation in Choreo deployments","text":"You can use the following convention to indicate the required MI runtime version in your integration project:
Version format Example Description Product version4.1.0, 4.2.0 Deploy on the latest update level of the mentioned product version. Product version with update level 4.1.0.15, 4.2.0.17 Deploy on the exact update level of the mentioned product version. GA version 4.1.0.0, 4.2.0.0 Deploy on the exact GA version without any update. Default version Empty value Deploy on the latest update level of the default product version. Choreo utilizes Alpine images for configuring and deploying the Micro Integrator runtime. This includes automated configuration of the JRE/JDK, customized to the compatibility of the chosen runtime version, simplifying the setup procedure.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#migrate-between-runtime-versions","title":"Migrate between runtime versions","text":"Changing the runtime version in an integration project may become necessary during product version upgrades or when you want to apply updates.
To change the runtime version of a MI Integration, follow the below steps.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#update-the-runtime-version-in-the-integration-project","title":"Update the runtime version in the integration project","text":"To change the runtime version in the integration project, follow the steps below: 1. Open the project in Integration Studio. 2. Right-click on the project and select Change Runtime MI Version. 3. Specify the new runtime version as shown below: 4. Alternatively, you can manually update the version by opening the root pom.xml file. Open pom.xml and change the required runtime version in <project.runtime.version> element under <properties> section.
To test the changes locally, you must download and set up the runtime environment locally. Then, you must configure the Integration Studio runtime environment by directing it to the locally installed MI runtime. Once the setup is complete, you can deploy your integrations on the MI runtime environment and proceed to the testing phase.
After completing the tests to ensure everything works as expected, you can follow below steps to deploy the project in Choreo:
You will see the runtime version in the logs as shown below:
Next, you must conduct additional testing in the development environment on Choreo before you promote the integration to production environments.
"},{"location":"develop-components/manage-the-micro-integrator-runtime-version-in-your-integration-project/#troubleshoot-errors","title":"Troubleshoot errors","text":"The following error codes can help you troubleshoot errors that occur during the integration component build:
Error code Description 110 - 119 Internal server error. 121 Malformed runtime version. 122 The specified runtime version is not available. Either the product or update level is not available. 123 Trivy security vulnerabilities found in thelibs directory. 124 Trivy security vulnerabilities found in the dropins directory. 125 Trivy security vulnerabilities found in the libs or dropins directory. 126 Error building integration project."},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/","title":"Work with the Micro Integrator Runtime in Choreo","text":"WSO2 Micro Integrator (WSO2 MI) is a lightweight, high-performance integration runtime. It allows you to run integrations developed using WSO2 Integration Studio within Choreo.
The topics on this page walk you through the key aspects you need to understand to use the WSO2 MI runtime effectively in Choreo.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#integration-types","title":"Integration types","text":"Choreo supports the following WSO2 MI integrations that cater to different use cases and requirements. Each integration type serves a specific purpose. Therefore, it is essential to understand their differences to easily choose the most appropriate integration for your use case.
WSO2 Integration Studio is a powerful, Eclipse-based graphical development environment that enables you to build and deploy integration artifacts in WSO2 Micro Integrator. This comprehensive IDE offers a robust set of tools for designing and testing integration flows and crafting integration artifacts. By utilizing the visual, drag-and-drop capabilities of WSO2 Integration Studio, developers can significantly reduce the time and effort needed to construct and deploy integration flows.
In addition to streamlining the development process, Integration Studio offers features such as debugging, testing, and version control to ensure the quality and reliability of integration flows. By creating an Integration project and Composite Exporter project in WSO2 Integration Studio, developers can export their integration projects as a single deployment artifact, known as a composite application. This composite application encompasses all the components and configurations necessary for deploying the integration project to WSO2 Micro Integrator.
The Composite Exporter project simplifies the deployment process by allowing developers to package their integration projects as a single, self-contained artifact that can be easily deployed and managed. This approach enhances the consistency and reliability of integration projects while streamlining the overall deployment process.
To start developing integrations with WSO2 Integration Studio, see WSO2 API Manager Documentation - Developing Integration Solutions.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#integration-project-directory-structure","title":"Integration project directory structure","text":"An Integration Project in WSO2 Integration Studio is a multi-module Maven project that can contain multiple modules with WSO2 Synapse configurations and a composite application module to export all the configurations as a single deployable artifact.
An integration project directory structure includes the following key components:
Optionally, you can include the following components in your integration project:
Understanding the Integration Project directory structure is crucial for organizing your project and ensuring that all necessary components are included in the final deployable artifact.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#openapi-support","title":"OpenAPI support","text":"OpenAPI Support plays a crucial role in enhancing the functionality of integrations exposed as APIs. By providing an OpenAPI definition for your exposed integration, you can streamline testing and management processes, ensuring a more efficient and user-friendly experience. Choreo will automatically generate an OpenAPI definition for you based on your integration project, if you don't provide one, saving you time and effort.
To incorporate OpenAPI support, store the OpenAPI definition file within the repository hosting your Integration Studio project. When creating the project, simply point to the file's location in the repository. If needed, you can change the location of the OpenAPI definition file later via the deploy page.
By leveraging OpenAPI Support, you can optimize the way you test and manage your integrations, resulting in a more efficient development process and a smoother user experience.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#work-with-third-party-libraries","title":"Work with third-party libraries","text":"The use of third-party libraries in your Micro Integrator project can offer several advantages, such as enhanced functionality, improved integration capabilities, optimized performance, and reduced development time.
Here are some of the benefits of adding third-party JARs to the Micro Integrator:
To incorporate third-party libraries into your Micro Integrator project, create a new directory called libs at the root of your project. If your project root and GitHub repository root are not the same, place the libs directory in the project root. After adding the required JAR files to the libs directory, the Micro Integrator runtime will automatically include them when deploying the component. This process ensures that any dependencies needed by your integration flow are available at runtime.
In addition to jar libraries, you may also need to incorporate OSGi bundle JARs into your project. To do this, create another directory called dropins at the root of your project. Similarly, if the project root and GitHub repository root differ, place the dropins directory in the project root. Within the dropins directory, add the OSGi bundle JAR files. The OSGI runtime will pick up these bundles during deployment, enabling you to utilize their functionality within your Micro Integrator project.
The feature enables Choreo MI users to import certificates into the MI client-truststore.jks file. This functionality proves valuable when users need to establish connections with servers or services utilizing SSL/TLS encryption and possessing self-signed certificates or certificates issued by private certificate authorities (CAs) that are not automatically trusted. Importing the certificate to the MI client-truststore.jks file enables MI clients to establish secure connections with the server or service seamlessly, eliminating SSL/TLS errors or warnings.
Before importing the certificate, it is necessary to obtain the certificate file, which can be in PEM or DER format. You can get the certificate from the server or service provider or export it from a web browser. Certificates should be added to the /wso2mi/certs/ folder. Users need to verify that the mount path for the certificate file aligns with this specific path.
Specify the following values as mount configurations:
Field Value Config Name An appropriate name for the certificate. Mount path/wso2mi/certs/<filename>. For example, /wso2mi/certs/certificate.crt Click Upload File and attach the certificate.
MI Secure Vault is a feature that allows users to securely store sensitive data, such as passwords and tokens, and provide access to that data to MI Integrations. This feature provides an added layer of security to your integrations by reducing the risk of accidental exposure of sensitive data.
To use MI Secure Vault to work with sensitive data, follow these steps:
Specify the following values as configurations:
Field Value Name An appropriate name for the secret/alias. Value Value for the secretSelect Mark as a Secret.
<property name=\"secret_value_1\" expression=\"wso2:vault-lookup('user_pass')\" scope=\"default\" type=\"STRING\"/>\n This code retrieves the secret named \"user_pass\" from the MI Secure Vault and stores it in the property named \" secret_value_1\". You can then use this property in your integration code to access the secret value. You can refer to the Accessing secrets section of MI Secure Vault documentation for more information on these features. By using MI Secure Vault to store and access sensitive data in your integrations, you can ensure that your integrations remain secure and protect sensitive data from unauthorized access.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#scan-third-party-libraries-to-identify-security-vulnerabilities","title":"Scan third-party libraries to identify security vulnerabilities","text":"Scanning third-party libraries for security vulnerabilities is essential for identifying potential weaknesses in an application that could be exploited by attackers. Taking a proactive approach to security helps organizations detect and mitigate risks before they can be exploited, preventing data breaches, system compromises, and other security incidents.
Choreo incorporates a security vulnerability scanning process during deployment. It uses Trivy to scan and detect critical vulnerabilities in third-party libraries added to the integration component. If the scan uncovers any critical vulnerabilities, the deployment process is halted. The deployment pane displays the Trivy scan status and any security failures in the Library (Trivy) vulnerable scan step, which can be accessed by clicking on it. Once the vulnerability has been addressed, you can redeploy the component.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#customize-wso2-micro-integrator-preconfigured-settings","title":"Customize WSO2 Micro Integrator preconfigured settings","text":"Customizing WSO2 Micro Integrator Preconfigured Settings is essential for ensuring that the integration solution works optimally within the specific context of your organization. While WSO2 MI comes with preconfigured settings designed for general use, these settings may not be suitable for every organization's unique requirements. Customizing these settings can help optimize performance and ensure compatibility with your organization's systems and applications.
To customize the preconfigured settings of WSO2 MI instances running on Choreo, define a deployment.toml file in the GitHub repository subpath of your Micro Integrator project:
Note
If you change critical configuration parameters such as port offset and hostname, it can break internal communication. Therefore, the recommended approach is to update only the necessary configuration parameters.
Given below is a sample deployment.toml file that can be used to configure the JMS transport. For more information on WSO2 MI configuration parameters, see the MI Config Catalog.
[[transport.jms.sender]]\nname = \"myQueueSender\"\nparameter.initial_naming_factory = \"org.apache.activemq.jndi.ActiveMQInitialContextFactory\"\nparameter.provider_url = \"$env{JMS_PROVIDER_URL}\"\nparameter.connection_factory_name = \"QueueConnectionFactory\"\nparameter.connection_factory_type = \"queue\"\nparameter.cache_level = \"producer\"\n\n[[transport.jms.listener]]\nname = \"myQueueListener\"\nparameter.initial_naming_factory = \"org.apache.activemq.jndi.ActiveMQInitialContextFactory\"\nparameter.provider_url = \"$env{JMS_PROVIDER_URL}\"\nparameter.connection_factory_name = \"QueueConnectionFactory\"\nparameter.connection_factory_type = \"queue\"\nparameter.cache_level = \"consumer\"\n"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#environment-variables","title":"Environment variables","text":"Using environment variables is a recommended practice when developing integration artifacts with WSO2 Integration Studio, as it improves configuration management, security, portability, and manageability. By leveraging environment variables, organizations can streamline the management and maintenance of their integrations, ensuring that updates can be implemented quickly and efficiently.
The component's Deploy page provides a user-friendly interface to manage environment variables across different environments. For information on managing environment variables for complex use cases, see Configurations and secrets.
Environment variables offer several benefits:
For a comprehensive list of parameters that can be configured as environment variables, see WSO2 API Manager Documentation - Injecting Parameters - Supported parameters.
"},{"location":"develop-components/work-with-the-micro-integrator-runtime-in-choreo/#configure-logging","title":"Configure logging","text":"Configuring logging is crucial when developing and maintaining a software system, as it can significantly improve efficiency during the development, testing, and maintenance phases of the software development process. Logging captures events and messages that occur during an application's execution, providing valuable insights for troubleshooting and debugging issues.
With Micro Integrator instances, you can configure and customize logging according to your requirements. Logging configurations can be added to each MI instance's environment, allowing you to fine-tune logging depending on the specific environment or deployment scenario.
To configure logging in MI instances, follow the steps given below:
Tip
You can use environment variables with specific naming conventions.
logging_level_ followed by the package or class name.Set the variable value to the required logging level for the corresponding package or class.
For example, to enable wire logs, change the logging level of the org.apache.synapse.transport.http.wire package to debug.
To configure logging, set the environment variable as follows:
Specify the following values as mount configurations:
Field Value Config Name An appropriate name for the configuration. Namelogging_level_org_apache_synapse_transport_http_wire Value debug Click Create.
WSO2 Micro Integrator (MI) Connectors are prebuilt connectors designed to simplify integration between WSO2 MI and various other systems. They enable seamless connections to databases, message brokers, REST APIs, and more, allowing you to perform actions such as sending messages, executing queries, or retrieving data. These connectors are easy to use, making it straightforward to incorporate them into your WSO2 MI integration flows. Micro Integrator connectors are versatile and can be utilized in various integration scenarios, including data integration, service-oriented architecture (SOA) integration, and event-driven architecture (EDA) integration.
WSO2 Integration Studio is a comprehensive development environment that facilitates the creation of integration flows using WSO2 Micro Integrator Connectors. With Integration Studio, you can design and implement integration flows that connect diverse systems and execute various actions, such as sending messages, executing queries, or retrieving data. You can build integration flows using either prebuilt connectors provided by WSO2 MI or custom connectors developed using the Connector Development Toolkit. Integration Studio offers a graphical user interface that simplifies the process of building and testing integration flows while also providing a set of tools for managing and deploying these flows in a WSO2 MI runtime environment.
For more information, see the following topics in the WSO2 API Manager documentation.
WSO2 MI buildpack is where you can deploy integrations developed with WSO2 Micro Integrator as an API. In this preset, you have three different ways to define endpoints. Choreo gives priory to the definition of endpoints in the below-mentioned order.
Using endpoints.yaml file This is the most flexible method to define endpoints. You can configure the endpoint details with the endpoints.yaml configuration file. Place this file in the .choreo directory in the project path of the component. If the Micro Integrator project has inbound endpoints, you can expose them via different endpoints using the endpoints.yaml
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
Auto generating endpoints If endpoints.yaml is not provided and if the source Micro Integrator project has APIs, Choreo scans the project and generates the API endpoints. If the project has few APIs, an endpoint will be generated for each API. The visibility of this auto-generated endpoint is set to Public by default. You can change the visibility in the deployment flow.
Provide default endpoints If endpoints.yaml is not provided and if the source Micro Integrator project doesn't have APIs, Choreo generates a default endpoint which will expose the default micro integrator port (8290) with Public visibility and wildcard context.
For a hands-on experience with MI-based integrations in Choreo, we recommend exploring our samples in Choreo Console. You can filter out the samples based on the buildpack WSO2 MI. This will point you to the samples in the Choreo samples GitHub repository
Fork the Repository: Start by forking the repository to your account.
Explore & run: Navigate through the different integration scenarios. Each example has a README.md with setup and execution instructions.
This guide walks you through the steps to develop, deploy, test, and observe a manual task using Choreo.
In this guide, you will:
Before you try out the steps in this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.Fork the Choreo samples repository, which contains the sample integration for this guide.
Repository file structure
To work with the sample repository, it is important to familiarize yourself with the repository file structure. The sample code for this guide is in the <sample-repository-dir>/weather-to-email-integration directory. To understand how the functionality is implemented, you must read the code comments. The following table describes what you will find in each file in the repository:
Go to OpenWeatherMap and sign up to obtain an API key. For details on how to obtain an API key, see the OpenWeatherMap documentation.
Enter a unique name and a description for the component. You can use the name and description given below:
Field Value Component NameWeatherToEmail Description My first manual task Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repositorychoreo-samples Branch main Buildpack Ballerina Project Directory weather-to-email-integration Tip
Buildpack specifies the type of build to run depending on the implementation of the component. It converts the integration code into a Docker image that can run on Choreo cloud. If an integration is developed using WSO2 Integration Studio, select Micro Integrator as the buildpack. If an integration is developed using the Ballerina language, select Ballerina as the buildpack.
Project Directory specifies the location of the project to build the component.
Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component.
To build the manual task, follow the steps given below:
Select the latest commit and click Build. This triggers the build process and displays the build progress in the Build Logs pane.
Info
The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with the build status.
Here, you will see the build status as Success.
"},{"location":"develop-components/develop-integrations/develop-a-manual-task/#step-3-deploy-the-manual-task","title":"Step 3: Deploy the manual task","text":"To deploy the manual task, follow the steps given below:
In the Configurations pane, specify values as follows for the configurable variables:
Tip
The configurable variables populated here are defined in the sample Ballerina project used in this guide. To learn how to declare configurable variables in Ballerina, see the Ballerina documentation on declaring configurable variables. If configurable variables are detected in a connected Ballerina project, Choreo prompts for the respective values during component deployment.
Field Value apiKey The API key you obtained in the prerequisites section latitude Latitude of the location to get the weather forecast longitude Longitude of the location to get the weather forecast email The email address to receive the formatted weather forecast informationNote
If you use Ballerina as the buildpack and you want to set a configurable variable as a secret, click the lock icon corresponding to the configurable variable. This marks it as a secret and conceals the input value.
For example, if you consider the configurable variables in this guide and set the apiKey as a secret, its input value will be concealed as follows:
If you want to update the input value at a later time, you can click Update Secret Content and specify a new value.
Click Deploy.
To execute the manual task, follow the steps given below:
Click Run Now. This triggers the task.
Inject dynamic values into your application as command-line arguments
If you want to inject dynamic values into your application as command-line arguments when you run a manual task, follow the steps given below:
The capability to run a manual task with arguments is supported for the following buildpacks:
DockerfileGoJavaNodeJSWSO2 MIBallerinaTo explore a Dockerfile-based manual task with arguments, try out the Hello World Task sample. For instructions, see the readme.md file in the sample repository.
Info
When you work on Docker projects, the Run with Arguments capability is not supported if the Dockerfile contains CMD. In such scenarios, you must use ENTRYPOINT to define your default commands.
To explore a Go-based manual task with arguments, try out the Hello World Go Task sample. For instructions, see the readme.md file in the sample repository.
To explore a Java-based manual task with arguments, try out the Hello World Java Task sample. For instructions, see the readme.md file in the sample repository.
Info
When you work on Java projects:
Procfile is available in the project.Main class should be defined in the manifest file.mvn.cmd exist in the project without the .mvn directory, the build will fail. To ensure a successful build, you must either commit the .mvn directory along with any Maven files or not include any Maven files in the project if you choose not to commit the .mvn directory.To explore a NodeJS-based manual task with arguments, try out the Hello World NodeJS Task sample. For instructions, see the readme.md file in the sample repository.
Info
When you work on NodeJS projects:
Procfile is available in the project.package.json file with the main attribute defined.To explore a WSO2 MI-based manual task with arguments, try out the Weather to Logs Task sample. For instructions, see the readme.md file in the sample repository.
Info
When you work on WSO2 MI projects and you want to deploy a WSO2 MI integration as a manual task in Choroeo, you must use the WSO2 MI automation mode. For details, see Running the Micro Integrator in Automation Mode.
To explore a Ballerina manual task with arguments, try out the Weather to Email Task sample. For instructions, see the README.md file in the sample repository.
Info
If you want to pass arguments to Ballerina main functions, you can use the Run with Arguments capability. For details on the arguments you can pass, see the Ballerina documentation. You can also override configurable values in the same manner. For more information, see Provide values to configurable variables.
Once the task is triggered, an email with the subject [WSO2 Choreo Demo] Next 24H Weather Forecast is sent from choreo.demo@gmail.com to the email address specified as the email configurable variable value in Step 3.
If the manual task ran successfully, you should receive an email similar to the following to the email address you specified:
"},{"location":"develop-components/develop-integrations/develop-a-manual-task/#step-6-observe-the-manual-task","title":"Step 6: Observe the manual task","text":"The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy.
To visualize and monitor the performance of the manual task you deployed, click Observability in the left navigation menu. You can observe the following:
To learn more about the observability details you can view via Choreo observability, see Observability Overview.
"},{"location":"develop-components/develop-integrations/develop-a-manual-task/#step-7-monitor-executions","title":"Step 7: Monitor executions","text":"To track and monitor executions associated with the deployed scheduled task, go to the left navigation menu and click Execute.
Tip
The Execute view is applicable to both scheduled and manual tasks.
You can view the following information:
The total number of executions within the past 30 days.
The currently active executions and those that are already complete.
Here, you can view information such as the execution ID, the revision of the execution, and the time it was triggered.
Detailed execution logs for a specific execution.
You can click on an execution to view detailed logs related to it.
Info
It may take a few minutes for the logs to appear. You may need to manually refresh to view the latest logs.
Choreo is a versatile integration platform that allows you to create various types of integrations depending on your requirement.
If you have a requirement to automatically run a specific integration at regular intervals, you can use Choreo to develop a scheduled task. This type of integration can automate the synchronization of data between different systems at specified intervals, reducing errors and improving productivity by eliminating the need for manual intervention.
This guide walks you through the steps to develop, deploy, test, and observe a scheduled task using Choreo.
In this guide, you will:
Before you try out the steps in this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.Fork the Choreo samples repository, which contains the sample integration for this guide.
Repository file structure
To work with the sample repository, it is important to familiarize yourself with the repository file structure. The sample code for this guide is in the <sample-repository-dir>/weather-to-email-scheduled-task directory. To understand how the functionality is implemented, you must read the code comments. The following table describes what you will find in each file in the repository:
Go to OpenWeatherMap and sign up to obtain an API key. For details on how to obtain an API key, see the OpenWeatherMap documentation.
Enter a unique name and a description for the component. You can use the name and description given below:
Field Value Component NameWeatherToEmail Description My first scheduled task Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repositorychoreo-samples Branch main Buildpack Ballerina Project Directory weather-to-email-scheduled-task Tip
Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component.
Now you can proceed to build and deploy the scheduled task.
"},{"location":"develop-components/develop-integrations/develop-a-scheduled-task/#step-2-build-the-scheduled-task","title":"Step 2: Build the scheduled task","text":"To build the scheduled task, follow the steps given below:
Select the latest commit and click Build. This triggers the build process and displays the build progress in the Build Logs pane.
Info
The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with the build status.
Here, you will see the build status as Success.
"},{"location":"develop-components/develop-integrations/develop-a-scheduled-task/#step-3-deploy-the-scheduled-task","title":"Step 3: Deploy the scheduled task","text":"To deploy the scheduled task, follow the steps given below:
In the Configurations pane, specify values as follows for the configurable variables:
Tip
The configurable variables populated here are defined in the sample Ballerina project used in this guide. To learn how to declare configurable variables in Ballerina, see the Ballerina documentation on declaring configurable variables. If configurable variables are detected in a connected Ballerina project, Choreo prompts for the respective values during component deployment.
Field Value apiKey The API key you obtained in the prerequisites section latitude Latitude of the location to get the weather forecast longitude Longitude of the location to get the weather forecast email The email address to receive the formatted weather forecast informationNote
If you use Ballerina as the buildpack and you want to set a configurable variable as a secret, click the lock icon corresponding to the configurable variable. This marks it as a secret and conceals the input value.
For example, if you consider the configurable variables in this guide and set the apiKey as a secret, its input value will be concealed as follows:
If you want to update the input value at a later time, you can click Update Secret Content and specify a new value.
Click Next.
In this step, you must define a schedule to run the task. In this guide, you set the schedule to receive the weather information daily at 8.00 AM UTC. Enter values as follows to configure the schedule:
Field Value Select Time Zone Select a time zone to schedule the task Select Range Day Every1 At 08:00 Tip
When you develop a scheduled task, you can define a schedule depending on your requirement. If you want to test and verify the immediately, you can schedule the deployment to run in just a few minutes after you create it. However, to avoid unnecessary expenses, make sure you reschedule or stop the deployment once you test and verify.
Click Deploy. This deploys the scheduled task to the development environment and indicates the Scheduled Status as Active in the Development card.
You can test the scheduled task when it runs at the configured time.
"},{"location":"develop-components/develop-integrations/develop-a-scheduled-task/#step-4-test-the-scheduled-task","title":"Step 4: Test the scheduled task","text":"When the scheduled task runs at the configured time, an email with the subject [WSO2 Choreo Demo] Next 24H Weather Forecast is sent from choreo.demo@gmail.com to the email address specified as the email configurable variable value in Step 3.
If the scheduled task ran successfully, you should receive an email similar to the following to the email address you specified:
"},{"location":"develop-components/develop-integrations/develop-a-scheduled-task/#step-5-observe-the-scheduled-task","title":"Step 5: Observe the scheduled task","text":"The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy.
To visualize and monitor the performance of the scheduled task you deployed, click Observability in the left navigation menu. You can observe the following:
To learn more about the observability details you can view via Choreo observability, see Observability Overview.
"},{"location":"develop-components/develop-integrations/develop-a-scheduled-task/#step-6-monitor-executions","title":"Step 6: Monitor executions","text":"To track and monitor executions associated with the deployed scheduled task, go to the left navigation menu and click Execute.
Tip
The Execute view is applicable to both scheduled and manual tasks.
You can view the following information:
The total number of executions within the past 30 days.
The currently active executions and those that are already complete.
Here, you can view information such as the execution ID, the revision of the execution, and the time it was triggered.
Detailed execution logs for a specific execution.
You can click on an execution to view detailed logs related to it.
Info
It may take a few minutes for the logs to appear. You may need to manually refresh to view the latest logs.
An Event Handler executes predefined actions in response to specific events. Choreo simplifies the process of creating and deploying such integrations.
This guide walks you through the steps to create and deploy an Event Handler using WSO2 MI and Choreo.
In this guide, you will build a simple event handler that monitors RabbitMQ for new messages and displays them once they become available.
"},{"location":"develop-components/develop-integrations/develop-an-event-handler/#prerequisites","title":"Prerequisites","text":"Before you try out the steps in this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.Use an existing RabbitMQ instance or start a new RabbitMQ instance on a server that can be accessed via the internet. Obtain the username, hostname, password, and vhost from the RabbitMQ instance to use later as environment variables.
Fork the Choreo samples repository, which contains the sample integration for this guide.
Enter a unique name and a description for the component. You can use the name and description given below:
Field Value Component NameSalesOrderListener Description RabbitMQ integration Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repositorychoreo-samples Branch main Buildpack WSO2 MI because you are creating the REST API from a WSO2 Integration Studio project Project Directory mi-rabbitmq-listener Tip
Click Create.
To deploy the integration, follow the steps given below:
In the Configurations pane, click + Add corresponding to Environment Variables and add the following environment variables:
Tip
Use the values from your RabbitMQ instance as per the Prerequisites section, for the environment variables.
Name Value HOSTNAME Hostname of your RabbitMQ server VHOST Virtual hostname of your RabbitMQ server USERNAME Username for connecting to RabbitMQ PASSWORD Password associated with the RabbitMQ usernameClick Deploy. This deploys the event handler to the development environment and indicates the Deployment Status as Active in the Development card.
To test the integration, follow the steps given below:
{\n\"order_id\": \"12345\",\n\"customer_name\": \"John Doe\",\n\"product\": \"Widget\",\n\"quantity\": 10,\n\"total_amount\": 100.00\n}\nNow you have gained hands-on experience in creating, configuring, and deploying an event handler.
"},{"location":"develop-components/develop-integrations/develop-an-integration-with-integration-studio/","title":"Develop an Integration with Integration Studio","text":"The seamless integration of APIs, microservices, applications, and data across different languages and formats requires the ability to expose integrations as APIs. Choreo simplifies building, deploying, and managing integration components, making it easy for you to quickly expose integrations as APIs.
Note
This guide walks you through the steps to expose an integration you created in WSO2 Integration Studio as an API in Choreo.
In this guide, you will:
Before you try out the steps in this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.Fork the Choreo samples repository, which contains the sample integration for this guide.
Enter a unique name and a description for the component. You can enter the name and description given below:
Field Value Component NameHello World Description Hello World REST API Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repositorychoreo-samples Branch main Buildpack WSO2 MI because you are creating the REST API from a WSO2 Integration Studio project Project Directory hello-world-mi Click Create. Choreo initializes the component with the sample integration.
To deploy the integration component to the development environment, follow the steps given below:
Click Deploy. This deploys the integration component to the development environment. The Development card indicates the Deployment Status as Active when the integration is successfully deployed.
Tip
Choreo uses endpoints to expose Service component to the network. You can read more about configuring endpoints in Configure Endoints.
Tip
Automatic deployment is enabled for the component by default. Therefore, you are required to perform only the first deployment manually.
Now you can test the integration.
"},{"location":"develop-components/develop-integrations/develop-an-integration-with-integration-studio/#step-3-test-the-integration","title":"Step 3: Test the integration","text":"To test the integration using the OpenAPI Console. Follow the steps given below:
Go to the Response body section and observe the response returned by the integration. If the integration works as expected, you should see a response similar to the following:
{\"Hello\" : \"Integration\"}
The observability view in Choreo displays graphs that depict details such as throughput, latency, diagnostic data, and logs to identify and troubleshoot anomalies in components you deploy.
To visualize and monitor the performance of the integration component you deployed, click Observability in the left navigation menu. You can observe the following:
To learn more about the observability details you can view via Choreo observability, see Observability Overview.
"},{"location":"develop-components/develop-integrations/develop-an-integration-with-integration-studio/#step-5-publish-the-integration-component","title":"Step 5: Publish the integration component","text":"To publish the integration component, follow the steps given below:
To open the published API in the Developer Portal via the Lifecycle Management pane, click Go to Devportal. In the Choreo Developer Portal, you can view the published API, manage subscriptions for it, and generate access tokens for testing purposes.
Now, you have gained hands-on experience in exposing an integration designed using WSO2 Integration Studio as a REST API in Choreo.
"},{"location":"develop-components/develop-services/develop-a-ballerina-service/","title":"Develop a Ballerina Service","text":"Choreo allows you to develop and deploy applications using your preferred programming language. This guide demonstrates how to deploy a service component that exposes a REST API using the Ballerina language. No prior knowledge of the Ballerina language is required to follow this guide.
A REST API is a web service adhering to Representational State Transfer (REST) principles, using HTTP methods to access and manage resources. This guide walks you through building a Ballerina service component, deploying it on Choreo, and using it with an HTTP client application.
In this guide, you will:
Build a simple greeting service using a sample service implementation. The sample implementation will have a single resource named greet that accepts a single query parameter as input.
Request:
$ curl GET http://localhost:9090/greeter/greet?name=Ballerina
Response:
$ hello Ballerina!
Deploy the service in Choreo. The service will run on port 9090.
Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample greetings service implementation in Ballerina.
It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service:
Note
The specified file paths are relative to <sample-repository-dir>/greeting-service.
service.bal The greetings service code written in the Ballerina language. tests/service_test.bal Test files related to the service.bal file. Ballerina.toml The Ballerina configuration file. Let's get started!
"},{"location":"develop-components/develop-services/develop-a-ballerina-service/#step-1-create-a-service-component","title":"Step 1: Create a service component","text":"To create a Ballerina service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameBallerina Greetings Component Name ballerina-greetings Description Send greetings Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account Repository choreo-samples Branchmain Select Ballerina as the buildpack.
/greeting-service.You have successfully created a service that exposes a REST API written in the Ballerina language. Next, let's build and deploy the service.
"},{"location":"develop-components/develop-services/develop-a-ballerina-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that you have connected the source repository and configured the endpoint details, it's time to build and deploy the service.
Note
If you are rebuilding the Ballerina service component after changing the Ballerina version, ensure that before building the code, the version of the Ballerina distribution mentioned in the Ballerina.toml file matches the distribution version specified in the Dependencies.toml file.
To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
To build and deploy the service, follow the steps below:
Once you have successfully deployed your service, you can test, manage, and observe it like any other component type in Choreo.
For detailed instructions, see the following sections:
If you want to view Kubernetes-level insights to perform a more detailed diagnosis of this Ballerina REST API, see Choreo's DevOps capabilities.
"},{"location":"develop-components/develop-services/develop-a-service-with-docker/","title":"Develop a Service with Docker","text":"Choreo is a platform that allows you to create and deploy applications in any language.
In this guide, you will:
greet that accepts a single query parameter as input.If you want to create a service component that exposes a Ballerina service, see Develop a Ballerina Service .
"},{"location":"develop-components/develop-services/develop-a-service-with-docker/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample greetings service implementation with the Dockerfile.
It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service:
Note
The specified file paths are relative to <sample-repository-dir>/greeting-service-go
main.go The Go-based greeter service code. Dockerfile The Dockerfile to build the container image of the application. .choreo/endpoints.yaml Choreo-specific configuration that provides information about how Choreo exposes the service. openapi.yaml The OpenAPI contract of the greeter service. This is required to publish the service as a managed API. This openapi.yaml file is referenced by the .choreo/endpoints.yaml file. Let's get started!
"},{"location":"develop-components/develop-services/develop-a-service-with-docker/#configure-the-service-port-with-endpoints","title":"Configure the service port with endpoints","text":"In Choreo, you can expose your services via endpoints.
You are going to run the greeter service on port 9090. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints.
To configure the endpoint details of a containerized component, Choreo looks for an endpoints.yaml file inside the .choreo directory. Be sure to place the .choreo directory at the root of the Docker build context path.
In the greeter sample, the endpoints.yaml file is in the greeting-service-go/.choreo/ directory.
To create a containerized service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGreetings Component Name greetings Description Send greetings Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account Repository choreo-samples Branchmain Select Docker as the buildpack.
Enter the following information:
Field Value Docker Context/greeting-service-go Dockerfile /greeting-service-go/Dockerfile Info
To successfully build your container with Choreo, it is essential to explicitly define a user ID (UID) under the USER instruction in your Dockerfile. For reference, see sample Dockerfile. To ensure that the defined USER instruction is valid, it must conform to the following conditions:
10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.The Dockerfile used in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries.
Click Create. This creates the component and takes you to the Overview page of the component.
You have successfully created a service from a Dockerfile. Next, you can build and deploy the service.
"},{"location":"develop-components/develop-services/develop-a-service-with-docker/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that we have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then we can deploy that image test the greeter service.
"},{"location":"develop-components/develop-services/develop-a-service-with-docker/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
You can access the following scans under Build.
Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail.
Info
If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
Once you have successfully deployed the service, you can test, manage, and observe it like any other component type in Choreo.
To perform a more detailed diagnosis of this Dockerfile-based REST API by viewing Kubernetes-level insights, see Choreo's DevOps capabilities.
"},{"location":"develop-components/develop-services/develop-a-service/","title":"Develop a Service","text":"Choreo allows you to create and deploy applications in your preferred programming language.
In this guide, you will:
greet that accepts a single query parameter as input.Go buildpack. The service will run on port 9090.Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample greetings service implementation in Go.
It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service:
Note
The specified file paths are relative to <sample-repository-dir>/greeting-service-go
main.go The Go-based greeter service code. .choreo/endpoints.yaml Choreo-specific configuration that provides information about how Choreo exposes the service. openapi.yaml The OpenAPI contract of the greeter service. This is required to publish the service as a managed API. This openapi.yaml file is referenced by the .choreo/endpoints.yaml file. Let's get started!
"},{"location":"develop-components/develop-services/develop-a-service/#configure-the-service-port-with-endpoints","title":"Configure the service port with endpoints","text":"In Choreo, you can expose your services via endpoints.
You are going to run the greeter service on port 9090. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints.
To configure the endpoint details of a containerized component, Choreo looks for an endpoints.yaml file inside the .choreo directory. Be sure to place the .choreo directory at the root of the Docker build context path.
In the greeter sample, the endpoints.yaml file is in the greeting-service-go/.choreo/ directory.
To create a containerized service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGreetings Component Name greetings Description Send greetings Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repository choreo-samples Branchmain Select Go as the buildpack.
Enter the following information:
Field Value Go Project Directory/greeting-service-go Language Version 1.x Click Create. This creates the component and lists it under Component Listing on the project home page.
You have successfully created the service. The next step is to build and deploy it.
"},{"location":"develop-components/develop-services/develop-a-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that you have connected the source repository and configured the endpoint details, it's time to build and deploy the greeter service.
"},{"location":"develop-components/develop-services/develop-a-service/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
Greetings component you created. This takes you to the component overview page.On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
Once you have successfully deployed the service, you can test, manage, and observe it like any other component type in Choreo.
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/","title":"Expose a Ballerina GraphQL Endpoint via a Service","text":"Choreo offers the flexibility to develop and deploy applications in a language of your preference. This guide shows you how to deploy a service component that exposes a GraphQL API using the Ballerina language in Choreo. No prior knowledge of the Ballerina language is required to follow this guide.
GraphQL API is a query language and runtime that provides a single endpoint for retrieving flexible and efficient data in a strongly-typed and self-documenting way. By following this guide, you will build a service component in Ballerina and deploy it on Choreo for any GraphQL client application to utilize it.
This guide shows how to build a simple reading list service and deploy it in Choreo using Ballerina. The GraphQL endpoint you create in this guide has two operations: Query and Mutation. The Query type operations read the data in the data source, and the Mutation operations update the data in the data source. The reading list service has two queries and three mutations as follows:
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#queries","title":"Queries","text":"Retrieve the reading list
This resource accepts an optional filter, status, which filters the reading list by reading status. Accepted values for status are reading, read, and to_read.
Sample request:
$ curl -X POST -H \"Content-Type: application/json\" -d '{\"query\": \"query {allBooks (status: \\\"reading\\\") { id title author status }}\"}' http://localhost:8090\n Sample response
$ {\n \"data\": {\n \"allBooks\": [\n {\n \"id\": 1,\n \"title\": \"Sample Book\",\n \"author\": \"Test Author\",\n \"status\": \"to_read\"\n }\n ]\n }\n}\n Retrieve a book item from the reading list
This resource accepts a filter, id, which will select the book item from the reading list by book id. The id is an Integer value.
Sample request
$ curl -X POST -H \"Content-Type: application/json\" -d '{\"query\": \"query {book (id: 1) { id title author status }}\"}' http://localhost:8090\n Sample response
$ {\n \"data\": {\n \"book\": {\n \"id\": 1,\n \"title\": \"Sample Book\",\n \"author\": \"Test Author\",\n \"status\": \"to_read\"\n }\n }\n}\n"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#mutations","title":"Mutations","text":"Add a book item to the reading list
This remote function accepts a book record as the input and consists of the title and the author. When you add a new book to the reading list, the method updates the reading status of the newly added book to to_read. This method returns the added book item upon successful execution.
Sample request
$ curl -X POST -H \"Content-type: application/json\" -d '{ \"query\": \"mutation { addBook(book: {title: \\\"Sample Book\\\", author: \\\"Test Author\\\"}) { id title author status } }\" }' 'http://localhost:8090'\n Sample response
$ {\n \"data\": {\n \"addBook\": {\n \"id\": 1,\n \"title\": \"Sample Book\",\n \"author\": \"Test Author\",\n \"status\": \"to_read\"\n }\n }\n}\n Update the reading status of a book
This remote function requires id and status as inputs to update the reading status of the selected book. The id refers to the id of the book. It is an integer. The status refers to the reading status that needs to be updated. This method returns the updated book item upon successful execution.
Sample request
$ curl -X POST -H \"Content-type: application/json\" -d '{ \"query\": \"mutation { setStatus(id: 1, status: \\\"reading\\\") { id title author status } }\" }' 'http://localhost:8090'\n Sample response
$ {\n \"data\": {\n \"setStatus\": {\n \"id\": 1,\n \"title\": \"Sample Book\",\n \"author\": \"Test Author\",\n \"status\": \"reading\"\n }\n }\n}\n Delete a book item from the reading list
This remote function requires the id as the input to delete the book item from the reading list. This method returns the removed book item upon successful execution.
Sample request
$ curl -X POST -H \"Content-type: application/json\" -d '{ \"query\": \"mutation { deleteBook(id: 1) { id title author status } }\" }' 'http://localhost:8090'\n Sample response
$ {\n \"data\": {\n \"deleteBook\": {\n \"id\": 1,\n \"title\": \"Sample Book\",\n \"author\": \"Test Author\",\n \"status\": \"reading\"\n }\n }\n}\n Our next step is to set up the resources that you will require to follow the guide, including the sample reading list application and the Choreo GitHub app.
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#prerequisites","title":"Prerequisites","text":"If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample GraphQL service implementation for this guide.
Let's get started!
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#learn-the-repository-file-structure","title":"Learn the repository file structure","text":"It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the reading list service.
Note
The following file paths are relative to the path <sample-repository-dir>/reading-list-graphql.
service.bal The reading list service code written in the Ballerina language. Ballerina.toml The Ballerina configuration file. .choreo/endpoints.yaml The configuration file with endpoint details."},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#step-1-create-a-service-component","title":"Step 1: Create a service component","text":"To create a Ballerina service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameBallerina Reading List Component Name ballerina-reading-list Description Manage a reading list Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Ballerina as the buildpack.
Enter the following information:
Field Value Ballerina Project Directoryreading-list-graphql Click Create. This creates the component and takes you to the Overview page of the component.
You have successfully created a service component that exposes a GraphQL API written in the Ballerina language. Next, let's build and deploy the service.
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that we have connected the source repository, it's time to build and deploy the reading list service.
"},{"location":"develop-components/develop-services/expose-a-ballerina-graphql-endpoint-via-a-service/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
To build and deploy the service, follow the steps below:
Once you have successfully deployed your service, you can test, manage, and observe it like any other component type in Choreo.
For detailed instructions, see the following sections:
Choreo allows you to create and deploy applications in your preferred programming language. One powerful option is gRPC, a high-performance and language-agnostic remote procedure call (RPC) framework. It utilizes Protocol Buffers to define services and generate client/server code.
In this guide, you will learn to use Choreo to create a service component that exposes a gRPC server implemented in Go, enabling efficient and scalable communication with any gRPC client application. No prior knowledge of the Go language is necessary to follow this guide.
By following this guide, you will:
Link the containerized gRPC service to the Choreo component using the Dockerfile. The greeter service has a single RPC method named sayHello. Following is the proto file the server and the client application are using:
syntax = \"proto3\";\noption go_package = \"github.com/wso2/choreo-samples/go-grpc/pkg\";\nservice greeter {\nrpc SayHello (HelloRequest) returns (HelloReply) {}\n}\nmessage HelloRequest {\nstring name = 1;\n}\nmessage HelloReply {\nstring message = 1;\n}\n Deploy the gRPC server component in Choreo.
Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample service implementation for this guide.
Let's get started!
"},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#learn-the-repository-file-structure","title":"Learn the repository file structure","text":"It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the greeter service.
Note
The following file paths are relative to the path <sample-repository-dir>/go-grpc.
main.go The greeter service code written in the Go language. greeter_client/main.go The greeter client application written in the Go language. Dockerfile.server The Dockerfile to build the container image of the server application. Dockerfile.client The Dockerfile to build the container image of the client application. .choreo/endpoints.yaml The Choreo-specific configuration that provides information about how Choreo exposes the service. pkg/greeter.proto The interface definition of the gRPC service. This is used to generate the server and client stubs for the Go application."},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#configure-the-service-port-with-endpoints","title":"Configure the service port with endpoints","text":"In Choreo, you can expose your services via endpoints.
Let's run the gRPC server service component on port 8080. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints.
Choreo looks for an endpoints.yaml file inside the .choreo directory to configure the endpoint details of the containerized component. Ensure the .choreo directory is at the root of the Docker build context path.
In the gRPC server sample, the endpoints.yaml file is at go-grpc/.choreo/endpoints.yaml, where the build context path is go-grpc.
To create a containerized service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo gRPC Server Component Name go-grpc-server Description Send greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextgo-grpc Dockerfile go-grpc/Dockerfile.server Info
To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile. To ensure that the defined USER instruction is valid, it must conform to the following conditions:
10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries.
Click Create. This creates the component and takes you to the Overview page of the component.
You have successfully created a service from a Dockerfile. Next, you can build and deploy the service.
"},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the greeter service.
"},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
You can access the following scans under Build.
Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail.
Info
If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
Once you have successfully deployed your service, navigate to the component overview page and copy the gRPC service URL. You need to provide that URL when setting up the client application later in this guide.
You have successfully deployed the gRPC server. Currently, the gRPC service is only accessible by the components deployed within the same project.
"},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#step-3-invoke-the-grpc-service","title":"Step 3: Invoke the gRPC service","text":"Let's invoke the gRPC service that you created above, using a gRPC client.
"},{"location":"develop-components/develop-services/expose-a-grpc-endpoint-via-a-service/#step-31-create-a-manual-task-for-the-grpc-client","title":"Step 3.1: Create a manual task for the gRPC client","text":"To create a manual task component, follow these steps:
Enter a display name, a unique name, and a description for the component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo gRPC Client Component Name go-grpc-client Description Receive greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextgo/grpc Dockerfile go/grpc/Dockerfile.client Click Create. This creates the component and takes you to the Overview page of the component.
To build the component, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
The client application, in this case, the gRPC client, requires the server URL of the gRPC server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application:
Specify the following name and value to configure the environment variable for the client application:
Field Value NameGREETER_SERVICE Value Paste the URL value copied after deploying the gRPC service via step 2.2 above. Make sure to drop the http:// or grpc:// part and the trailing / from the URL when copying. For example, if the URL is http://go-grpc-server-3192360657:8080/, add only go-grpc-server-3192360657:8080. Click Add and then click Next.
To execute the gRPC client, follow these steps:
For details on what you can monitor via the execute page, see Monitor executions.
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/","title":"Expose a TCP Server via a Service","text":"Choreo offers the flexibility to design and deploy applications in the programming language of your choice. One viable choice for specific network communication needs is TCP (Transmission Control Protocol). TCP provides a reliable, stream-oriented communication mechanism that ensures data integrity and orderliness during transmission. It's the go-to option for scenarios where guaranteed data delivery and error recovery are paramount.
In this guide, you will learn to use Choreo to create a service component that exposes a TCP server implemented in Go, enabling efficient and scalable communication with any TCP client application. No prior knowledge of the Go language is necessary to follow this guide.
By following this guide, you will:
Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample service implementation for this guide.
Let's get started!
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#learn-the-repository-file-structure","title":"Learn the repository file structure","text":"It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the sample service.
Note
The following file paths are relative to the path <sample-repository-dir>/docker-tcp-service.
server/main.go The greeter service code written in the Go language. client/main.go The greeter client application written in the Go language. Dockerfile.server The Dockerfile to build the container image of the server application. Dockerfile.client The Dockerfile to build the container image of the client application. .choreo/endpoints.yaml The Choreo-specific configuration provides information about how Choreo exposes the service."},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#configure-the-service-port-with-endpoints","title":"Configure the service port with endpoints","text":"In Choreo, you can expose your services via endpoints.
Let's run the TCP server service component on port 5050. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints.
Choreo looks for an endpoints.yaml file inside the .choreo directory to configure the endpoint details of a containerized component. Place the .choreo directory at the root of the Docker build context path.
In our TCP server sample, the endpoints.yaml file is at docker-tcp-service/.choreo/endpoints.yaml, where the build context path is docker-tcp-service.
To create a containerized service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo TCP Server Component Name go-tcp-server Description Send greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextdocker-tcp-service Dockerfile docker-tcp-service/Dockerfile.server Info
To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile. To ensure that the defined USER instruction is valid, it must conform to the following conditions:
10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries.
Click Create. This creates the component and takes you to the Overview page of the component.
You have successfully created a service from a Dockerfile. Next, you can build and deploy the service.
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the service.
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
You can access the following scans under Build.
Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail.
Info
If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
Once you have successfully deployed your service, navigate to the component overview page and copy the TCP service address. You need to provide that address when setting up the client application later in this guide.
You have successfully deployed the TCP server. Currently, the TCP service is only accessible by the components deployed within the same project.
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#step-3-invoke-the-tcp-service","title":"Step 3: Invoke the TCP service","text":"Now let's use a TCP client to invoke the TCP service that you created above. To do this, you can create a manual trigger component as the TCP client. This is the recommended approach because, in this example, it's more efficient to have a client that connects to the server, sends a request, and then stops. Here, a continuously executing task isn't required. Furthermore, if you use a manual trigger component, you won't need to expose an endpoint in the client for invocation, unlike with an API.
"},{"location":"develop-components/develop-services/expose-a-tcp-server-via-a-service/#step-31-create-a-manual-trigger-for-the-tcp-client","title":"Step 3.1: Create a manual trigger for the TCP client","text":"To create a manual task component, follow these steps:
Enter a display name, a unique name, and a description for the component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo TCP Client Component Name go-tcp-client Description Receive greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextdocker-tcp-service Dockerfile docker-tcp-service/Dockerfile.client Click Create. This creates the component and takes you to the Overview page of the component.
To build the component, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
The client application, in this case, the TCP client, requires the server URL of the TCP server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application:
Specify the following name and value to configure the environment variable for the client application:
Field Value NameSERVER_ADDRESS Value Paste the URL value copied after deploying the TCP service via step 2.2 above. Make sure to drop the tcp:// part and the trailing / from the URL when copying. For example, add only go-tcp-server-1097922445:8080. Click Add and then click Next.
To execute the TCP client, follow these steps:
For details on what you can monitor via the execute page, see Monitor executions.
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/","title":"Expose a UDP Server via a Service","text":"Choreo offers the flexibility to design and deploy applications in the programming language of your choice. One compelling choice for certain network communication needs is UDP (User Datagram Protocol). UDP is a high-speed, connectionless protocol ideal for scenarios where lightweight, real-time data transmission is essential.
In this guide, you will learn to use Choreo to create a Service component that exposes a UDP server implemented in Go, enabling efficient and scalable communication with any UDP client application. No prior knowledge of the Go language is necessary to follow this guide.
By following this guide, you will:
Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
Fork the Choreo samples repository, which contains the sample service implementation for this guide.
Let's get started!
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#learn-the-repository-file-structure","title":"Learn the repository file structure","text":"It is important to understand the purpose of the key files in the sample service. The following table provides a brief overview of each file in the sample service.
Note
The following file paths are relative to the path <sample-repository-dir>/docker-udp-service.
server/main.go The greeter service code written in the Go language. client/main.go The greeter client application written in the Go language. Dockerfile.server The Dockerfile to build the container image of the server application. Dockerfile.client The Dockerfile to build the container image of the client application. .choreo/endpoints.yaml The Choreo-specific configuration provides information about how Choreo exposes the service."},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#configure-the-service-port-with-endpoints","title":"Configure the service port with endpoints","text":"In Choreo, you can expose your services via endpoints.
Let's run the UDP server service component on port 5050. To securely expose the service through Choreo, you must provide the port and other required information to Choreo. For detailed information on each attribute of an endpoint, see Configure Endpoints.
Choreo looks for an endpoints.yaml file inside the .choreo directory to configure the endpoint details of a containerized component. Place the .choreo directory at the root of the Docker build context path.
In our gRPC server sample, the endpoints.yaml file is at docker-udp-service/.choreo/endpoints.yaml, where the build context path is docker-udp-service.
To create a containerized service component, follow these steps:
Enter a display name, a unique name, and a description for the service component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo UDP Server Component Name go-udp-server Description Send greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextdocker-udp-service Dockerfile docker-udp-service/Dockerfile.server Info
To successfully build your container with Choreo, it is essential to explicitly define a User ID (UID) under the USER instruction in your Dockerfile. For reference, see the sample Dockerfile. To ensure that the defined USER instruction is valid, it must conform to the following conditions:
10001 or 10500.my-custom-user-12221 or my-custom-user are invalid User IDs.The Dockerfile utilized in this guide is a multi-stage Dockerfile, which is designed to keep the final image size small and provides the ability to build the application with a specific version of tools and libraries.
Click Create. This creates the component and takes you to the Overview page of the component.
You have successfully created a service from a Dockerfile. Next, you can build and deploy the service.
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#step-2-build-and-deploy","title":"Step 2: Build and deploy","text":"Now that you have connected the source repository, and configured the endpoint details, it's time to build the service and create an image. Then you can deploy the image and test the service.
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#step-21-build","title":"Step 2.1: Build","text":"To build the service, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
You can access the following scans under Build.
Container (Trivy) vulnerability scan: The details of the vulnerabilities open in a separate pane. If this scan detects critical vulnerabilities, the build will fail.
Info
If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment.
To deploy the service, follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. Once deployed, the Development environment card indicates the Deployment Status as Active.
Once you have successfully deployed your service, navigate to the component overview page and copy the UDP service address. You must provide that address when setting up the client application later in this guide.
You have successfully deployed the UDP server. Currently, the UDP service is only accessible by the components deployed within the same project.
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#step-3-invoke-the-udp-service","title":"Step 3: Invoke the UDP service","text":"Now let's use a UDP client to invoke the UDP service that you created above. To do this, you can create a manual trigger component as the UDP client. This is the recommended approach because, in this example, it's more efficient to have a client that connects to the server, sends a request, and then stops. Here, a continuously executing task isn't required. Furthermore, if you use a manual trigger component, you won't need to expose an endpoint in the client for invocation, unlike with an API.
"},{"location":"develop-components/develop-services/expose-a-udp-server-via-a-service/#step-31-create-a-manual-trigger-for-the-udp-client","title":"Step 3.1: Create a manual trigger for the UDP client","text":"To create a manual task component, follow these steps:
Enter a display name, a unique name, and a description for the component. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo UDP Client Component Name go-udp-client Description Receive greetings Click the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repositorychoreo-samples Branch main Select Docker as the buildpack.
Enter the following information:
Field Value Docker Contextdocker-udp-service Dockerfile docker-udp-service/Dockerfile.client Click Create. This creates the component and takes you to the Overview page of the component.
To build the component, follow these steps:
On the Build page, click Build Latest.
Note
Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
The client application, in this case, the UDP client, requires the server URL of the UDP server service. This is read from the client application as an environment variable. Follow the steps below to configure the environment variable for the client application:
Specify the following name and value to configure the environment variable for the client application:
Field Value NameSERVER_ADDRESS Value Paste the URL value copied after deploying the UDP service via step 2.2 above. Make sure to drop the udp:// part and the trailing / from the URL when copying. For example, add only go-udp-server-1097922445:8080. Click Add and then click Next.
To execute the UDP client, follow these steps:
For details on what you can monitor via the execute page, see Monitor executions.
"},{"location":"develop-components/develop-services/service-component-overview/","title":"Service Component Overview","text":"Explore how to create, deploy, manage, and observe service components in Choreo.
"},{"location":"develop-components/develop-services/service-component-overview/#what-is-a-service-component","title":"What is a service component?","text":"A service component in Choreo lets you deploy and expose REST, GraphQL, gRPC, UDP, or TCP services. It is a fundamental building block for creating cloud-native applications in Choreo. They provide a simple and effective way to expose functionality as a service to other components within Choreo or to the outside world.
Service components encapsulate business logic and provide standardized interfaces, called endpoints, for communicating with other components or systems. You can deploy and scale services independently, which makes them highly flexible and adaptable to changing workloads.
With the help of the service component, developers can quickly create APIs and microservices, making it easier to implement and manage complex software systems. Service components can also be integrated with other Choreo components, that acts as message processors, connectors, and data sources, etc to create powerful end-to-end solutions.
Services and integrations are exposed to other services, integrations, or applications through endpoints. A service or an integration can expose multiple endpoints, each representing a unique entry point into the service. For example, a service may expose a REST API endpoint and a GraphQL endpoint, each providing different ways to interact with the service. Endpoints provide specific details for how the service or the integration can be consumed. For instance, the port number, protocol, and the schema such as open API specification (OAS) or GraphQL schema. By defining these details, endpoints make it possible for other services, integrations, and applications to discover and interact with the service in a standardized way.
Choreo defines endpoints by combining port binding, protocol, endpoint name, network visibility, endpoint schema, and additional protocol-related fields. The following table describes each attribute of an endpoint.
Field Description Name A unique identifier for the endpoint within the service component. Port The network port on which the endpoint is accessible. Type The endpoint protocol. Supported protocols: REST, GraphQL, gRPC, UDP, and TCP. Network Visibility Determines the level of visibility of an endpoint. Possible values are:The method of defining endpoints depends on the buildpack. For buildpacks other than Ballerina and WSO2 MI, it is required to have an endpoints.yaml file in project root directory to create the Service component.
When you build a service component using any other buildpacks(Java, Python, NodeJS, Ruby, PHP, Go, Dockerfile, etc) other than Ballerina and WSO2 MI, you can configure the endpoint details with the endpoints.yaml configuration file. You must place this file inside the .choreo directory at the build context path and commit it to the source repository.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
When you create a service component with the Ballerina buildpack, Choreo automatically detects the endpoint details for REST APIs. You can override the auto-generated endpoint configuration by providing the endpoints.yaml file in the source directory.
Note
Automatic endpoint generation is not supported for dynamic endpoint parameters such as variable ports. Therefore, you must use an endpoint.yaml file to define dynamic endpoint parameters.
See Understanding the endpoints.yaml file to learn about the endpoints.yaml file.
The endpoints.yaml file has a specific structure and contains the following details:
endpoints.yaml file. name Required A unique name for the endpoint, which Choreo will use to generate the managed API. port Required The numeric port value that gets exposed via this endpoint. type Required The type of traffic this endpoint is accepting, such as REST, GraphQL, gRPC, UDPor TCP. Currently, the MI preset supports only the REST type. networkVisibility Required The network level visibility of this endpoint, which defaults to Public if not specified. Accepted values are Project, Organization, or Public. context Required The context (base path) of the API that Choreo exposes via this endpoint. schemaFilePath Required The swagger definition file path. Defaults to the wildcard route if not provided. This field should be a relative path to the project path when using the Java, Python, NodeJS, Go, PHP, Ruby, and WSO2 MI buildpacks. For REST endpoint types, when using the Ballerina or Dockerfile buildpack, this field should be a relative path to the component root or Docker context. Sample endpoints.yaml File location:
<docker-build-context-path>/.choreo/endpoints.yaml\n Note
For components built with Ballerina buildpack docker-build-context-path should be replaced with component-root. For example: <component-root>/.choreo/endpoints.yaml
For components built with WSO2 MI buildpack docker-build-context-path should be replaced with <Project Path>. For example: <Project Path>/.choreo/endpoints.yaml
File content:
# +required Version of the endpoint configuration YAML\nversion: 0.1\n# +required List of endpoints to create\nendpoints:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via this endpoint\nport: 9090\n# +required Type of the traffic this endpoint is accepting. Example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, UDP, TCP\ntype: REST\n# +optional Network level visibility of this endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Project\n# +optional Context (base path) of the API that is exposed via this endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional Path to the schema definition file. Defaults to wild card route if not provided\n# This is only applicable to REST endpoint types.\n# The path should be relative to the docker context.\nschemaFilePath: greeting_openapi.yaml\n"},{"location":"develop-components/develop-services/service-component-overview/#apply-advanced-component-connection-configurations","title":"Apply advanced component connection configurations","text":"The component-config.yaml file extends the capabilities of endpoints.yaml by introducing enhancements that allow you to apply advanced inbound and outbound connection configurations.
Beta release
component-config.yaml file is considered stable. However, it is important to note that the configuration schema may undergo changes and improvements based on user feedback. The component-config.yaml file complements and enhances the existing endpoint configuration process. It allows you to define how your service's endpoints (inbound connections) are exposed and how your service connects to external services or components (outbound connections).
Inbound configurations: This configuration section is for you to define inbound connections, Similar to endpoints.yaml, you can define how your service endpoints are exposed. It aligns seamlessly with the existing endpoint schema structure.
Outbound configurations: This configuration section is for you to specify outbound connection details, including service connections. The Choreo Internal Marketplace facilitates creating connections with existing services. To learn more about Choreo Marketplace, see Choreo Marketplace.
Note
component-config.yaml and endpoints.yaml are defined in the .choreo path, the component-config.yaml file takes priority.component-config.yaml file","text":"The component-config.yaml file has a specific structure and contains the following details:
component-config.yaml file defaults to core.choreo.dev/v1beta1. kind Required The resource type of the file defaults to ComponentConfig. spec.inbound Optional The list of inbound connection configurations. spec.outbound Optional The list of outbound connection configurations. Inbound connection configurations (spec.inbound) In the spec.inbound configuration section, you can specify endpoints to set up inbound connections. To specify endpoints, you can follow the existing endpoints schema structure. For details on the endpoints schema structure, see the endpoints schema documentation.
spec.outbound) In the spec.outbound section, you can define serviceReferences. To define serviceReferences, you can use the service references generated in the Internal Marketplace when creating a service connection. To copy the outbound connection configurations, see the inline developer guide that is available when you create a connection.
The serviceReferences schema has a specific structure and contains the following details:
Note
Choreo automatically generates outbound connection configurations upon the creation of a connection within the internal marketplace. The properties such as name, connectionConfig, and env.from are automatically generated. However, you must manually set the env.to value.
Sample component-config.yamlFile location:
<docker-build-context-path>/.choreo/component-config.yaml\n Note
docker-build-context-path with the component-root. For example, <component-root>/.choreo/component-config.yaml.docker-build-context-path with the <Project Path>. For example, <Project Path>/.choreo/component-config.yaml.File content:
apiVersion: core.choreo.dev/v1beta1\nkind: ComponentConfig\nspec:\n# +optional Incoming connection details for the component (AKA endpoints).\ninbound:\n# +required Unique name for the endpoint. (This name will be used when generating the managed API)\n- name: Greeting Service\n# +required Numeric port value that gets exposed via the endpoint\nport: 9090\n# +required Type of traffic that the endpoint is accepting. For example: REST, GraphQL, etc.\n# Allowed values: REST, GraphQL, GRPC, TCP, UDP.\ntype: REST\n# +optional Network level visibility of the endpoint. Defaults to Public\n# Accepted values: Project|Organization|Public.\nnetworkVisibility: Public\n# +optional Context (base path) of the API that gets exposed via the endpoint.\n# This is mandatory if the endpoint type is set to REST or GraphQL.\ncontext: /greeting\n# +optional The path to the schema definition file. Defaults to wildcard route if not specified.\n# This is only applicable to REST endpoint types.\n# The path should be relative to the Docker context.\nschemaFilePath: greeting_openapi.yaml\n# +optional Outgoing connection details for the component.\noutbound:\n# +optional Defines the service references from the Internal Marketplace.\nserviceReferences:\n# +required Name of the service reference.\n- name: choreo:///apifirst/mttm/mmvhxd/ad088/v1.0/PUBLIC\n# +required Name of the connection instance.\nconnectionConfig: 19d2648b-d29c-4452-afdd-1b9311e81412\n# +optional Environment variables injected to the component for connection configuration.\nenv:\n# +required Key name of the connection configuration.\n- from: ServiceURL\n# +required Environment variable injected to the container.\nto: SERVICE_URL\n"},{"location":"develop-components/develop-services/service-component-overview/#expose-endpoints-as-managed-apis","title":"Expose endpoints as managed APIs","text":"Exposing endpoints as managed APIs is crucial to ensure secure and controlled access to the services being exposed. When a user wants to expose their written service to the outside world or to the organization at large, there is an inherent security risk involved. To mitigate this risk, the Choreo platform is built with an internal (access within the organization only) or external (publicly accessible) gateway that is protected with Choreo API management making the services secure by design.
Note
This feature is not available for gRPC, UDP, and TCP endpoints.
If you want to expose an endpoint as a managed API in Choreo, you need to set the network visibility to either Organization or Public. This allows the endpoint to be exposed through the Choreo API Gateway, which provides a number of benefits, including:
Once you deploy the service component, Choreo will expose the endpoint as a managed API through the Choreo API Gateway. You can then use the full lifecycle API management features provided by Choreo to test, deploy, maintain, monitor, and manage your API using the API management features.
"},{"location":"develop-components/develop-services/service-component-overview/#understand-the-default-component-url","title":"Understand the default component URL","text":"The default URL of a component corresponds to the default endpoint of the component and is structured as follows:
<domain>/<project-name>/<component-name>
This URL does not include the default endpoint name. For all other endpoints, the URL structure includes the endpoint name, as follows:
<domain>/<project-name>/<component-name>/<endpoint-name>
If a component has multiple endpoints, Choreo allows you to change the endpoint corresponding to the default component URL. For a component with a single endpoint, the default URL automatically corresponds to that endpoint.
"},{"location":"develop-components/develop-services/service-component-overview/#change-the-default-endpoint-of-a-component","title":"Change the default endpoint of a component","text":"To change the default endpoint of a component, follow the steps given below:
Note
A web application is an application program hosted on a server and serves ingress traffic through a browser. In Choreo, you can deploy a web application by creating a Web Application component and connecting it to a Git repository that contains the implementation of the web application. Web applications can fall into one of the following categories:
You can create a web application in Choreo as follows:
Build and deploy a SPA from the source code.
package.json engine property. The required Node version must be explicitly set in the build configuration.Once you create the Web Application component, Choreo automatically generates a build pipeline for your single-page application and deploys it.
Bring your Dockerfile.
This approach is recommended if you are deploying a web server and not just a single-page application (or a single-page application with a complex build process).
Host static websites.
Now let's take a look at how you can build and deploy a SPA from source code:
Follow the steps below to create a sample Web Application component and deploy it in Choreo:
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description GitHub Account Your account GitHub Repository choreo-samples Branch mainSelect React as the Buildpack.
Enter the following information:
Field Description Project Directory /react-single-page-app Build Commandnpm run build Build Path build Node Version 18 Tip
Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks. To learn how to set up authentication for your web application with Choreo's managed authentication, see Secure Web Applications with Managed Authentication.
Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component.
You have successfully created a Web Application component from the source code. Now let's build and deploy the web application.
"},{"location":"develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application/#build-your-web-application","title":"Build your web application","text":"To build the web application, follow the steps given below:
Select the latest commit and click Build. This triggers the build process and displays the progress in the Build Logs pane.
You can access the following scans in the Build Logs pane:
Info
If you have Choreo environments on a private data plane, you can ignore these vulnerabilities and proceed with the deployment.
Note
The build process can take a while to complete. When the build process is complete, the build will be listed in the Builds pane along with its status.
Here, you will see the build status as Success.
"},{"location":"develop-components/develop-web-applications/build-and-deploy-a-single-page-web-application/#deploy-and-access-your-web-application","title":"Deploy and access your web application","text":"Keep the default settings and click\u00a0Deploy.
Note
To verify that you have successfully hosted the web application, click the\u00a0Web App URL\u00a0in the\u00a0Development\u00a0card. This takes you to the web application.
Info
This feature is only available on the Choreo cloud data plane.
When you promote your component to the Production environment, you have the option to create a personalized short URL for your web application. The URL follows the https://{your-short-prefix}.choreoapps.dev structure, where you can select a name of your preference for {your-short-prefix}.
To create a short URL for your web application, follow the steps given below:
Specify a Short URL prefix of your choice and click Save.
Note
Short URL names/prefixes are subject to availability, provided on a first-come-first-serve basis.
For web applications with a backend server, Choreo allows you to mount runtime configurations and secrets as environment variables and/or file mounts for a specific environment. Alternatively, you can also inject them into the client application during server-side rendering or when serving static content.
However, in the case of SPAs that run completely on the browser, Choreo does not support baking-in environment variables or other configurations. This is because Choreo follows a multi-environment deployment model, where configuration should be kept separate from the build and injected at runtime. For example, in most React SPA frameworks, the process.env stub is available during build time. However, it does not actually read in variables from the runtime. Instead, it is baked into the final JavaScript output during the build process.
To manage runtime configurations, Choreo recommends the following approach (although this is a React example, the approach is generally applicable to other SPA frameworks as well).
Note
Follow the steps given below to manage runtime configurations for the React application you created above:
Create and commit a new file named config.js in the public directory of your React application. This file should contain the runtime configuration variables you want to expose to your application, such as API endpoints or feature flags. Let's expose the API URL and a feature flag as follows:
window.config = {\napiUrl: 'https://api.example.com',\n featureFlags: {\n enableNewFeature: true,\n enableExperimentalFeature: false,\n },\n};\n 4. In your index.html file inside the public directory, add a script tag as follows to include the config.js file inside the tag. The config.js file will be accessible via JavaScript at runtime. <!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"utf-8\" />\n <title>My React App</title>\n</head>\n<body>\n <div id=\"root\"></div>\n <script src=\"%PUBLIC_URL%/config.js\"></script>\n</body>\n</html>\n This makes the window.config object available to your app at runtime. In your React component, you can access the configuration variables by referencing the window.config object as follows:
import React from 'react';\n\nfunction MyComponent() {\nconst apiUrl = window.config.apiUrl;\nconst enableNewFeature = window.config.featureFlags.enableNewFeature;\nconst enableExperimentalFeature = window.config.featureFlags.enableExperimentalFeature;\n\n// ...\n}\n Now you can deploy your component. When you deploy your component to Choreo, create a config file mount in the specified path for each environment (where your index.html expects the config.js file as in this example). https://wso2.com/choreo/docs/devops-and-ci-cd/manage-configurations-and-secrets/#apply-a-file-mount-to-your-container.
The following limitations are specific to the Choreo cloud data plane:
I\u2019m seeing a blank page or a 502 error after I deploy my web application
If you encounter a blank page or a 502 error after deploying your web application, it typically indicates that the wrong directory is being served. To resolve this issue, follow these steps:
public/ as the output directory when it should have been build/.By verifying and correcting the output directory alignment, you should be able to address the issue of encountering a blank page or experiencing a 502 error on deploying your web application.
Choreo\u2019s managed authentication capability exposes a set of backend for frontend (BFF) endpoints, facilitating authentication and authorization for web applications. These endpoints are readily available for single-page web applications deployed on Choreo.
As a web application developer, there may be instances where it becomes necessary to run the application on your personal workstation. In such situations, the expectation is for authentication and authorization during local development to work in the same manner as it would when the application is deployed to Choreo, eliminating the need to modify the source code.
Choreo's local development capability ensures a seamless local application development experience where the authentication and authorization process aligns with Choreo\u2019s deployment environment. This facilitates a smoother transition from development to deployment, improving workflow efficiency.
"},{"location":"develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication/#how-local-development-works-in-choreo","title":"How local development works in Choreo","text":"Local development uses a proxy that sits in front of the locally running web application. This proxy intercepts all incoming requests. The requests to /choreo-apis/* and /auth/* are then forwarded to Choreo, while all other requests are forwarded to the locally running web application. The proxy runs on HTTPS using a self-signed certificate, crucial for secure, HTTP-only cookie-based managed authentication. Upon running the proxy, you can access the web application using the proxy's URL and start developing the application locally. You will observe that the behavior of the web application, in terms of the managed authentication functionality, is similar to how it would be after deploying to Choreo.
Promote and deploy the application to the environment where you want to enable local development.
Note
Now you have done the necessary configurations to set up local development. The next section walks you through the steps to access your web application so that you can develop it locally.
"},{"location":"develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication/#access-your-web-application-to-develop-it-locally","title":"Access your web application to develop it locally","text":""},{"location":"develop-components/develop-web-applications/develop-web-applications-locally-with-managed-authentication/#prerequisites_1","title":"Prerequisites","text":"http://localhost on a specific port.You can either use the Choreo built-in identity provider or external identity provider to access your web application locally.
Use the Choreo built-in identity providerUse an external identity providerTo access the application and proceed to develop it, go to the URL given under Step 2 in the Local Development pane.
Note
The local development proxy runs on HTTPS using a self-signed certificate. Your browser may warn that the certificate is not valid. Accept the risk and proceed.
To access the application and proceed to develop it, go to the URL given under Step 3 in the Local Development pane.
Note
The local development proxy runs on HTTPS using a self-signed certificate. Your browser may warn that the certificate is not valid. Accept the risk and proceed.
Connections in Choreo allow you to integrate Choreo components, or to integrate Choreo components to external services or resources. Connections provide a simple and uniform way to integrate with services and resources.
To consume a service deployed on Choreo within your service, you must create a connection to the service you want to consume.
To create a connection, follow the steps given below:
In the Choreo Console, go to the top navigation menu and set the visibility level as project or component as follows:
From the left navigation menu, click Dependencies and then Connections. This page will list the currently available connections.
For step-by-step instructions on how to use a connection in your service, see Use a Connection in Your Service.
For step-by-step instructions on how to use a connection in your web application, see Use a Connection in Your Web Application.
"},{"location":"develop-components/sharing-and-reusing/use-a-connection-in-your-service/","title":"Use a Connection in Your Service","text":"Choreo allows you to share and reuse your services, accelerating development and enhancing efficiency in building integrated applications through connections.
For step-by-step on instruction on creating a connection, see Create a Connection.
To learn more about Choreo Connections, see the documentation on Connections.
"},{"location":"develop-components/sharing-and-reusing/use-a-connection-in-your-service/#consume-a-service-through-a-connection","title":"Consume a service through a connection","text":"You can consume a Choreo-deployed service within another service. Consuming connections from within Choreo services is seamless and straightforward. Follow the steps below to consume a Choreo service:
"},{"location":"develop-components/sharing-and-reusing/use-a-connection-in-your-service/#step-1-add-connection-configurations","title":"Step 1: Add connection configurations","text":"To integrate another service into your application, follow the steps below:
Copy and paste the snippet from the in-line developer guide into the component-config file under the spec section.
The following is a sample snippet:
outbound:\nserviceReferences:\n- name: <SERVICE_NAME>\nconnectionConfig: <CONNECTION_ID>\nenv:\n- from: ServiceURL\nto: <YOUR_ENV_VARIABLE_NAME_HERE>\n- from: ConsumerKey\nto: <YOUR_ENV_VARIABLE_NAME_HERE>\n- from: ConsumerSecret\nto: <YOUR_ENV_VARIABLE_NAME_HERE>\n- from: TokenURL\nto: <YOUR_ENV_VARIABLE_NAME_HERE>\n Field Description Name The name of the service you are connecting to. ConnectionConfig The unique connection identifier for the connection. env The environment variable mapping. from The key of the configuration entry. to The environment variable name to which Choreo will inject the value of the key. Replace <YOUR_ENV_VARIABLE_NAME_HERE> with an appropriate environment variable name of your choice. If you have previously added an outbound service reference, append this as another item under serviceReferences.
Upon deploying the component, Choreo automatically creates a subscription if applicable and populates the specified environment variables with actual values.
The following table provides details on the configuration keys associated with the connection:
Name Type Description Optional Sensitive ServiceURL string Service URL of the Choreo service false false ConsumerKey string Consumer key of the Choreo service false false ConsumerSecret string Consumer secret of the Choreo service false true TokenURL string Token URL of the STS false falseOnce you add the connection configuration snippet, you can proceed to read those configurations within your application. The steps to follow depend on the programming language you are using.
The following is a sample code snippet in NodeJS:
const serviceURL = process.env.SVC_URL;\n"},{"location":"develop-components/sharing-and-reusing/use-a-connection-in-your-service/#step-3-acquire-an-oauth-20-access-token","title":"Step 3: Acquire an OAuth 2.0 access token","text":"To consume a Choreo service with the visibility level set to organization or public and secured by the OAuth 2.0 security scheme, you must obtain an OAuth 2.0 token from the token endpoint. Subsequently, you can use the token to invoke the service.
For languages with OAuth 2.0-aware HTTP clients, you must pass the OAuth 2.0-related configurations such as client id, client secret and so on, obtained when creating the connection to your HTTP client configuration. The HTTP client autonomously manages token retrieval and refreshing.
For languages without OAuth 2.0-aware HTTP clients, you must manually initiate a call to the token endpoint. This includes fetching the token and managing token expiration and refresh directly within your application code. The following is a sample curl command to obtain a token:
CONSUMER_KEY=\"your_consumer_key\"\nCONSUMER_SECRET=\"your_consumer_secret\"\nTOKEN_URL=\"your_token_url\"\n# Encode client credentials as Base64\nCLIENT_CREDENTIALS=$(echo -n \"$CLIENT_ID:$CLIENT_SECRET\" | base64)\ncurl -X POST $TOKEN_URL \\\n-H \"Content-Type: application/x-www-form-urlencoded\" \\\n-H \"Authorization: Basic $CLIENT_CREDENTIALS\" \\\n--data-urlencode \"grant_type=client_credentials\"\n You can invoke the service as follows:
For languages with OAuth 2.0-aware HTTP clients, you can invoke the service in a straightforward manner. The HTTP client seamlessly manages OAuth 2.0 authentication without requiring additional intervention.
As the service URL you can use the URL that you resolved in step 2. For sample requests and responses, see the API definition provided via the Choreo marketplace for the service.
For languages without OAuth 2.0-aware HTTP clients, you can use the token obtained in step 3 to make calls to the dependent service. Subsequently, add the obtained token to the HTTP authorization header with the bearer prefix. As the service URL you can use the URL that you resolved in step 2. For sample requests and responses, see the API definition of the service provided via the Choreo marketplace.
The following is a sample code snippet in NodeJS:
const response = await axios.get(serviceURL/{RESOURCE_PATH}, {\nheaders: {\n'Authorization': `Bearer ${accessToken}`\n}\n});\n Note
If you want to consume a Choreo service at the project visibility level, you don't need to obtain a token. You can directly invoke the service using the resolved URL.
Choreo simplifies the process of integrating services into your web application. The approach to connect to a service can vary based on your web application.
To connect to a selected service, follow the step-by-step instructions given below depending on the authentication mechanism used in your web application.
Managed authenticationCustom authentication or no authenticationChoreo-managed authentication allows you to seamlessly handle authentication for your web application. You can configure your web application to work with the built-in identity provider of Choreo or any external identity provider that supports OIDC/OAuth2.0
Note
Choreo's managed authentication is currently available only for web applications created with React, Angular, or Vue.js buildpacks.
Follow the steps below to use an existing connection within your web application:
Step 1: Add the connection configuration
To integrate a service into your application, you must first add the connection configuration as follows:
For single page applications (SPAs), you must add the connection configuration as a file mount. You can mount a file via the Configurations pane on the Deploy page. You must mount a file (for example, config.js) and add the configuration provided in the in-line developer documentation into it.
The following is a sample configuration:
window.configs = {\napiUrl: '<SERVICE_URL>', };\n To ensure accessibility of the config.js file via JavaScript at runtime, add a script tag as follows in the index.html file to reference the config.js file:
<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\" />\n<title>My React App</title>\n</head>\n<body>\n<div id=\"root\"></div>\n<script src=\"%PUBLIC_URL%/config.js\"></script>\n</body>\n</html>\n Note
If you use an external IdP, you must add the IdP's configuration to the same file.
For more information on working with IdPs, see Configure Asgardeo as an External Identity Provider.
Step 2: Read the configuration
Once you add the connection configuration, you can proceed to read the configuration from your application. The steps to read depend on the programming language you use.
The following is a sample code snippet in NodeJS:
const serviceURL = window?.configs?.apiUrl ? window.configs.apiUrl : \"/\";\n Step 3: Invoke the service
If you use Choreo-managed authentication, Choreo handles the security handshaking for the application during deployment. The connected service will be accessible under the same domain as your application. Therefore, you can call the configured path directly using your preferred HTTP client.
The following is a sample code snippet in NodeJS:
const response = await axios.get(serviceURL/{RESOURCE_PATH});\n Note
If you are using an external IdP provider instead of Choreo-managed authentication, you must obtain an access token from your IdP and add it to the HTTP authorization header with the bearer prefix.
If you are not using Choreo-managed authentication or your web application lacks authentication, follow the steps below to connect to a service from your web application:
Step 1: Add the connection configuration
For single-page applications (SPAs), you must add the connection configuration as a file mount. You can mount a file via the Configurations pane on the Deploy page. You must mount a file (for example, config.js) and add the following configuration into it.
The following is a sample configuration:
window.configs = {\napiUrl: '<SERVICE_URL>',\nconsumerKey: '<CONSUMER_KEY>',\nconsumerSecret: '<CONSUMER_SECRET>',\ntokenUrl: '<TOKEN_URL>',\n};\n For other types of web applications, you must add the respective configuration into your application.
Step 2: Read the configuration
Once you have added the connection configuration, you can proceed to read the configuration from your application. The steps to read depend on the programming language you use.
The following is a sample code snippet in NodeJS:
const serviceURL = window?.configs?.apiUrl ? window.configs.apiUrl : \"/\";\n Step 3: Acquire an OAuth 2.0 access token
For languages with OAuth 2.0-aware HTTP clients, you must pass the OAuth 2.0-related configurations such as client id, client secret and so on, obtained when creating the connection to your HTTP client configuration. The HTTP client autonomously manages token retrieval and refreshing.
For languages without OAuth 2.0-aware HTTP clients, you must manually initiate a call to the token endpoint. This includes fetching the token and managing token expiration and refresh directly within your application code. The following is a sample curl command to obtain a token:
CONSUMER_KEY=\"your_consumer_key\"\nCONSUMER_SECRET=\"your_consumer_secret\"\nTOKEN_URL=\"your_token_url\"\n# Encode client credentials as Base64\nCLIENT_CREDENTIALS=$(echo -n \"$CLIENT_ID:$CLIENT_SECRET\" | base64)\ncurl -X POST $TOKEN_URL \\\n-H \"Content-Type: application/x-www-form-urlencoded\" \\\n-H \"Authorization: Basic $CLIENT_CREDENTIALS\" \\\n--data-urlencode \"grant_type=client_credentials\"\n Step 4: Invoke the service
You can invoke the service as follows:
For languages with OAuth 2.0-aware HTTP clients, you can invoke the service in a straightforward manner. The HTTP client seamlessly manages OAuth 2.0 authentication without requiring additional intervention.
As the service URL you can use the URL that you resolved in step 2 above. For sample requests and responses, see the API definition provided via the Choreo marketplace for the service.
For languages without OAuth 2.0-aware HTTP clients, you can use the token obtained in step 3 above to make calls to the dependent service. Subsequently, add the obtained token to the HTTP authorization header with the bearer prefix.
As the service URL you can use the URL that you resolved in step 2 above. For sample requests and responses, see the API definition of the service provided via the Choreo marketplace.
The following is a sample code snippet in NodeJS:
const response = await axios.get(serviceURL/{RESOURCE_PATH}, {\nheaders: {\n'Authorization': `Bearer ${accessToken}`\n}\n})\n Choreo allows you to automatically scale your component replicas up or down in number based on resource consumption to ensure high availability.
Note
Autoscaling capabilities are only available in paid plans for private data plane organizations. In the free tier, components run in a single-replica, low-availability mode.
The following parameters allow you to scale component replicas:
2.5. There is no restriction on the value in private data planes.Tip
If you update a scaling parameter, it may not immediately reflect in the Choreo Console because the change can take some time to propagate.
Run a fixed number of replicas
If you want to run exactly 3 replicas for a component, you must set the minimum and maximum replicas to 3.
Scale to zero
0, your component does not scale to zero automatically during low usage. It can only go down to 1 replica.0 suspends the deployment.In Choreo, you can view detailed information about the container that comprises a component, such as its image tag, the corresponding commit ID, any imposed resource usage limits, and so on.
Each component in Choreo is limited to a single main container.
Resource Limits
Resource limits ensure that a single component does not take up more resources than it requires, which can affect other workloads on the data plane. If a process exceeds the allocated memory limit, the corresponding container will be forcefully shut down and restarted. If the process exceeds the allocated CPU limit, it gets throttled and can result in significant latencies in compute and I/O operations.
Choreo allows you to edit the default container configuration depending on your requirement.
"},{"location":"devops-and-ci-cd/configure-container-resources-commands-and-arguments/#update-container-configurations","title":"Update container configurations","text":"Follow these steps to update container configurations:
Apply the necessary changes and click Save.
The following topics walk you through the container configuration changes you can apply.
"},{"location":"devops-and-ci-cd/configure-container-resources-commands-and-arguments/#update-resource-requests-and-limits","title":"Update resource requests and limits","text":"Note
The capability to update resource requests and limits is only available in paid pricing plans.
To update resource requests and limits, move the corresponding slider to a required position. A resource request cannot be less than its corresponding limit.
"},{"location":"devops-and-ci-cd/configure-container-resources-commands-and-arguments/#set-the-image-pull-policy","title":"Set the image pull policy","text":"You can select one of the following options as the image pull policy.
If Not Present - The image is pulled from the container registry only if a matching image is not present in the data plane.
Tip
The recommended option is If Not Present.
You can specify appropriate values for the Container Port and Service Port. The Service Port is the port exposed outside of the container to your project-scoped endpoint. If you do not know the value to specify as the Service Port, specify the Container Port value in both fields.
Tip
You do not need to configure port values manually for Ballerina components. The capability to edit port values is primarily for containerized/Dockerfile-based components.
You can also select an appropriate Protocol.
"},{"location":"devops-and-ci-cd/configure-container-resources-commands-and-arguments/#define-a-command-and-arguments-for-the-container","title":"Define a command and arguments for the container","text":"You can define a command and arguments for a container when you want to provide or override the ENTRYPOINT of a container. For example, in a scenario where you want to run legacy or third-party applications, you would want to provide or override the ENTRYPOINT of a container.
When you define a command and arguments,
ENTRYPOINT array and it is not executed within a shell. $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged.$$ are reduced to $, which allows escaping the $(VAR_NAME) syntax. This means that \"$$(VAR_NAME)\" produces the string literal \"$(VAR_NAME)\". The ENTRYPOINT of the container image is used if you do not define a command and arguments for the container.
All components you create in Choreo have a default read-only file system, which you cannot access or write to from your applications.
Volume mounts allow you to create either temporary or persisted writable file system storage locations for your applications.
"},{"location":"devops-and-ci-cd/configure-storage/#volume-mount-types","title":"Volume mount types","text":"Type Description Empty Directory (In-Memory) A fast, temporary in-memory (tmpfs) storage location. This volume gets erased when you restart or remove the attached container. Available on all data planes. Empty Directory (Disk) A temporary storage location on disk. This volume gets destroyed when you restart or remove the attached container. Only available on private data planes. Persistent Volume A permanent storage location. This volume persists even if you restart or remove the attached container. Only available on private data planes.Tip
All components have a writable location in the /tmp directory at the time of component creation. You can also configure other writable locations if required.
Empty directory (in-memory or on-disk) mounts allow you to create temporary file systems that your application can read from and write to. This option provides a convenient way to create a scratch space to write files temporarily before storing them in a more permanent storage location such as a cloud-backed storage bucket. For example, unzipping a file, temporarily writing results from a memory-intensive operation to disk, a temporary local cache, etc. However, it is important to note that these volumes destroy when you restart or update a container because the volumes are attached to the lifetime of a container.
Follow these steps to create a temporary storage space for your container:
Click Next.
In-memory (tmpfs) storage uses up container memory
Storage capacity for this type of volume will count against the container's memory limit. Uncontrolled writes to this location may starve your application process of memory and can result in the container getting killed and restarted if the memory limits exceed.
To add a mount location, specify a Mount Path and click Add mount.
Tip
Click Create. This applies the volume mount immediately to your container and triggers a rolling restart.
Follow these steps to create a persistent storage space for your container:
Note
Persistent volume options are only available in private data plane organizations.
Select an appropriate Access Mode.
Check and specify an access mode supported by the storage class
Click Next.
To add a mount location, specify a Mount Path and click Add mount.
Tip
Click Create. This applies the volume immediately to your container.
Secure access to private networks from the Choreo cloud data plane is an essential use case for cloud data plane users.
Choreo allows this secure connection using Tailscale. For this, Choreo provides a prebuilt Tailscale image component that can act as a forward proxy, which you can deploy in your Choreo project as a service. This service allows you to forward traffic to your external networks via Tailscale\u2019s peer-to-peer WireGuard network.
The following diagram illustrates the high-level deployment architecture of the Tailscale pre-installed forward proxy:
Let's take a look at the specifics of each part to understand the deployment architecture.
Choreo project
In Choreo, a project groups various components. For more information on what a project in Choreo is, see the documentation on Project.
Tailscale proxy
This acts as the Tailscale pre-installed forward proxy, facilitating secure peer-to-peer WireGuard connections from the Choreo cloud data plane to private networks. It includes a Tailscale Daemon, SOCKS5 proxy, and a configurable TCP forwarder.
Tailscale daemon
This is the core component of Tailscale. It is a software service that provides secure network connectivity and private networking solutions. For more details see the Tailscale documentation.
SOCKS5 proxy
This uses Tailscale\u2019s userspace networking mode, rather than the kernel mode. Therefore, the inbuilt SOCKS5 proxy handles the forwarded traffic and directs it through the Tailscale network.
TCP forwarder
Forwards inbound TCP (transmission control protocol) traffic from the Tailscale proxy container\u2019s network interface to the SOCKS5 proxy, ensuring it reaches its destination via the secured WireGuard tunnel.
User applications and the Choreo API gateway
User applications within the same namespace (project) can use the Kubernetes service created to front the Tailscale proxy, for connecting to the corresponding private endpoints. You can either expose this service within the organization via the internal API gateway or expose it to the public via the external API gateway. For more details, see the documentation on Choreo endpoints.
Now that you understand the deployment architecture, let\u2019s explore how you can use Tailscale to secure connections to your private networks.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#configure-and-use-tailscale-to-access-private-network-endpoints","title":"Configure and use Tailscale to access private network endpoints","text":"This section walks you through the steps to create, configure, deploy, and use the Tailscale proxy component.
Let's get started.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#prerequisites","title":"Prerequisites","text":"If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the organization home page.
Follow the steps given below to create a project:
Enter a display name, unique name, and description for the project. You can enter the values given below:
Info
In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project.
Field Value Project Display Name Tailscale Proxy Project Name tailscale-proxy-project Project Description My Tailscale projectClick Create. This creates the project and takes you to the project home page.
Enter a display name, component name, and a description for the service. For this guide, let's enter the following values:
Field Value Component Display Name Tailscale proxy Component Name tailscale-proxy Description Tailscale proxy componentClick the Container Registry tab.
Now you have successfully created the Tailscale proxy. You can proceed to configure and deploy it.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#step-2-configure-and-deploy-the-tailscale-proxy","title":"Step 2: Configure and deploy the Tailscale proxy","text":"Here, you will add the required volume mounts, set the Tailscale authentication key, configure the TCP forwarder, configure endpoints, and deploy the Tailscale proxy. Follow the steps given below:
Step 2.1: Add required volume mountsTailscale requires the following volume mounts for its operations:
/var/run/tailscale/.localTo create the volume mounts, follow the step-by-step instructions in Configure Storage.
Step 2.2: Configure and deploy the componentTo configure and deploy the component, follow the steps given below:
TS_AUTH_KEY environment variable as a secret. To add the environment variable, you must obtain an authentication key from your Tailscale network.To mount a configuration file to the Tailscale proxy component and specify the port mapping for the TCP forward proxy running there, do the following:
/config.yaml as the Mount Path.Specify the following in the sample configuration file:
portMappings:\n 8080: \"100.108.78.93:8090\"\n 8081: \"100.108.78.93:1433\"\n Note
In this sample configuration, the TCP traffic arriving at port 8080 on your Tailscale proxy will be forwarded to port 8090 on the node with IP address 100.108.78.93 in your Tailscale network. Similarly, port 8081 will map to the corresponding address. You can find the IP addresses of your nodes on the Tailscale machines page in your Tailscale network's admin console or via the Tailscale clients running on your machine.
Click Next.
In the Endpoints pane that opens, click + Add and edit the endpoints.yaml configuration to expose your Tailscale proxy as a service. The following is a sample endpoints.yaml configuration you can use:
Note
The sample endpoints.yaml file given below defines two project-level endpoints. These endpoints can be used by other components within the same project to access the services. If you want to directly expose your private endpoint via the Choreo gateway either with the Public or Organization visibility, you can set the networkVisibility property of the endpoint to Public or Organization.
version: 0.1\nendpoints:\n- name: Private HTTP service\nport: 8080\ntype: REST\nnetworkVisibility: Project\ncontext: /\n- name: Private DB service\nport: 8081\ntype: TCP\nnetworkVisibility: Project\ncontext: /\n Click Save.
Click Next and then click Deploy.
Note
Deploying the component may take a while. You can track the progress by observing the logs. Once the deployment is complete, the build status changes to Active on the Development environment card.
When the component is deployed, you can observe a new node connected to your Tailscale network. To view this, go to the Tailscale machines page of your Tailscale coordination server.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#step-3-access-private-network-endpoints-with-the-tailscale-proxy","title":"Step 3: Access private network endpoints with the Tailscale proxy","text":"Now you have successfully deployed the Tailscale proxy in your project and it is connected to your Tailnet. You can proceed to use the Tailscale proxy to provision access for other components to securely access private network endpoints.
You can configure endpoints of the Tailscale proxy to use it for various aspects within Choreo.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#post-deployment-actions","title":"Post-deployment actions","text":""},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#handle-node-key-expiry","title":"Handle node key expiry","text":"Tailscale nodes have a default node key expiry time of 180 days. Nodes require re-authentication after key expiry to avoid connection losses and application downtime. There is an option to disable node key expiry if necessary. For more details, see Node key expiry documentation.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#handle-auth-key-expiry","title":"Handle auth key expiry","text":"Auth keys are used to register new nodes into your Tailscale network. The default expiry time for auth keys is 90 days, but nodes remain connected even after auth key expiry. This becomes an issue only if the Tailscale Proxy component is redeployed or restarted.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#update-port-mapping-configurations","title":"Update port mapping configurations","text":"If you want to add a new private endpoint to your network and access it via the same Tailscale proxy within Choreo, you must add a new port mapping entry in the port mapping configuration of your Tailscale proxy deployment.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#best-practices","title":"Best practices","text":""},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#configure-health-checks","title":"Configure health checks","text":"Since the Tailscale proxy acts as a forward proxy, it is important to configure health checks. You can use one of the open ports of the TCP forwarder as a health endpoint. For details on how to set up health probes in Choreo, see Set up health checks.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#use-tailscale-acls","title":"Use Tailscale ACLs","text":"You can use Tailscale ACLs to precisely manage permission for users and devices on your Tailnet.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#disable-scale-to-zero-for-the-tailscale-proxy","title":"Disable scale-to-zero for the Tailscale proxy","text":"It is recommended to disable Scale-to-Zero for the Tailscale proxy because it acts as a forward proxy and should always be up and running to make consistent connections with the Tailscale VPN mesh. If you enable Scale-to-Zero, you may experience service downtime.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#run-multiple-replicas-with-hpa-horizontal-pod-autoscaler","title":"Run multiple replicas with HPA (horizontal pod autoscaler)","text":"To achieve high availability and resiliency for the Tailscale proxy, you must run multiple replicas with HPA. To configure multiple replicas for the Tailscale proxy component, go to the Scaling page under DevOps. For more details, see Autoscale component replicas
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#security-best-practices","title":"Security best practices","text":"Before deploying the Tailscale proxy in production environments, it is recommended to follow the Tailscale production best practices and security best practices.
Note
Choreo blocks incoming connections from other nodes in your Tailnet to the Tailscale proxy to prevent access to your project\u2019s namespace in the Choreo cloud data plane.
"},{"location":"devops-and-ci-cd/configure-vpns-on-the-choreo-cloud-data-plane/#troubleshoot-issues","title":"Troubleshoot issues","text":"For assistance in resolving common Tailscale proxy issues, see Troubleshoot Tailscale proxy issues.
"},{"location":"devops-and-ci-cd/manage-configurations-and-secrets/","title":"Manage Configurations and Secrets","text":"Choreo allows you to easily manage and version your component's configurations and secrets as file mounts or environment variables.
Note
All configurations and secrets applied to a Choreo component are stored in an encrypted secret vault in the cloud data plane, which is managed by WSO2. If you are on a private data plane, the configurations and secrets are stored in an Azure key vault or AWS secret manager attached to your data plane in your cloud environment.
"},{"location":"devops-and-ci-cd/manage-configurations-and-secrets/#the-difference-between-configurations-and-secrets","title":"The difference between configurations and secrets","text":"Choreo considers all configurations and secrets to be sensitive content when storing them, but gives you the option to choose between secret or configuration when you create a file mount or an environment variable.
Configurations can be read and updated via the Choreo Console after you create them.
Note
If you want to include sensitive data such as database passwords, cloud credentials, service accounts, and so on, the recommended approach is to use a secret instead of a configuration.
Follow these steps to apply a file mount to a component you have created:
If you want to create the file mount as a secret, select Mark as a Secret. Otherwise, proceed to the next step.
Note
If you create the file mount as a secret, you will not be able to read the file content after you create the file mount.
In the Display Name field, specify a name for the file mount.
Tip
The display name does not affect the file mount or its content. It is only a reference to identify the configuration or secret you create.
In the File Mount Path field, specify where to mount the file inside the container. Use an absolute file path with the file name and extension if applicable.
Tip
The file name in the mount path does not need to match the configuration name or the name of the file you upload.
Upload a configuration file or copy and paste the configuration content into the editor.
Click Create.
Note
Configurations and secrets are applied immediately to your environment on creation. To ensure that the container reflects the new content, your existing running replicas undergo a rolling restart.
Follow these steps to apply environment variables to a component you have created:
If you want to create the environment variable values as secrets, select Mark as a Secret. Otherwise, proceed to the next step.
Note
If you create environment variables as secrets, you will not be able to read the values you set for the environment variables after you create them.
In the Display Name field, specify a name to identify the configuration or secret.
Tip
The display name you specify does not affect the environment variables you set. It is only a reference to identify the configuration or secret you create.
Under Add Environment Variables, specify the necessary environment variables as key-value pairs. You can click Add Item to add any number of environment variables.
Click Create.
Follow these steps to update a configuration or secret you have defined:
Follow these steps to delete a configuration or secret you have defined:
Choreo manages the Ballerina configurables for the Ballerina components you create.
When you deploy or promote a Ballerina application, you can modify the Ballerina configurables via the Deploy page.
Tip
You can use configurables instead of environment variables to add file mounts to a Ballerina component. Environment variables are primarily for components written in other languages.
"},{"location":"devops-and-ci-cd/manage-environments/","title":"Manage Environments","text":"By default, all projects created in the cloud data planes (irrespective of the data plane region) are provisioned with two environments (i.e., development and production).
The environments are listed in the order of deployment and promotion. The initial deployment takes place in the first environment and you can proceed to promote a component to subsequent environments.
"},{"location":"devops-and-ci-cd/manage-environments/#create-a-new-environment","title":"Create a new environment","text":""},{"location":"devops-and-ci-cd/manage-environments/#prerequisites","title":"Prerequisites","text":"ENVIRONMENT-MANAGEMENT permission. By default, ENVIRONMENT-MANAGEMENT permission is granted to Admin and Choreo DevOps roles.To create a new environment, follow the steps given below:
On the Environments page, click Create and specify the following details to create a new environment:
Data Plane - The data plane to create the new environment.
Tip
The Data Plane list displays all the private data planes registered under your organization.
DNS Prefix: A DNS prefix to identify the exposed APIs in the environment. Here, the base domain depends on the custom domain attached to the API gateways provisioned on the selected data plane.
Mark environment as a Production environment: Select if you want this environment to be a production environment.
Tip
In Choreo, you can have multiple non-production and production environments. To work in a production environment, you must have privileged permissions to access and deploy to production environments.
The order in which environments are listed on the Environments page is the same order in which promotion takes place.
To change the order of promotion across environments in an organization, follow the steps given below:
On the Environments page, click and drag environment list items to rearrange the order of listed environments.
Note
Although changes to the order of promotion for environments are applied immediately, the change does not affect the components already running in environments. Only subsequent builds and promotions will follow the new order.
To see the changes, go to the Deploy page of a component (in any project).
"},{"location":"devops-and-ci-cd/manage-environments/#delete-an-environment","title":"Delete an environment","text":"To delete an environment, follow the steps given below:
Warning
Environment deletion is a permanent, non-reversible operation.
Health checks ensure that a running container is always healthy and ready to serve traffic.
"},{"location":"devops-and-ci-cd/set-up-health-checks/#liveness-probes","title":"Liveness probes","text":"Liveness probes run periodically on your container and restart if the probe fails. This allows the container to self-heal in scenarios where the application may have crashed or become unresponsive.
"},{"location":"devops-and-ci-cd/set-up-health-checks/#readiness-probes","title":"Readiness probes","text":"Similar to liveness probes, readiness probes run periodically throughout the lifecycle of a container. However, unlike liveness probes, these probes do not restart the container if the probe fails. Instead, they stop the container from receiving network traffic.
Readiness probes on single replicas
You must be mindful when you configure readiness probes on a single-running replica. If the readiness probe fails, your application stops receiving traffic because there is only one active replica. The application may not recover unless the liveness probe fails and restarts the container.
"},{"location":"devops-and-ci-cd/set-up-health-checks/#probe-types","title":"Probe types","text":"You can configure the following probe types for both readiness and liveness probes.
"},{"location":"devops-and-ci-cd/set-up-health-checks/#http-get-request","title":"HTTPGET request","text":"This probe sends an HTTP GET request to a specified port and path on the container. A response status code in the range of 200-399 indicates that the request is a success.
Depending on your requirement, you can configure additional HTTP headers.
The recommended approach is to create a /healthz or /health endpoint in your service for this purpose.
This probe attempts to open a socket to the container on the specified port. If it cannot establish a TCP connection, it becomes a failure.
"},{"location":"devops-and-ci-cd/set-up-health-checks/#execute-a-command","title":"Execute a command","text":"This probe executes a given script inside the container. A non-zero return from the command is considered a failure.
For example, [\"cat\", \"/tmp/healthy\"] is considered healthy if the file /tmp/healthy is present. If not, it becomes a failure (non-zero exit code). In such scenarios, the application is responsible for writing and maintaining this file in the specified location.
Follow these steps to configure liveness and readiness probes on a container:
Configure the liveness probe depending on your requirement.
Click Save.
Click Save.
Note
You can update or remove a probe at any time.
Follow these steps to ensure that the container works as expected:
In Choreo, you can view details about running replicas of a component in a specific environment (i.e., Development or Production).
To view the runtime details of a component, follow the steps given below:
The runtime details you can see here are analogous to a zoomed-in view of a specific environment on the Deploy page.
The following topics walk you through the specific details you can view and actions you can perform via the Runtime page.
"},{"location":"devops-and-ci-cd/view-runtime-details/#redeploy-a-release","title":"Redeploy a release","text":"On the Runtime page, you can click Redeploy Release to immediately redeploy all resources, including configurations and secrets, to a specific environment. This triggers a rolling update to sync all the latest changes to the data plane.
What is a release?
A release in Choreo uniquely identifies an underlying deployment of a component to an environment for a given version. For example, if you deploy a component to two environments across two versions, the component will have four active releases.
The capability to redeploy a release also allows you to quickly restart all the running replicas of a component in a specific environment.
"},{"location":"devops-and-ci-cd/view-runtime-details/#view-running-instances","title":"View running instances","text":"The running instances you see on the Runtime page provide insights into the active replicas of your component in the selected environment.
If you want to see the real-time logs and information on conditions and events of a replica, click the menu icon of the replica and then click Real-time Logs or Conditions & Events depending on what you need to view. These options provide insights that help to diagnose issues in deployments.
Note
Unlike the logs available in the Observability Metrics of a component, these logs are fetched in real-time from the data plane and are not historical. Therefore, you can only see logs of active containers and the last shutdown container.
Conditions and events provide information necessary to troubleshoot failing deployments.
If a component is not behaving as expected and you cannot detect any issues via the application logs, these events can provide necessary debugging information, such as the following:
Choreo allows you to automatically scale your component replicas up or down in number based on resource consumption to ensure high availability.
Note
Autoscaling capabilities are only available in paid plans for private data plane organizations. In the free tier, components run in a single-replica, low-availability mode.
The following parameters allow you to scale component replicas:
2.5. There is no restriction on the value in private data planes.Tip
If you update a scaling parameter, it may not immediately reflect in the Choreo Console because the change can take some time to propagate.
Run a fixed number of replicas
If you want to run exactly 3 replicas for a component, you must set the minimum and maximum replicas to 3.
Scale to zero
0, your component does not scale to zero automatically during low usage. It can only go down to 1 replica.0 suspends the deployment.Choreo provides the scale-to-zero capability for HTTP applications you deploy in the data plane. This lets you run your components in a serverless mode.
Scale to zero is very useful in lower environments, where you can significantly reduce infrastructure costs by scaling down idle workloads. In production environments, you can also use scale-to-zero capability if your application's behavior aligns with this feature behavior. In the paid tier, if you want to run your application with more guaranteed high availability, it is recommended to choose HPA (Horizontal Pod Autoscaler) scaling method and configure a minimum replica count of 2 or higher.
"},{"location":"devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero/#how-scale-to-zero-works-in-choreo","title":"How Scale to Zero works in Choreo","text":"Info
For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default.
When Scale to Zero is enabled, your apps will automatically scale down to zero unless they receive HTTP traffic. When the application receives an HTTP request, your workload quickly scales up from zero to handle the request. When a new request is received by the deployment, the deployment will scale up to one replica and serve the request. When the deployment remains idle for a set period (approximately 5 minutes), it will automatically scale back to zero until a new request is received.
When Scale to Zero is enabled, you can set the maximum number of replicas for deployments with this capability. Choreo dynamically scales deployments up to meet high HTTP traffic demand, up to the specified number of replicas. If the pending requests surpass the defined threshold under Number of pending requests to spawn a new pod, Choreo automatically adds a new replica to handle the increased load.
"},{"location":"devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero/#enable-scale-to-zero","title":"Enable scale to zero","text":"For service components and web-apps you create after February 23, 2024, Choreo enables the scale-to-zero feature by default. When deploying or promoting the component, the deployment will automatically scale-to-zero. Upon the next request to the deployed service, a replica will be created to serve the request.
Note
To enable scale-to-zero for service components created before February 23, 2024, follow the steps given below:
In the left navigation menu, click DevOps and then click Scaling.
If you are a free user, you will see a view similar to the one below. You can click the scale-to-zero card to enable scale-to-zero for your component.
If you are a paid user or you are running your applications in your own private data plane, you will see a view similar to the one below. You can click the scale-to-zero card to enable scale-to-zero for your component.
Note
The scale-to-zero service should start within 60 seconds. If it doesn\u2019t, the gateway will timeout the request.
You can independently scale Choreo components in both the Development and Production environments. The deployment card indicates the scaling status of each environment. To configure the scale-to-zero feature for a specific environment, click on the scale-to-zero link, which redirects to the Devops \u2192 Scaling page.
When you turn on the scale-to-zero for your application, the minimum replicas for your app will be set to zero. However, you can still select an appropriate maximum number of replicas.
"},{"location":"devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero/#limitations","title":"Limitations","text":"Scheduled tasks and manually triggered components cannot connect to a service on a project scope if scale-to-zero is enabled. Attempting to do so results in the following error:
Host not found, not forwarding request.
To allow a task-type component to invoke a project-level service, set it to HPA mode if you are on a paid plan, or to no scaling if you are on the Developer plan.
When your Choreo application scales down to zero, an intermediary proxy service intercepts incoming requests. If a request is directed at your application, this service initiates a scale-up. Requests are held in the proxy's queue until your application becomes active. After scaling up, the proxy forwards the queued requests to your application.
If your application remains without HTTP traffic for an extended period (default idle time is 5 minutes), it will be scaled down to zero until more HTTP requests arrive. Conversely, if there's a surge in HTTP traffic to your scaled-up application, Choreo will further increase its scale to manage the demand. Choreo considers adding additional replicas if the number of queued requests surpasses the 'Target Pending Requests' threshold, which is set to 100 by default. You can adjust this threshold in the user interface.
Note
The initial request after a long period of inactivity experiences a delay because the application must first scale up from zero. If your API operates in a service-chain sequence (e.g., service-1 activates service-2, which in turn calls service-3), this waiting time may extend further. If your application or its chain takes a considerable time to scale up, be aware that the first request might face a timeout.
"},{"location":"devops-and-ci-cd/autoscale/autoscale-components-with-scale-to-zero/#troubleshooting","title":"Troubleshooting","text":"When Choreo enables scale-to-zero by default, it will configure the readiness probe with some default values. However, in some cases, you may observe that your first request responds with a 503 status code. To overcome these behaviors, fine-tune the readiness probe in the DevOps \u2192 Health Checks view to match your application's needs.
"},{"location":"manage-databases-and-caches/billing-for-platform-services/","title":"Billing for Platform Services (Databases and Caches)","text":"Any platform services you create within your Choreo Organization will be included in your current Choreo subscription. The quantity included will vary depending on the service plan of the resources you create.
A few important considerations:
Try out the free trial
Choreo provides a 7 day free trial for all database types on the 'Hobbyist' service plan (for free tier users).
"},{"location":"manage-databases-and-caches/choreo-managed-caches/","title":"Choreo-Managed Cache","text":"Fully compatible with legacy Redis\u00ae OSS.
Choreo-Managed Cache provides fully-managed in-memory NoSQL databases on AWS, Azure, GCP, and Digital Ocean and can be used as a cache, database, streaming engine, or message broker.
"},{"location":"manage-databases-and-caches/choreo-managed-caches/#create-a-choreo-managed-cache","title":"Create a Choreo-Managed Cache","text":"Follow the steps below to create a Choreo-Managed Cache:
To connect to your Choreo-Managed Cache, follow these guidelines:
The high availability and the automatic backup retention periods for a Choreo-Managed Cache can vary as follows depending on the service plan you select.
Service plan High availability Backup features Backup history Hobbyist Single-node with limited availability. Single backup only for disaster recovery None Startup Single-node with limited availability. Single backup only for disaster recovery 1 day Business Two-node (primary + standby) with higher availability (automatic failover if the primary node fails). Automatic backups 3 days Premium Three-node (primary + standby + standby) with highest availability (automatic failover if the primary node fails). Automatic backups 13 daysIn general, service plans are recommended for production scenarios due to the following reasons:
Minor failures: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once it automatically restarts the crashed process or when it restores the network access.
Severe failures: Failures such as losing a node entirely in case of hardware or severe software problems, require more drastic recovery measures. The monitoring infrastructure automatically detects a failing node when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created.
The number of simultaneous connections in a Choreo-Managed Cache depends on the total available memory on the server instances.
You can use the following to estimate:
max_number_of_connections = 4 x m\n Here, m represents the memory in megabytes, where at least 10,000 connections are available, even on the smallest servers. For example, on a server with 4GB memory (4,096 MB), the simultaneous connections are:
4 x 4096 = 16384 // 16k connections\n This number is estimated by the exact available memory so it can vary between different plans and cloud providers. To see the exact maximum connections allowed, use the * redis-cli and info command as follows:
echo \"info\" | redis-cli -u REDIS_URI | grep maxclients\n"},{"location":"manage-databases-and-caches/choreo-managed-caches/#restricted-commands","title":"Restricted commands","text":"To maintain the stability and security of a managed environment, Choreo restricts certain commands on Choreo-Managed Cache services.
Support for Lua scripts on Choreo-Managed Cache
EVAL, EVALSHA, and SCRIPT LOAD commands.EVAL, EVALSHA, and SCRIPT LOAD commands are enabled by default.The following commands are disabled on Choreo:
bgrewriteaof: Initiates a background append-only file rewrite.cluster: Manages Caching cluster commands.command: Provides details about all Caching commands.debug: Contains sub-commands for debugging Caching.failover: Manages manual failover of a master to a replica.migrate: Atomically transfers a key from one caching instance to another.role: Returns the role of the instance in the context of replication.slaveof: Makes the server a replica of another instance, or promotes it as master.acl: Manages caching access control lists.bgsave: Creates a snapshot of the data set into a dump file.config: Alters the configuration of a running caching server.lastsave: Returns the UNIX timestamp of the last successful save to disk.monitor: Streams back every command processed by the Caching server.replicaof: Makes the server a replica of another instance.save: Synchronously saves the dataset to disk.shutdown: Synchronously saves the dataset to disk and then shuts down the server.The following eval commands are also disabled:
eval: Executes a Lua script server-side.eval_ro: Read-only variant of the eval command.evalsha: Executes a script cached on the server side by its SHA1 digest.evalsha_ro: Read-only variant of the evalsha command.fcall: Calls a Caching function.fcall_ro: Read-only variant of the fcall command.function: Manages Caching functions.script: Manages the script cache.Choreo allows you to create PostgreSQL and MySQL databases as well as Choreo-Managed Cache instances on all major cloud providers (AWS, Azure, GCP, and DigitalOcean) as fully Choreo-managed platform services. These databases and caches can be seamlessly provisioned to offer persistence and caching capabilities for all your Choreo components. Choreo provides various service plans for each type, ranging from smaller instances for development purposes to production-grade databases with automatic backups and high-availability multi-nodes.
"},{"location":"manage-databases-and-caches/choreo-managed-databases-and-caches/#postgresql-on-choreo","title":"PostgreSQL on Choreo","text":"PostgreSQL (also known as Postgres), is an open-source object-relational database management system. You can create PostgreSQL databases on Choreo as fully Choreo-managed, flexible SQL databases that are ideal for both structured and unstructured data. If you want to perform an efficient vector similarity search, you can create a PostgreSQL vector database.
MySQL is a user-friendly, flexible, open-source relational database management system with a well-established history in the SQL database realm. Choreo allows you to swiftly create fully Choreo-managed MySQL databases, enabling rapid setup and utilization.
A fully-managed cache compatible with legacy Redis\u00ae OSS. A versatile, in-memory NoSQL database that serves as a cache, database, streaming engine, and message broker. Choreo-managed Cache allows you to have fully-managed instances that can be swiftly provisioned and integrated into your applications within minutes.
PostgreSQL, MySQL, and Redis\u00ae are trademarks and property of their respective owners. All product and service names used in this documentation are for identification purposes only.
"},{"location":"manage-databases-and-caches/choreo-managed-mysql-databases/","title":"Choreo-managed MySQL Databases","text":"MySQL on Choreo offers fully managed, flexible relational databases on AWS, Azure, GCP, and Digital Ocean.
"},{"location":"manage-databases-and-caches/choreo-managed-mysql-databases/#create-a-choreo-managed-mysql-database","title":"Create a Choreo-managed MySQL database","text":"Follow the steps below to create a Choreo-managed MySQL database:
To connect to your Choreo-managed MySQL database, consider the following guidelines:
The high availability characteristics and the automatic backup retention periods for Choreo-managed MySQL databases vary based on your service plan as explained below:
Service Plan High Availability Backup Retention Time Hobbyist Single-node with limited availability None Startup Single-node with limited availability 2 days Business Two-node (primary + standby) with higher availability 14 days Premium Three-node (primary + standby + standby) with highest availability 30 daysIn general, we recommend service plans for production scenarios for multiple reasons: - Provides another physical copy of the data in case of hardware, software, or network failures. - Typically reduces the data loss window in disaster scenarios. - Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running.
"},{"location":"manage-databases-and-caches/choreo-managed-mysql-databases/#automatic-backups","title":"Automatic Backups","text":"Choreo runs full backups daily to automatically back up Choreo-managed MySQL databases and record binary logs continuously. Choreo encrypts all backups at rest.
Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database.
The maximum number of simultaneous connections to MySQL databases is fixed for each service plan and depends on how much RAM your service plan offers.
Note
An extra_connection with a value of 1 is added for system processes for all MySQL databases, regardless of the service plan.
For plans under 4 GiB of RAM, the number of allowed connections is 75 per GiB:
max_connections = 75 x RAM + extra_connection\n"},{"location":"manage-databases-and-caches/choreo-managed-mysql-databases/#for-plans-with-over-4-gib-ram","title":"For plans with over 4 GiB RAM:","text":"For plans with 4 GiB or more RAM, the number of allowed connections is 100 per GiB:
max_connections = 100 x RAM + extra_connection\n"},{"location":"manage-databases-and-caches/choreo-managed-postgresql-databases/","title":"Choreo-Managed PostgreSQL Databases and Vector Databases","text":"PostgreSQL on Choreo offers fully Choreo-managed, efficient object-relational databases on AWS, Azure, GCP, and Digital Ocean. Additionally, Choreo allows you to create fully-managed PostgreSQL vector databases if you want to perform efficient vector similarity search.
"},{"location":"manage-databases-and-caches/choreo-managed-postgresql-databases/#create-a-choreo-managed-postgresql-database","title":"Create a Choreo-managed PostgreSQL database","text":"Follow the steps below to create a Choreo-managed PostgreSQL database:
Follow the steps below to create a Choreo-managed PostgreSQL vector database:
To connect to your Choreo-managed PostgreSQL database, consider the following guidelines:
The high availability characteristics and the automatic backup retention periods for Choreo-managed PostgreSQL databases vary based on the selected service plan as shown below.
Service Plan High Availability Backup Retention Time Hobbyist Single-node with limited availability None Startup Single-node with limited availability 2 days Business Two-node (primary + standby) with higher availability 14 days Premium Three-node (primary + standby + standby) with highest availability 30 daysService plans with standby nodes are generally recommended for production scenarios for multiple reasons: - Provides another physical copy of the data in case of hardware, software, or network failures. - Typically reduces the data loss window in disaster scenarios. - Provides a quicker time to restore with a controlled failover in case of failures, as the standby is already installed and running.
"},{"location":"manage-databases-and-caches/choreo-managed-postgresql-databases/#automatic-backups","title":"Automatic Backups","text":"Choreo runs full backups daily to automatically back up Choreo-managed PostgreSQL databases and copies the write-ahead logs (WAL) at 5-minute intervals or for every new file generated. Choreo encrypts all backups at rest.
Choreo automatically handles outages and software failures by replacing broken nodes with new ones that resume correctly from the point of failure. The impact of a failure will depend on the number of available standby nodes in the database.
Minor failures: Choreo automatically handles minor failures such as service process crashes or temporary loss of network access in all plans without requiring significant changes to the service deployment. Choreo automatically restores the service to normal operation once Choreo automatically restarts the crashed process or when Choreo restores the network access.
Severe failures: To handle severe failures such as losing a node entirely in case of hardware or severe software problems, requires more drastic recovery measures. The monitoring infrastructure automatically detects a failing node, both when the node starts reporting issues in the self-diagnostics or when it stops communicating. In such cases, the monitoring infrastructure automatically schedules a new replacement node to be created.
The following connection limits apply to Choreo-managed PostgreSQL databases based on the selected service plan.
Service Plan Max Connections Hobbyist 25 Startup/Business/Premium-4 100 Business-16 400 Premium-8 200"},{"location":"monitoring-and-insights/generate-custom-reports/","title":"Generate Custom Reports","text":"Choreo insights allow you to generate custom reports to view the information that is important to you to make timely decisions for the betterment of your business. With custom reports, you can generate reports for a set of metrics of your choice and aggregate results by specific fields. Once generated, the metrics can be filtered out using any selected group-by filters. Custom reports support three visualizations: overtime charts, pie charts, and tables.
"},{"location":"monitoring-and-insights/generate-custom-reports/#metrics","title":"Metrics","text":"Choreo Insights allow you to retrieve data for the following metrics:
Group-by fields specify how to group the metric data. e.g., You can select Successful Hit Count in the Metrics field and API Name under Group-by to retrieve the successful hit count grouped by the API name.
Choreo Insights allow you to group metric data by the following fields:
To generate a custom report, follow the steps below:
In the left navigation menu, click Custom Reports.
Select metric(s) from the Metrics drop-down selector.
Select a minimum of 1 and a maximum of 3 group-by field(s) from the Group By drop down selector.
Set the order of the group-by filters by drag and drop to determine the grouping order of the selected metric(s).
Once you determine the order of the group-by fields, you can set values for each group-by field from the respective dropdown.
Click Generate.
Choreo Insights allow you to download report data related to each chart as a PDF or a CSV file.
To do this, click the Download icon on the top right of the relevant chart and select the required file format.
"},{"location":"monitoring-and-insights/insights-overview/","title":"Insights Overview","text":"Choreo provides comprehensive insights into APIs created within both the on-premises API Manager and the Choreo platform. Choreo insights provide a range of metrics, including API traffic, error rates, and latency, allowing you to monitor and optimize API performance effectively.
With Choreo insights, you can:
By leveraging these insights, businesses can make informed decisions to enhance their API strategies and drive their digital transformation initiatives forward.
"},{"location":"monitoring-and-insights/insights-overview/#view-insights","title":"View insights","text":"To view usage insights, go to the Choreo Console and click Usage Insights in the left navigation menu.
If you are viewing insights on the Choreo platform at the organization level, note the following:
View Organization Insights permission under OBSERVABILITY-MANAGEMENT with the mapping level defined at the Organization level.View Organization Insights permission by default and can view organization-wide insights.By ensuring proper permissions are set, organizations can manage access to insights effectively while maintaining data security and relevance.
"},{"location":"monitoring-and-insights/insights-overview/#analyze-statistics","title":"Analyze statistics","text":"Once you access the Usage Insights page, you can access the following subpages.
"},{"location":"monitoring-and-insights/insights-overview/#overview","title":"Overview","text":"The Overview page gives you a quick overview of the system status.
The information displayed is as follows:
Total Traffic
This widget displays the total traffic of the selected environment received during a given time interval. Both successful requests and failed requests are displayed. To investigate further, you can click the arrow icon on the bottom right corner of the widget to open the Traffic page.
Error Request Count
This widget displays the total number of requests that have resulted in errors in your selected environment during the selected time range.
Average Error Rate
This widget displays the average error rate (i.e., error count/total request count) of the selected environment for a given time interval. You can use this widget as an indicator to understand the health of the system. If the error rate is high, you can investigate further by clicking the arrow on the bottom right of the widget and opening the Errors page.
95th Percentile Latency
This widget displays the 95th percentile of all API latencies in your selected environment for the given time interval. You can use this widget to know whether the complete system operates under given SLAs. This metric provides the first indication of slow APIs. To investigate further, you can click the arrow on the bottom right of the widget to open the Latency page where you can further analyze the latency.
API Request Summary
This chart displays the total successful requests, the total requests that have resulted in errors, and the latency in a timeline. The y-axis on the left displays the request count and the error count. The x-axis shows time, and the y-axis on the right shows the latency in milliseconds. The granularity of the data points is decided based on the time range you have selected. The tooltip provides the exact value of all three metrics accurately.
The Traffic page shows information related to the traffic that goes through your API management deployments. This includes API usage, application usage, resource usage, etc. You can use this page to investigate the usage of APIs and applications, traffic patterns, etc.
You can filter the information displayed in the widgets as follows:
Filtering Option Description By API In the API field, you can select one or more APIs for which you want to view analytics. All is selected by default. Once you select an API, you can further filter by a specific application that uses the selected API via the Application field described below. By Application In the Application field, you can select the applications for which you want to view analytics. All is selected by default. The available applications are all the applications that have subscribed to one or more of the APIs you selected in the API field.You can view the following information for the APIs you have selected using the above filtering criteria:
API Usage Over Time
This timeline shows the count of API hits for the APIs for the filtered APIs. If multiple APIs are selected, the timeline shows each API in a separate line with a legend separating each line. You can also zoom in on a selected time range by selecting that area in the chart. To restore to the original view use the Zoom out button on the top right-hand corner of the plot.
API Usage By Application
This widget shows the per-application breakdown of requests for the APIs you selected. You can use the pie chart view or the line chart view. You can switch between the two views using the small icon at the upper-right corner of the widget.
API Usage By Target
This widget shows the per-backend breakdown of requests for the APIs you selected. This information is useful when multiple APIs share the same backend that has traffic restrictions. You can use these stats to scale your backends proactively. You can switch between the two views using the small icon at the upper-right corner of the widget.
API Resource Usage
This table shows a resource-level breakdown of API traffic. Each row represents an API resource and it shows the API name, resource path, API method, and the hit count for that combination.
The Errors page shows information related to erroneous API calls that are received by your system. The errors are categorized based on the error type. You can further drill down using the error subtypes. Use this page as the starting point for debugging any API errors.
You can filter the information displayed in the widgets as follows:
Filtering Option Description By API In the API field, select the APIs for which you want to view analytics. By default, all APIs are selected. You can select one or multiple APIs from this selector and view the aggregated result. By Category The Category field is displayed when you click Category in the upper right corner of the page. In this field, you can select one or all of the following error categories:Authentication: Any kind of authentication error falls into this category including expired/missing/invalid credentials.Target Connectivity: Any kind of back-end error falls into this category including connection time-outs/other back-end errors (for example, 4xx and 5xx status codes).Throttling: Any request that fails due to rate-limiting falls into this category including application throttling/subscription throttling.Other: All other errors fall into this category including mediation errors/resource not found errors. By Status Code The Status Code field is displayed when you click Status Code in the upper right corner of the page. In this field, you can select all or any available HTTP status code categories (4xx, 5xx, etc.). These status codes represent the response status of the API Gateway. Viewing errors by categoryThe following widgets are available for monitoring errors when you have selected Category in the upper-right corner of the page.
This graph shows the error by category over time for the selected period. Apply the required filters as explained above to select the APIs and the error categories to which this content applies. When you select multiple APIs, the error count is grouped by category.
This table provides further information about the errors such as application details and the error reason. For some authentication errors, the application name is not available. You can use this table to get more concrete information about the errors related to your APIs and then start the problem identification.
The following widgets are available for monitoring errors when you select Status Code in the upper-right corner of the page.
Errors by Status Code
This graph shows the distribution of HTTP status codes received for errors over time for the selected period. Apply the required filters as explained above to select the APIs and status code groups to which this content applies. When you select multiple APIs, the error count is grouped by the status code.
Target Errors by Status Code
This graph shows the distribution of target errors that have occurred during the selected time interval by HTTP status code. Apply the required filters as explained in the table above to view the APIs and status code groups to which this content applies. If you select multiple APIs, the widget groups the target error count by the status code.
Errors
The Errors heat map shows the HTTP response codes of errors sent to the client by the API Gateway. Each row displays the number of times the system returned each status code for the selected APIs. The cell color is red for higher numbers and white for lower numbers. If required, you can further filter the results by the error code groups you identified with the Errors by Status Code graph.
Target Errors
The Target errors heat map shows the HTTP response codes of errors that the API Gateway received from the backend. Each row displays the number of times the system returned each status code for the selected APIs. The cell color is red for higher numbers and white for lower numbers. If required, you can further filter the results by the error code groups you identified with the Target Errors by Status Code graph.
The Latency page shows information related to the latency of API calls within the API management deployment. You can view a summary of the slowest APIs and then drill down into the API view for further analysis. Use this page as a starting point to debug API slowness.
The information displayed is as follows:
Top 10 Slowest APIs
This widget allows you to identify the slowest APIs of the API management system at a glance. Since these are the APIs that contribute to the higher 95th percentile of the system, improving these APIs lowers the 95th percentile of latency in the API Management deployments.
Latencies By Category
This widget allows you to further drill down details in the above chart. Use the API selector in this widget to select the slow API you identified in the earlier step and then analyze further. Use the charts available in the widget to view the 95th percentile and the median latency over the selected period of the following:
You can use these charts to further drill down and analyze whether the latency occurs in the backend, request mediation, or response mediation. Also, because you can see both the median and 95th percentile, you can easily identify whether the slowness is occurring in each request or whether it is intermittent.
"},{"location":"monitoring-and-insights/insights-overview/#cache","title":"Cache","text":"The Cache page shows statistics that indicate the efficiency with which response caching is carried out for the requests sent to your APIs.
The page displays the following statistics:
Cache Hit Percentage
This graph shows the percentage of requests the system has handled via the response cache over time and the total hits over time. This information allows you to assess how efficiently the backend handles API requests. For example, if the cache hit rate is low, it may indicate that the backend generates the same response each time a specific request is sent instead of returning the response via the cache. In such a scenario, there is scope to improve performance via response caching.
Latency
This section shows the total latency reported during the same time interval applied to the Cache Hit Percentage graph above.
The Devices page displays information about operating systems and HTTP agents that end users use to invoke the APIs. You can use this page to get an idea of the distribution of your user base and improve your APIs to match the audience.
To filter the information displayed on this page by API, select the required API(s) in the API field. All is selected by default.
The information displayed is as follows:
Top Platforms
This chart shows the breakdown of the API clients by the operating system. The pie chart only shows platforms with a significant amount of requests. Other platforms are grouped under the Other category.
Top User Agents
This chart shows the breakdown of the API clients by user-agent. The pie chart only shows user agents with a significant amount of requests. Other platforms are grouped under the Other category.
The Alerts page shows information related to business alerts issued by Choreo for your currently selected environment and organization. You can use this page as a health monitoring dashboard and make it visible to your project team. Using this page you can drill down on each alert and discover possible anomalies in your published APIs. See the topics given below to get details of the available widgets and understand how to use them effectively.
Prerequisites
To use this page, be sure to configure alerts and have API invocations that trigger alerts.
Note
Alerts are retained only for a week.
Alert Summary
This table lists each alert generated during the selected time interval. The message of the alert can be viewed by expanding the arrow icon on the details column. The drop-downs can be used to filter alerts based on the alert type and API.
Top APIs by Alert Count
This shows a pie chart and a table to visualize the alert distribution during the selected time interval.
The Reports page allows you to download monthly usage reports for your system. There are preconfigured reports with system-wide statistics, and a custom report generator to generate reports based on a subset of APIs/applications.
Download custom reportsThis widget allows you to generate a custom report for the statistics that have been generated up to now and download it.
To generate a custom report, follow the steps below:
In the API field, select one or more APIs for which you want to generate the report. If required, you can select all the APIs by selecting All.
If you need to further filter the content printed in the report, select one or more applications in the Application field. By default, all the applications that have subscribed to one or more of the selected APIs are selected.
Tip
If you want to filter the report content by the API consumer instead of the application, click on the toggle switch to the right of the Application field, and then select the required consumer. Only consumers who have subscribed to one or more of the selected APIs are displayed in the list. You can either select one or all of them.
Select the required year and the month in the Year and Month fields to specify the time interval for which you want to generate the report.
Click Download, and select the required format.
The report is downloaded in the specified format. The following is a sample report generated in PDF format.
The contents of the report are as follows.
Item Description Generated Time The date and the time the report was generated. Organization The organization to which the report applies. Each report always applies to a specific organization. Environment The environment to which the report applies. Each report always applies to a specific environment. Tenant The tenant to which the report applies. Each report always applies to a specific tenant. Reporting period The time interval for which the report is generated. Total request count The total request count received by all selected APIs during the report time interval.The table in the report contains the following rows.
Item Description API The name of the API. Application The name of the application. The name of the subscriber is also provided within brackets. Usage The usage count. Download pregenerated reportsThese widgets allow you to download monthly reports for the last three months.
To download a pregenerated report, click Download for the relevant month and then click on the required format.
"},{"location":"monitoring-and-insights/insights-overview/#geo-map","title":"Geo Map","text":"The Geo Map page allows you to see a geographical representation of your API usage. You can use this page to make business decisions such as identifying growing regions, analyzing the impact of a region-specific marketing campaign, etc.
To filter the information displayed on this page by API, select the required API(s) in the API field. The default value is All.
This heat map highlights the countries with the appropriate color based on the hit count. It uses a relative color scale to depict the highest hit count to the lowest non-zero hit count.
Viewing the number of requests by countryYou can hold the pointer over the highlighted countries to view the country name and the total number of hits from that location. You can also use the mouse to zoom the map or pan it. Optionally, you can download geo-map data in a tabular format using the PDF or CSV download options by clicking on the top right corner.
Note
x-forwarded-for header to each request to preserve the source IP address. If you do not configure this correctly, the Geo Map page will not show any data. To test this, you can manually add an x-forwarded-for header to the request.Moesif is an API analytics and monetization service that helps you grow your API products. You can integrate Choreo with Moesif and gain valuable insights into your API's usage. While Moesif's API analytics capabilities empower you to make informed decision-making on behalf of your organization, its monetization options simplify revenue generation from your APIs, eliminating the need for complex coding.
In this guide, you will:
Let's generate an API key in Moesif. If you're an existing Moesif user with a registered organization, proceed to step 1.2.
"},{"location":"monitoring-and-insights/integrate-choreo-with-moesif/#step-11-generate-a-key-in-moesif-as-a-new-user","title":"Step 1.1: Generate a key in Moesif as a new user","text":"If you are a new user, follow the steps below to register an organization and generate a key:
On the Get Started page, enter meaningful values for the fields and create a new organization.
Field Description Organization Name The name of your company or team. Application Name The name of your application that represents one project or environment.Click Next.
On the Overview page, click Next.
This opens the Quick Install page. As there is no data, you cannot proceed. Let's configure Moesif to receive data from Choreo.
Select a WSO2 Choreo as the Server Integration
Copy the Application Id.
If you are an existing user with a registered organization, or you do not have an API key for the organization you created, follow the steps below to access the generated API key:
Let's configure Choreo to publish events to Moesif.
Once you successfully add the key, you will see a delete option next to it. Currently, you can only configure one API key. If you need to add a new API key, you need to delete the existing key and add the new one.
Note
Once you configure the Moesif API key on Choreo, wait for five minutes before you publish any data to the Moesif API analytics platform.
"},{"location":"monitoring-and-insights/integrate-choreo-with-moesif/#step-3-invoke-an-api-and-observe-the-data-on-the-moesif-dashboard","title":"Step 3: Invoke an API and observe the data on the Moesif Dashboard","text":"You have configured Choreo to publish data to Moesif. Let's see how you can view the insights on Moesif.
Tip
Invoke your API by following the Test REST Endpoints via the OpenAPI Console guide.
Once you publish data, your Moesif dashboard will receive events. Once Moesif receives events, you will see a notification on Moesif confirming that it received data.
Click Next on the notification. This will take you to the final step, where you can opt to add team members. In this guide, let's skip this step.
You can now view your API's insights in the Moesif dashboard.
"},{"location":"monitoring-and-insights/observability-overview/","title":"Observability Overview","text":"The Choreo observability dashboard provides a comprehensive interface to visualize and monitor the performance of services deployed on Choreo.
The Observability dashboard allows you to:
Tip
If you are a Choreo private data plane customer and you want to observe your private data plane using New Relic, see Observing Choreo Private Data Planes With New Relic.
"},{"location":"monitoring-and-insights/observability-overview/#throughput-and-latency-graphs","title":"Throughput and latency graphs","text":"The throughput graph depicts the throughput of requests per second for a selected timestamp.
By default, Choreo renders this graph for the data generated within the past 24 hours. You can change the default time window by selecting the time range and zone from the options bar. To expand the graph, click and drag the cursor over the period you want to drill down.
You can view the Choreo service logs in the Logs pane below the throughput and latency graph. Clicking on a graph updates the Logs view to contain the corresponding log entries generated at that time. You can use these logs to identify the reasons for any latency and throughput anomalies you detect using the graph.
"},{"location":"monitoring-and-insights/observability-overview/#diagnostics-view","title":"Diagnostics view","text":"The Diagnostics view allows you to simultaneously analyze errors, throughput, latencies, CPU usage, memory usage, and logs for a particular event. This facilitates detailed error detection and analysis.
By default, the time range selected for the Throughput & Latency graphs is the same time range used for the Diagnostics view.
Each horizontal section of the graph, termed a bin, represents a specific period and comprises:
The Logs pane serves as a centralized view to observe logs of the components you deploy on Choreo. This facilitates rigorous troubleshooting and analysis.
"},{"location":"monitoring-and-insights/view-logs/","title":"View Logs","text":"The unified log view in Choreo allows you to view runtime and audit logs to gain application and user insights while ensuring data privacy.
Choreo provides real-time insights through live logs and allows you to view historical logs for insights into the past. You also have the flexibility to define a required time range to view relevant log entries, where an intuitive scrolling capability facilitates easy viewing of appropriate logs within the selected time frame.
The log view also provides advanced filtering capabilities that allow you to efficiently navigate through appropriate logs to expedite troubleshooting in distributed environments.
Note
All personally identifiable information (PII) gets resolved at the frontend service level, with only relevant UUIDs stored in logs.
"},{"location":"monitoring-and-insights/view-logs/#runtime-logs","title":"Runtime logs","text":"Choreo runtime logs provide insights into both project and component-level logs, covering application and gateway logs. These logs streamline the debugging process by centralizing diverse log sources.
In Choreo, any organization member can view runtime logs via the runtime logs page. Choreo allows you to apply filters based on parameters such as log level (error, warn, info, debug), log type (application, gateway), and environment (development, staging, production) to simplify the debugging process.
To access runtime logs, follow the steps below:
In the left navigation menu, click Observability and then click Runtime Logs. This displays runtime logs for the past 30 days by default.
To view logs based on a specific time range and other requirements, you can apply the necessary filter criteria.
When you view component-level logs on the Runtime Logs page, you will see both application and gateway logs.
Application logsEach application log entry displays the following details:
timestamp: The time when the request is received by the component.level: Indicates the severity of the log message. Possible values are Debug, Info, Warn, and Error.componentVersion: The version of the invoked component.componentVersionId: The identifier of the invoked component\u2019s version.envName: The environment of the inbound request. For example, Development, Production, etc.Each gateway log entry displays the following details:
timestamp: The time when the request is received by the gateway component.logLine: Contains the following details about the request, including inbound and outbound information from the gateway perspective.Method: The HTTP method of the request.RequestPath: The path of the inbound request.ServicePath: The path of the outbound request.UserAgent: The user-agent header of the request.CorrelationID: The request identifier of the inbound request. This is useful to track a request.ServiceHost: The host IP of the backend.Duration: The time taken for the gateway to serve the request.\u00a0\u00a0gatewayCode: Indicates the state of the request from the gateway perspective. Possible values are as follows:
BACKEND_RESPONSE: Indicates successful processing of the request by the gateway with a response to the client from the backend application.CORS_RESPONSE: Denotes a CORS (Cross Origin Resource Sharing) request.AUTH_FAILURE: Indicates a request failure at the gateway due to authentication or authorization issues, such as an invalid token.NO_HEALTHY_BACKEND: Indicates a request failure at the gateway due to a non-existent backend.RATE_LIMITED: Indicates a request failure at the gateway due to surpassing the rate limit enforced within the component.RESOURCE_NOT_FOUND: Indicates a request failure at the gateway due to the absence of a matching API resource for the inbound request. This can be caused by a mismatch in the HTTP method, path, or host.BACKEND_TIMEOUT: Indicates a request timeout when calling the backend application from the gateway.GATEWAY_ERROR: Indicates a request failure due to an erroneous behavior in the gateway.Note
Occasionally, a request may not fit into any of the above categories. In such instances, the gatewayCode is displayed as UNKNOWN.
statusCode: The HTTP status code returned to the client.
componentVersion: The version of the invoked component.envName: The environment of the inbound request. For example, Development, Production, etc.Audit logs, also called audit trails, enhance security, ensure compliance, provide operational insights, and help manage risks.
In Choreo, an audit log records organization-level user-specific operations performed via the Choreo Console. It also captures the timestamp and the outcome of the action.
As of now, Choreo captures the following user-specific operations as audit logs:
In Choreo, organization administrators are allowed to view audit logs by default. If other members need to access organization-specific audit logs, the administrator can create a role with the relevant permission and assign it to members. For step-by-step instructions on how to create and assign a role with relevant permission, see Manage audit log access.
To view audit logs, follow these steps:
In the Choreo Console, go to the top navigation menu and click Organization.
Tip
As of now, you can only view organization-level audit logs.
In the left navigation menu, click DevOps and then click Audit Logs. This displays audit logs for the past 30 days by default.
To view audit logs based on a specific time range and other requirements, you can apply the necessary filter criteria.
Choreo retains audit logs for one year and archives them for an additional year. Therefore, the total retention period for audit logs is two years.
"},{"location":"monitoring-and-insights/view-logs/#manage-audit-log-access","title":"Manage audit log access","text":"Follow the steps given below to create a role with audit log access permission and assign it to organization members who need access to audit logs:
Note
You must be the organization administrator to perform this action.
Step 1: Create a role with audit log access permissionEnter a name and description for the role.
Click Next.
In the Create Role dialog, select LOG-MANAGEMENT under Permissions.
Click Create.
Click on a member who needs to have access to audit logs, and then click + Add Role.
Tip
If you want to invite one or more members and assign them the audit log viewer role, follow the steps given below:
Click to expand the Roles list and select the role you created in Step 1.
This section explains how you can configure alerts for your API manager deployments. Setting up alerts allows you to proactively monitor your API ecosystem and take corrective measures when necessary.
You can configure alerts for each environment within your organization. You can add, modify, or delete alerts per API. Optionally, you can specify a list of emails for each alert configuration.
Alerts are subject to a suppression policy to prevent duplicate notifications within a specific time frame. By default, a 10-minute suppression window is applied, and this is not configurable. The suppression policy is specific to each alert configuration.
Info
Alerts can be categorized as either latency alerts or traffic alerts.
"},{"location":"monitoring-and-insights/alerts/configure-alerts/#latency-alerts","title":"Latency alerts","text":"Latency alerts notify you if the response latency of an API exceeds a predefined threshold. This is useful for APIs that need to meet specific SLAs and for proactively identifying slow APIs.
To configure a new latency alert, follow the steps given below:
Click Alert Configuration.
This opens the Alert Configuration pane with the Latency tab open by default.
In the API Name field, select the API for which you want to configure the alert.
Info
Only the APIs that you have invoked at least once are listed here. For other APIs, you need to give the API name in the required format as instructed in the UI.
In the Metric field, select the required metric against which you want to evaluate the alert configuration.
Tip
The list includes all available options. If there are multiple metrics, you can select the required metric. If there is only one metric to choose, that metric is selected by default, and the field is disabled.
In the Latency field, specify the threshold in milliseconds.
Info
When the 95th percentile of the selected metric exceeds the threshold provided here, alerts are triggered.
In the Emails field, specify the list of emails that should be notified when the alert is added.
Click + Add.
Once an alert is successfully added, the alert configuration is listed in the Alert Configuration pane. Each configuration can be edited and removed via this pane.
"},{"location":"monitoring-and-insights/alerts/configure-alerts/#traffic-alerts","title":"Traffic alerts","text":"Traffic alerts notify you when the request count of an API exceeds a predefined threshold. This is useful for managing APIs with backend traffic limits or monetized backends that require proactive scaling based on incoming traffic.
To configure a new traffic alert, follow the steps below:
In the API Name field, select the API for which you want to configure the alert.
Info
Only the APIs that you have invoked at least once are listed here. For other APIs, you need to give the API name in the required format as instructed in the UI.
In the Metric field, select the required metric against which you want to evaluate the alert configuration.
Tip
The list includes all available options. If there are multiple metrics, you can select the required metric. If there is only one metric to choose, that metric is selected by default, and the field is disabled.
In the Threshold field, specify the threshold number of requests per minute.
If required, specify the list of emails that should be notified when the alert is generated in the Emails field.
Click Add.
Once an alert is successfully added, the alert configuration is listed in the Alert Configuration pane. Each configuration can be edited and removed via this pane.
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/","title":"Configure CIO Dashboard","text":"You can view DORA metrics in Choreo to use as KPIs to measure your organization's DevOps team's performance. Choreo enables this feature by default for all organizations. DORA includes the following four key metrics that are regarded as the most important metrics to indicate team performance:
Choreo enables two DORA metrics by default; deployment frequency and lead time for change.
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#configure-the-cio-dashboard-with-all-metrics","title":"Configure the CIO Dashboard with all metrics","text":"To configure the CIO dashboard by enabling the other two metrics, follow the steps below:
To configure GitHub as the incident management system, follow the steps below:
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#step-1-authorize","title":"Step 1: Authorize","text":"First, let's authorize Choreo to access the repositories used to record incidents.
On the Add Integration page, select GitHub and click Authorize with GitHub.
Once the authorization process is complete, you can start configuring the GitHub repository.
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#step-2-configure","title":"Step 2: Configure","text":"By default, Choreo collects incident details(issues) from all repositories containing Choreo components. However, you can configure a GitHub account and a GitHub repository to allow Choreo to read issues from a specific repository, and then click Next.
Field Description Value Data Plane Choreo collects incident details by running a scheduled job which invokes the GitHub API periodically. This job runs on the user's data plane. This configuration allows users to specify a preferred data plane to run the job, especially when they have multiple data planes. Select a preferred data plane from the Data Plane list. GitHub Account The GitHub account you have your repositories in. Select your GitHub account that includes the repository used for incident collection. GitHub Repository By default, Choreo will collect incident details(issues) from all repositories that already have Choreo components."},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#step-3-filter-label","title":"Step 3: Filter label","text":"The filter label allows Choreo to scrape issues associated with that label.
Incident Label: The label Choreo uses to identify incidents. For example, Type/Incident.
Invalid incident label(Optional): Choreo will not scrape issues with this label and will proceed to skip these issues. For example, Resolution/Invalid. You can use this label when you want to ignore issues. For example, closing an issue after identifying that it doesn't qualify as an incident issue as it was due to a user error.
Once you configure the labels, click Save.
Choreo will enable incident data publishing in the background once you save. Once completed, DORA metric charts will appear in the CIO dashboard for Mean Time To Recover and Change Failure Rate. If there are any issues in the configuration, the configure banner will reappear, and the user can proceed to reconfigure.
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#step-4-enrich-incident-tickets-with-deployment-information","title":"Step 4: Enrich incident tickets with deployment information","text":"Choreo extracts deployment information from the relevant incident and generates DORA metrics that help you analyze the deployment statistics related to the incidents. Therefore, you must manually update the GitHub issue with the relevant deployment-related information. Follow the steps below to add the deployment information to the GitHub issue.
Get deployment detailsOn the right-hand side panel, select the relevant deployment, and click Release details to copy the deployment details to the clipboard.
Get deployment details) at the end of the issue body.That's it! You have successfully configured your CIO dashboard to include the DORA metrics.
Note
The CIO Dashboard is expected to reflect the latest statistics within approximately 30 minutes.
"},{"location":"monitoring-and-insights/delivery-insights/configure-dora-metrics/#edit-configurations","title":"Edit configurations","text":"You can edit or override the configurations you made via the edit option in the dashboard.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/","title":"View DORA metrics","text":"DORA metrics comprise four key metrics. Let's explore what each metric represents in Choreo. Choreo displays a summary and graphical representation of each metric.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#snapshot-view","title":"Snapshot view","text":"The snapshot view includes four tiles on the top of the dashboard, summarizing DORA metrics for the entire time period you select. The snapshot view categorizes each metric into four performance levels: elite, high, medium, and low. The categorization is based on the 2020 DORA metric report.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#time-series-view","title":"Time series view","text":"The time series view provides a graphical representation of how the statistics have changed over a period of time. You can use this view to analyze team performance and identify trends.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#deployment-frequency","title":"Deployment frequency","text":"DORA team definition: The frequency at which an organization successfully releases to production.
In Choreo, this translates to the number of times an organization deploys a component to the production environment. Choreo does not count the deployment done to the development or other lower environments.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#snapshot-view_1","title":"Snapshot view","text":"The snapshot view of the Deployment Frequency metric shows the deployment frequency for all components within the selected organization. The frequency is dynamically determined and rounded to the nearest measurement. For example, if there is more than one deployment daily, the deployment frequency is measured in deployments per day. If the deployment frequency is less, it is measured in a higher granularity. For example, deployments per week.
A lower deployment frequency indicates that your organizational efficiency is low and that you need to evaluate and improve the processes to encourage frequent releases.
Choreo also displays the total number of deployments for the selected time range and the percentage increase or decrease compared to the previous time range.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#time-series-view_1","title":"Time series view","text":"The time series view for the Deployment Frequency metric visualizes the deployment count as a bar chart for the selected time period. Deployment count is aggregated based on the \u2018view by\u2019 selector. Hovering over each bar shows the counts for the aggregated period. Using this chart, organizations can identify deployment patterns, such as days of the week/months of the year where more deployments are likely to happen (near quarterly release days) and periods with fewer deployments. Decision-makers can then take steps to investigate and improve performance. This chart displays the pattern before and after a process change so you can use it to evaluate the team's performance after a significant process change.
DORA team definition: The time it takes for a commit to reach production.
In Choreo, this translates into the time between committing and promoting a deployment to production. Although this approach may overlook any commits you push to production between two commits, it effectively assesses the efficiency of the review, approval, and CI/CD processes. Therefore, focusing on the production commits is adequate. If a team commits locally for extended periods without deploying to production, this gets reflected in the Deployment Frequency charts.
The snapshot view of this metric displays the 95th percentile of the lead time for the selected time period. 95th percentile serves as a better representation as it filters out large outliers that can taint the average value. Lower lead times for change suggest that your organization has efficient processes for change review, approval, and CI/CD, while longer times suggest that the process needs to improve. Organizations can also use the categorization label to determine their standpoint on global standards.
Additionally, Choreo also displays the percentage increase or decrease compared to the last time period.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#time-series-view_2","title":"Time series view","text":"The time series view of this metric visualizes the lead time as a bar chart for the selected time period. The time is summed based on the \u2018view by\u2019 selector. To handle outliers, the y-axis employs a log scale that represents values read dynamically. Hovering over each bar displays the actual counts for the aggregated period. Using this chart, organizations can identify trends in their release process. For example, organizations can identify the time of the year when lead time rises, such as summer break. Also, organizations can use this to benchmark and evaluate new process changes. For example, if you introduced a process to include peer programming and reviewing, this chart can be used to evaluate its effect on the lead time and provide leadership with factual information to proceed further.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#change-failure-rate","title":"Change failure rate","text":"The DORA team definition: The percentage of deployments causing a failure in production.
In Choreo, this translates to the ratio of deployments causing production failures to the total number of deployments. If there is at least one incident reported against a deployment, Choreo considers that deployment as a failed deployment in production. Any deployment-time failures are not counted as production failures because such failures don't impact the end user. For this metric to be accurate, the organization is expected to open incidents adhering to the proper format as it is crucial for Choreo to identify production failures.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#snapshot-view_3","title":"Snapshot view","text":"The snapshot view of this metric visualizes the change failure rate as a percentage for the selected time period. This will be the absolute percentage for the entire time period. When deciding on the time, the time of deployment is considered instead of the incident reported time. For example, the change failure rate for January 2023 will reflect the following: - All deployments that happened within January. - Any incidents that were reported at any time (in or after January) against the January deployments.
This view helps leadership assess the quality of deliverables and identify areas for improvement. Higher rates suggest that the organization needs to improve its processes to bring in more quality assurance aspects such as improved code coverage and end-to-end test coverage.
Additionally, Choreo also shows the percentage increase or decrease compared to the previous time period.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#time-series-view_3","title":"Time series view","text":"The time series view of this metric displays it as a line chart with data points corresponding to the granularity selected by the \u2018view by\u2019 selector. The absolute percentage is shown for each granularity. Hovering over the line chart displays the actual counts for the aggregated period. This chart helps leadership identify timely trends in product quality aspects. For example, this view displays the months of the year where the failure rate is high (for example, close to quarterly release/announcement dates). Also, you can use this to measure the effectiveness of changes introduced to improve quality. For example, if the organization introduced an end-to-end test pipeline integration to the PR approval process, they can use this view to factually observe the timely impact of that change and determine how it decreases the failure rate.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#mean-time-to-recovermttr","title":"Mean Time to Recover(MTTR)","text":"The DORA team definition: The time it takes for an organization to recover from a production failure.
In Choreo, this measures the time from identifying a production incident to resolving it. This metric reflects the responsiveness and agility of incident management teams.
Choreo depends on the open and close times of incidents to gather the relevant information. Therefore, for the dashboards to be accurate, organizations must follow process guidelines to update and close incident tickets efficiently in their incident management system.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#snapshot-view_4","title":"Snapshot view","text":"The snapshot view for this metric displays the mean recovery time for the selected time period. Choreo dynamically adjusts the time unit to measure this metric for better readability. This chart helps organizations evaluate the response time and agility of their incident handling teams, which in turn is an indication of stability. Higher MTTR means the leadership should look at new ways of improving the efficiency and agility of the teams handling incidents.
"},{"location":"monitoring-and-insights/delivery-insights/view-dora-metrics/#time-series-view_4","title":"Time series view","text":"The time series view of this metric shows how the mean time to recovery changes over time on a granularity based on the \u2018view by\u2019 selector. Each time the granularity mean would be used as the aggregation factor. Hovering over the line chart displays the actual counts for the aggregated period. This view helps leadership understand timely trends on mean time to recovery, such as higher values during holiday periods when there is less staff. Also, you can use this measurement to evaluate the effectiveness of process changes such as introducing an incident response plan. The trend view clearly shows the before and after statistics and the effectiveness of the process change.
Choreo offers the capability to access runtime logs through its console. However, in cases where viewing logs for your PDP is not supported by Choreo yet, you can still view the runtime logs of your components via the log analyzing solution provided by your cloud vendor as a workaround.
"},{"location":"monitoring-and-insights/logs/view-pdp-logs/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, complete the following:
Release ID and the Namespace. Save it for later.You can view your PDP logs with Azure Log Analytics by following the steps below:
<START_TIME_STAMP EX: 2023-04-10T07:07:31.684Z> and <END_TIME_STAMP EX: 2023-04-21T07:27:31.684Z> values as required. Replace the '' and '' with the values you copied by following the steps in the prerequisites section. Replace the <OPTIONAL SEARCH PHRASE> with your search term, or leave it blank if you don't require any search filtering. let startDateTime = datetime('<START_TIME_STAMP EX: 2023-04-10T07:07:31.684Z>');\nlet endDateTime = datetime('<END_TIME_STAMP EX: 2023-04-21T07:27:31.684Z>');\nlet releaseId = '<RELEASE_ID>';\nlet namespace = '<NAMESPACE>';\nlet searchPhrase = '<OPTIONAL SEARCH PHRASE>';\nlet startDateTimeKPI = iff(datetime_diff('second', endDateTime, startDateTime) > 60, startDateTime, endDateTime - 2m);let endDateTimeKPI = iff(datetime_diff('second', endDateTime, startDateTime) > 60, endDateTime, startDateTime + 2m);let filteredLogLevels = dynamic([]);\nlet hasNoLevelFilter = array_length(filteredLogLevels) == 0;\nlet commonKeys = dynamic(['time', 'level', 'module', 'traceId', 'spanId', 'message']);\nlet ContainerIdList = KubePodInventory\n| where TimeGenerated > startDateTimeKPI and TimeGenerated < endDateTimeKPI\n| where Namespace == namespace\n| where extractjson('$.[0].release_id', PodLabel) == releaseId\n| distinct ContainerID;\nlet data = ContainerLog\n| where TimeGenerated > startDateTime and TimeGenerated < endDateTime\n| where ContainerID in (ContainerIdList)\n| where searchPhrase == \"\" or LogEntry contains searchPhrase\n| top 126 by TimeGenerated desc\n| extend logs = parse_json(LogEntry)\n| project TimeGenerated, LogLevel = iif(isempty(logs['level']), iff(LogEntrySource == 'stderr', 'ERROR', 'INFO'), logs['level']), LogEntry = iif(isempty(logs['message']), logs, logs['message']),\nKeyValuePair = bag_remove_keys(logs, commonKeys)\n| where hasNoLevelFilter or LogLevel in (filteredLogLevels);\nlet lastTimeStamp = data | top 1 by TimeGenerated asc | project TimeGenerated;\nlet trimmedData = data | where TimeGenerated > toscalar(lastTimeStamp)| sort by TimeGenerated desc;\nlet selected = iff(toscalar(data | count) == 126, 'trimmedData', 'data');\nlet choose = (selector:string){ union (trimmedData | where selector == 'trimmedData'), (data | where selector == 'data')};\nchoose(selected);\n"},{"location":"monitoring-and-insights/logs/view-pdp-logs/#view-private-data-plane-pdp-logs-with-amazon-cloudwatch","title":"View Private Data Plane (PDP) logs with Amazon CloudWatch","text":"<RELEASE_ID> with the values you copied by following the steps in the prerequisites section. Replace the <OPTIONAL SEARCH PHRASE> with your search term, or leave it blank if you don't require any search filtering.fields @timestamp, @message\n| filter kubernetes.labels.release_id == \"<RELEASE_ID>\"\n| filter @message like \"<OPTIONAL SEARCH PHRASE>\"\n"},{"location":"monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api/","title":"Access the Choreo Insights API","text":"The Usage Insights page in the Choreo Console displays data retrieved from the Insights API exposed over the Internet. However, in some scenarios, you may need to retrieve data from external systems and implement custom dashboards to display the data.
Choreo provides a secure and user-friendly approach to accomplish this requirement. Follow the steps given below:
"},{"location":"monitoring-and-insights/work-with-choreo-insights-api/access-the-choreo-insights-api/#become-a-member-of-the-choreo-system-organization","title":"Become a member of the Choreo System organization","text":"Access the Developer Portal of the Choreo System organization via https://devportal.choreo.dev/choreosystem/applications and sign in using your preferred method.
To obtain access to the Choreo System organization, click Request Access.
To create an application and generate keys, follow the steps below:
To create a new application in the Choreo System organization, click + Create Application.
Enter a name for the application and click Create. This creates the application and takes you to the Overview page.
To subscribe to the Insights API via the newly created application, follow the steps below:
Insights and click Add.To generate credentials for the application, follow the steps given below:
To specify an appropriate token expiry time for the application, follow the steps given below:
Specify an appropriate value in the Application access token expiry time field and click Update.
Execute the following cURL command to generate an access token:
curl --location --request POST 'https://sts.choreo.dev/oauth2/token' \\\n--header 'Authorization: Basic <BASE64_ENCODED_CONSUMER_KEY_AND_CONSUMER_SECRET_OF_YOUR_APP_HERE>' \\\n--header 'Content-Type: application/x-www-form-urlencoded' \\\n--data-urlencode 'grant_type=client_credentials' \\\n--data-urlencode 'orgHandle=<YOUR_ORG_HANDLE_HERE>' \\\n--data-urlencode 'scope=apim:api_manage'\n Info
To obtain your organization handle, follow the steps given below:
You can use the generated token to access the Insights API exposed via https://choreocontrolplane.choreo.dev/93tu/insights/1.0.0/query-api.
The following is a sample cURL command to invoke the Insights API:
curl --location --request POST 'https://choreocontrolplane.choreo.dev/93tu/insights/1.0.0/query-api' \\\n--header 'Content-Type: application/json' \\\n--header 'Authorization: Bearer <TOKEN_HERE>' \\\n--data-raw '{\"query\":\"query ($org: OrgFilter!) {listEnvironments(org: $org){id\\n name}}\",\"variables\":{\"org\":{\"orgId\":\"<ORG_UUID_HERE>\"}}}'\n Tip
The Choreo Insights API is a GraphQL API that allows you to retrieve data from external systems based on specific criteria. This guide describes the operations and schema-defined types you can use to retrieve data via the Choreo Insights API.
You can try out the Choreo Insights API with your data via GraphQL Explorer.
Warning
The GraphQL Explorer is currently not compatible with the Safari web browser due to a known issue.
"},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#query","title":"Query","text":"The query root of the Choreo Insights GraphQL API.
Field Argument Type Description listAllAPI [API] Fetches all the APIs with the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure theprovider parameter to further filter the APIs by a specific provider. provider String The name of the API provider. dataFilter DataFilter! The data filter. listApplications [Application] Fetches all the applications with the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the applicationFilter parameter to further filter the applications by a specific application filter. applicationFilter ApplicationFilter The application filter. dataFilter DataFilter! The data filter. listProviders [Provider] Fetches all the API providers with the given combination of tenant ID, environment ID, and organization ID. dataFilter DataFilter! The data filter. listSubscribers [Subscriber] Fetches all the API subscribers with the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the subscriberFilter parameter to further filter the subscribers. subscriberFilter SubscriberFilter The subscriber filter. dataFilter DataFilter! The data filter. listOrganizations [Organization] Fetches all the organizations of a user. listEnvironments [Environment] Fetches all the environments of an organization. org OrgFilter! The organization filter. projectId String The project ID by which the results need to be filtered. It is optional to specify a value for this parameter. Note that providing a project ID with an on-prem key is not allowed. listTenants [String] Fetches all the tenants with the given combination of environment ID and organization ID. tenantDataFilter TenantDataFilter! The tenant filter. getTotalTraffic Int Returns the total traffic during the given time range for the specified combination of tenant ID, environment ID, and organization ID. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. getTotalErrors Int Returns the total number of errors that occurred during the given time range for the specified combination of tenant ID, environment ID, and organization ID. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. getOverallLatency Float Returns the overall response latency (95th percentile value) during the given time range for the specified combination of tenant ID, environment ID, and organization ID. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. getLatencySummary LatencySummary Returns the response latency value (95th percentile value) for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the latencySummaryFilter parameter to further filter the results. filter TimeFilter! The time filter. latencySummaryFilter LatencySummaryFilter The latency summary filter. dataFilter DataFilter! The data filter. getSuccessSummary SuccessSummary Returns the number of successful (2xx response code) hit count for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the granularity parameter to override the default granularity value. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. granularity String The granularity value. getErrorSummary ErrorSummary Returns the number of unsuccessful hits (i.e., the total of both 4xx and 5xx response codes) for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the granularity parameter to override the default granularity value. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. granularity String The granularity value. getErrorsByCategory ErrorsByCategory Returns the number of proxy errors (i.e., the total of both 4xx and 5xx response codes) by each error category for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the errorsByCategoryFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. errorsByCategoryFilter ErrorsByCategoryFilter The errors by category filter. dataFilter DataFilter! The data filter. getErrorsDetails DetailsOfErrors Returns details of each proxy error (for both 4xx and 5xx response codes) within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the errorsDetailsFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. errorsDetailsFilter ErrorsDetailsFilter The error details filter. dataFilter DataFilter! The data filter. getProxyTargetErrorsOverTime [ErrorsByStatusCodeCategory] Returns a list of hit counts for proxy and target errors for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. The errors in each proxy and target result set are grouped as 4xx, 5xx, and total. Optionally, you can configure the errorsByStatusCodeFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. errorsByStatusCodeFilter ErrorsByStatusCodeFilter The errors by status code filter. dataFilter DataFilter! The data filter. getErrorsByStatusCode ErrorsByStatusCode Returns the hit count for each error response code (401, 404, and 500 etc.,) for each API within the specified time range for the given combination of tenant ID, environment ID, and organization ID. timeFilter TimeFilter! The time filter. errorCountByStatusCodeFilter ErrorCountByStatusCodeFilter! The error count by status code filter. dataFilter DataFilter! The data filter. getTotalErrorsByAPI TotalError Returns the total proxy error hit count for an API across for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the filter parameter to further filter the results by a given time range. filter TimeFilter The time filter. dataFilter DataFilter! The data filter. apiId ID! The API ID. getAPIUsageOverTime [APIUsageOverTime] Returns a list of details related to the usage of each API over time for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the apiUsageOvertimeFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. apiUsageOvertimeFilter APIUsageOverTimeFilter The API usage overtime filter. dataFilter DataFilter! The data filter. getAPIUsageByAppOverTime APIUsageByAppOverTime Returns API usage by each application over time for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the apiUsageOvertimeFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. apiUsageOvertimeFilter APIUsageOverTimeFilter The API usage overtime filter. dataFilter DataFilter! The data filter. getAPIUsageByBackendOverTime APIUsageByBackendOverTime Returns API usage by each backend over time for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the apiUsageByBackendOverTimeFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. apiUsageByBackendOverTimeFilter APIUsageByBackendOverTimeFilter The API usage by backend overtime filter. dataFilter DataFilter! The data filter. getResourceUsage ResourceUsages Returns API usage by resource within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the resourceUsageFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. resourceUsageFilter ResourceUsageFilter The resource usage filter. dataFilter DataFilter! The data filter. getTotalTrafficByAPI Int Returns the total hit count for an API for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the filter parameter to further filter the results by a given time range. filter TimeFilter The time filter. dataFilter DataFilter! The data filter. apiId ID! The API ID. topSlowestAPIs [SlowAPI] Returns a list of top slowest APIs based on the response latency (95th percentile value) within the specified time range for the given combination of tenant ID, environment ID, and organization ID. filter TimeFilter! The time filter. dataFilter DataFilter! The data filter. limit Int! The limit for the slow APIs list. getLatency APILatency Returns different latency category values (95th percentile values) for a given API over time for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. timeFilter TimeFilter! The time filter. latencyFilter LatencyFilter! The latency filter. dataFilter DataFilter! The data filter. getOverallLatencyByAPI OverallLatency Returns the overall response latency (95th percentile value) for an API for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the filter parameter to further filter the results by a given time range. filter TimeFilter The time filter. dataFilter DataFilter! The data filter. apiId ID! The API ID. getCacheHitsAndMisses CacheHits Return the total number of response cache hits, misses, and hit percentage for an API over time for each time granularity within the specified time range for the given combination of tenant ID, environment ID, and organization ID. timeFilter TimeFilter! The time filter. cacheFilter CacheFilter The cache filter. dataFilter DataFilter! The data filter. getTopPlatforms [Platform] Returns a list of top platforms ranked based on the hit count within the specified time range for the given combination of tenant ID, environment ID, and organization ID. The result list includes the top nine platforms with the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit count. Optionally, you can configure the deviceFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. deviceFilter DeviceFilter The device filter. dataFilter DataFilter! The data filter. getTopUserAgents [UserAgent] Returns a list of top user agents ranked based on the hit count within the specified time range for the given combination of tenant ID, environment ID, and organization ID. The result list includes the top nine user agents with the respective hit count, and all the rest of the platforms are labeled as **Other** with the cumulated hit count. Optionally, you can configure the deviceFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. deviceFilter DeviceFilter The device filter. dataFilter DataFilter! The data filter. getAPIUsageByGeoLocation [UsageByGeoLocation] NOTE: Currently, this operation returns data only for on-premise environments. Returns API usage by country within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the geoLocationFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. geoLocationFilter GeoLocationFilter The geolocation filter. dataFilter DataFilter! The data filter. getAPIsUsageByApplications [APIUsageByApplication] Returns details relating to the usage of each API by application within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the apiUsageByAppFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. apiUsageByAppFilter APIUsageByAppFilter The API usage by app filter. dataFilter DataFilter! The data filter. getTopAPIsByAlertCount TopAPIsByAlertCount Returns top APIs ranked based on the alert count within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the topAPIsByAlertCountFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. topAPIsByAlertCountFilter TopAPIsByAlertCountFilter The top APIs by alert count filter. dataFilter DataFilter! The data filter. getAlertSummary AlertSummaries Returns a summary for each alert within the specified time range for the given combination of tenant ID, environment ID, and organization ID. Optionally, you can configure the alertSummaryFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. alertSummaryFilter AlertSummaryFilter The alert summary filter. dataFilter DataFilter! The data filter. getSuccessAPIsUsageByApplications [SuccessAPIUsageByApplication] NOTE: This operation can only be invoked via using an on-prem key as the authentication header. Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API, grouped by each application. Optionally, you can configure the successAPIUsageByAppFilter parameter to further filter the results. timeFilter TimeFilter! The time filter. successAPIUsageByAppFilter SuccessAPIUsageByAppFilter The successful API usage by application filter. getSuccessAPIsUsageByApplicationsWithOnPremKey [SuccessAPIUsageByApplication] Returns a list of successful hit counts (i.e., 2xx response codes) within the specified time range for each API, grouped by each application. Optionally, you can configure the successAPIUsageByAppFilter parameter to further filter the results. onPremKey String! The value of the On-Prem key. timeFilter TimeFilter! The time filter. successAPIUsageByAppFilter SuccessAPIUsageByAppFilter The successful API usage by application filter. getCustomReportOvertime CustomReportOvertime Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans. dataFilter DataFilter! The data filter. timeFilter TimeFilter! The time filter. metric Metric! The metric for which data needs to be retrieved. groupByFields [GroupByField]! The column/field by which data needs to be retrieved. groupByValues [String]! The value used to filter by the groupByField. granularity String! The granularity value for which data is retrieved. getCustomReportTopOvertime CustomReportTopOvertime Returns the summary of hits or latency data as specified for the selected time duration, grouped by time spans for the top N values for the selected groupByField. dataFilter DataFilter! The data filter. timeFilter TimeFilter! The time filter. metric Metric! The metric for which data needs to be retrieved. groupByFields [GroupByField]! The column/field by which the data should be grouped. groupByValues [String]! The value used to filter by the groupByField. granularity String! The granularity value for which data is retrieved. getGroupByValues [[String]] Returns a list of value sets by which you can group the data available for the selected groupBy fields. dataFilter DataFilter! The data filter. groupByFields [GroupByField]! The column/field for which the API needs to retrieve distinct values. groupByValues [String]! The value used to filter by the groupByField."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#objects","title":"Objects","text":""},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#api","title":"API","text":"Represents API details.
Field Argument Type Description id ID! The ID of the API. name String! The API name. version String! The API version. provider String! The API provider name."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apilatency","title":"APILatency","text":"Represents latency values for a single API over time.
Field Argument Type Description summary [Latency] A list containing latency category values over time. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusage","title":"APIUsage","text":"Represents the API usage for a single timestamp. The timestamp is calculated based on the granularity value provided.
Field Argument Type Description timeSpan String! Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' count Int! The API usage count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebyapp","title":"APIUsageByApp","text":"Represents API usage across APIs by a single application.
Field Argument Type Description applicationId ID! The application ID. applicationName String! The application name. applicationOwner String! The name of the application owner. usage [APIUsage] A list containing the APIs usage values. Returns an empty array if no data is available."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebyappovertime","title":"APIUsageByAppOverTime","text":"Represents API usage across APIs by applications over time.
Field Argument Type Description usage [APIUsageByApp] A list containing the API usage values across APIs, grouped by the application. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebyapplication","title":"APIUsageByApplication","text":"Represents a single API usage by a single application.
Field Argument Type Description apiId String! The ID of the API. applicationId String! The Application ID. applicationName String! The application name. applicationOwner String! The name of the application owner. count Int! The usage of the API by the application."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebybackend","title":"APIUsageByBackend","text":"Represents API usage across APIs by a single backend.
Field Argument Type Description backend String! The name of the backend. usage [APIUsage] A list containing the APIs usage values. Returns an empty array if no data is available."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebybackendovertime","title":"APIUsageByBackendOverTime","text":"Represents API usage across APIs by each backend over time.
Field Argument Type Description usage [APIUsageByBackend] A list containing the API usage values across APIs by each backend. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusageovertime","title":"APIUsageOverTime","text":"Represents a single API usage over time.
Field Argument Type Description apiId ID The ID of the API. usage [APIUsage] A list containing the API usage values. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#alertsummaries","title":"AlertSummaries","text":"Represents alert summaries.
Field Argument Type Description usage [AlertSummary] A list containing the alert summary for each alert. Returns an empty array if no data is available. pagination Pagination! The pagination details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#alertsummary","title":"AlertSummary","text":"Represents a summary for an alert.
Field Argument Type Description apiId ID! The ID of the API. timestamp String! Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' category String! The alert category. Possible values are LATENCY and TRAFFIC. metric String! The alert metric. Possible values are RESPONSE_LATENCY and TOTAL_TRAFFIC. severity String! The severity level of the alert. Possible values are LOW, MEDIUM, and HIGH. message String! The alert details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#application","title":"Application","text":"Represents application details.
Field Argument Type Description id ID! The Application ID. name String! The application name. owner String! The name of the application owner."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#cachehit","title":"CacheHit","text":"Represents the response cache hits and misses for a single timestamp. The timestamp is calculated based on the granularity value provided.
Field Argument Type Description timeSpan String! Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' hits Int! The number of times the response cache was hit. misses Int! The number of times the response cache was missed. hitPercentage Float! The response cache hits as a percentage of the sum of hits and misses."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#cachehits","title":"CacheHits","text":"Represents the response cache hits and misses over time.
Field Argument Type Description summary [CacheHit] A list containing cache hits, misses, and the hit percentage over time. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#customreportgroupby","title":"CustomReportGroupBy","text":"Represents the usage data overtime for the selected parameters of a specific groupByValue.
Represents usage data overtime for the selected parameters.
Field Argument Type Description usage [CustomReportUsage] A list containing the usage values. This returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#customreporttopovertime","title":"CustomReportTopOvertime","text":"Represents usage data overtime for the selected parameters grouped by the top N groupByValues.
groupByField. This returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#customreportusage","title":"CustomReportUsage","text":"Represents usage data for a single timestamp in CustomReports.
1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' value Int! The usage value (Hit Count/ Latency)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#detailsoferrors","title":"DetailsOfErrors","text":"Represents error details over time.
Field Argument Type Description usage [ErrorDetails]! A list containing error details over time. Returns an empty array if no data is available. pagination Pagination! The pagination details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#environment","title":"Environment","text":"Represents an environment.
Field Argument Type Description id String! The environment ID. externalEnvId String! The external environment ID. internalEnvId String The internal environment ID. sandboxEnvId String The sandbox environment ID. name String! The environment name. type EnvironmentType! The environment type. A Choreo environment is labeled asCHOREO, a private Choreo environment is labeled as CHOREO_PRIVATE, and the on-premise environment is labeled as ON_PREM."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorcountbycategory","title":"ErrorCountByCategory","text":"Represents the number of errors from each category for a single timestamp. The timestamp is calculated according to the provided granularity value. If you select some categories, the error counts are retrieved only for those categories, and a null value is shown for the other categories that are not selected.
1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' auth Int The count of authorization errors. targetConnectivity Int The count of target connectivity errors. throttled Int The count of throttling errors. other Int The count of other errors."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorcountbycode","title":"ErrorCountByCode","text":"Represents the error count for a single error status code.
Field Argument Type Description statusCode String! The error status code. count Int! The error count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorcountbycodeforapi","title":"ErrorCountByCodeForAPI","text":"Represents the error count for each status code for a single API.
Field Argument Type Description apiId ID! The ID of the API. errorCountByCode [ErrorCountByCode] A list containing the error count for each error status code. Returns an empty array if no data is available."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errordetails","title":"ErrorDetails","text":"Represents details of an error for a single timestamp. The timestamp is calculated according to the granularity value provided.
Field Argument Type Description apiId ID The ID of the API. timeSpan String! Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' applicationId String The Application ID. applicationName String The application name. applicationOwner String The name of the application owner. reason String! The reason for the error. count Int! The error count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorstatuscodecategorycounts","title":"ErrorStatusCodeCategoryCounts","text":"Represents errors by the main status code (4xx or 5xx) and the total error count.
Provides the unsuccessful usage (i.e., 4xx and 5xx response codes) summary across all APIs.
Represents the unsuccessful request count (i.e., 4xx and 5xx response codes) for a single timestamp. The timestamp is calculated based on the granularity value provided.
1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' errorCount Int Represents the error request count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsbycategory","title":"ErrorsByCategory","text":"Represents the errors by category over time.
Field Argument Type Description errors [ErrorCountByCategory] A list containing the error count for each error category over time. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsbystatuscode","title":"ErrorsByStatusCode","text":"Represents the error counts grouped by status code for each API.
Field Argument Type Description errors [ErrorCountByCodeForAPI]! A list containing the error count for each status code for each API. Returns an empty array if no data is available. pagination Pagination! Pagination details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsbystatuscodecategory","title":"ErrorsByStatusCodeCategory","text":"Represents the error category values (grouped as 4xx, 5xx, and total) for both proxy and target errors for a single timestamp. The timestamp is calculated based on the granularity value provided.
1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' proxy ErrorStatusCodeCategoryCounts Represents proxy-related errors categorized as client errors (4xx response codes) or server errors (5xx response codes), and the total of both categories. target ErrorStatusCodeCategoryCounts Represents target-related errors categorized as client errors (4xx response codes) or server errors (5xx response codes), and the total of both categories."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#latency","title":"Latency","text":"Represents latency values for each latency category for a single timestamp. The timestamp is calculated based on the granularity value provided.
Field Argument Type Description timeSpan String Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' response Int The response latency (95th percentile) in milliseconds (ms). backend Int The backend latency (95th percentile) in milliseconds (ms). requestMediation Int The request mediation latency (95th percentile) in milliseconds (ms). responseMediation Int The response mediation latency (95th percentile) in milliseconds (ms). responseMedian Int The median (50th percentile) of the response latency in milliseconds (ms). backendMedian Int The median (50th percentile) of the backend latency in milliseconds (ms). requestMediationMedian Int The median (50th percentile) of the request mediation latency in milliseconds (ms). responseMediationMedian Int The median (50th percentile) of the response mediation latency in milliseconds (ms)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#latencysummary","title":"LatencySummary","text":"Provides the latency summary.
Field Argument Type Description summary [LatencyValue]! A list containing latency values. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#latencyvalue","title":"LatencyValue","text":"Represents the latency value for a single timestamp. The timestamp is calculated according to the provided granularity value.
Field Argument Type Description timeSpan String! Represents a timestamp value that is calculated based on the specified granularity value. For example, if the granularity value is1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' latencyTime Float! Represents the latency (95th percentile) time in milliseconds (ms)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#organization","title":"Organization","text":"Represents an organization.
Field Argument Type Description id String! The organization ID. uuid ID! The organization UUID. handle String! The organization handle name. name String! The organization name."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#overalllatency","title":"OverallLatency","text":"Represents the overall latency values.
Field Argument Type Description response Float The response latency (95th percentile value) in milliseconds (ms)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#pagination","title":"Pagination","text":"Represents pagination details.
Field Argument Type Description total Int! The total number of results. limit Int! The number of items in the result set. offset Int! The offset value for the result set. sortBy String! The sorting column name of the result set. sortOrder String! The sorting order of the result set. Possible values areasc and desc."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#platform","title":"Platform","text":"Represents a platform.
Field Argument Type Description platform String! The name of the platform. count Int! The usage of the platform."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#provider","title":"Provider","text":"Represents API Provider details.
Field Argument Type Description name String! The API provider name."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#resourceusage","title":"ResourceUsage","text":"Represents the usage of a single API resource.
Field Argument Type Description apiId ID! The ID of the API. apiResourceTemplate String! The API resource template. apiMethod String! The API method. count Int! The usage of the API resource."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#resourceusages","title":"ResourceUsages","text":"Represents API resource usages.
Field Argument Type Description usage [ResourceUsage] A list with the usage of each API resource. Returns an empty array if no data is available. pagination Pagination! Pagination details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#slowapi","title":"SlowAPI","text":"A slow API identified based on the response latency (95th percentile).
Field Argument Type Description apiId ID! The ID of the API. latency Int! Represents the latency (95th percentile) time in milliseconds (ms)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#subscriber","title":"Subscriber","text":"Represents API Subscriber details.
Field Argument Type Description name String! The name of the API subscriber."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#successapiusagebyapplication","title":"SuccessAPIUsageByApplication","text":"Represents successful usages(that have resulted in the 2xx response code) of an API by an application.
Provides the successful (2xx response code) usage summary across all the APIs.
Field Argument Type Description summary [SuccessValue]! A list containing successful usage values. Returns an empty array if no data is available. granularity String! The granularity value for which data is retrieved."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#successvalue","title":"SuccessValue","text":"Represents the successful request count (i.e., requests that have received the 2xx response code) for a single timestamp. The timestamp is calculated according to the granularity value provided.
1d, the timestamp represents the start of the day calculated adhering to the timezone provided in the time filter. e.g., timeSpan: '2021-06-21T00:00:00.0000000+05:30' requestCount Int! Represents the successful request count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#topapibyalertcount","title":"TopAPIByAlertCount","text":"Represents a top API by alert count.
Field Argument Type Description apiId ID! The ID of the API. count Int! The alert count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#topapisbyalertcount","title":"TopAPIsByAlertCount","text":"Represents the top APIs by alert count.
Field Argument Type Description usage [TopAPIByAlertCount] A list containing top APIs by alert count. Returns an empty array if no data is available. pagination Pagination! The pagination details."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#totalerror","title":"TotalError","text":"Represents the total errors.
Field Argument Type Description proxy Int The proxy-related error count."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#usagebygeolocation","title":"UsageByGeoLocation","text":"Represents the usage of a single API in a single country.
Field Argument Type Description country String! The name of the country. count Int! The usage of the API."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#useragent","title":"UserAgent","text":"Represents a user agent.
Field Argument Type Description userAgent String! The name of the user agent. count Int! The usage of the user agent."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#inputs","title":"Inputs","text":""},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebyappfilter","title":"APIUsageByAppFilter","text":"Filters the API usage by application results.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined. appIds [String] The results are filtered for the list of applications you specify here. A maximum of five application IDs can be defined. subscribers [String] The results are filtered for the list of subscribers you specify here. A maximum of five subscriber IDs can be defined."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusagebybackendovertimefilter","title":"APIUsageByBackendOverTimeFilter","text":"Filters the results for API usage by backend over time.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#apiusageovertimefilter","title":"APIUsageOverTimeFilter","text":"Filters the results for API usage over time.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined. appIds [String] The results are filtered for the list of applications you specify here. A maximum of five application IDs can be defined. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#alertsummaryfilter","title":"AlertSummaryFilter","text":"Filters the alerts summary results.
Field Type Description paginationFilter PaginationFilter The pagination filter. searchFilter SearchFilter The search filter. apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined. category String The alert category by which the results need to be filtered. The available categories to select areTRAFFIC and LATENCY."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#applicationfilter","title":"ApplicationFilter","text":"Filters applications by the application owner and API IDs.
Field Type Description owner String apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#cachefilter","title":"CacheFilter","text":"Filters response cache results.
Field Type Description apiId String The results are filtered by the API ID specified here. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#datafilter","title":"DataFilter","text":"Filters results by the given combination of organization, environment, and tenant.
Field Type Description orgId String! The organization by which the results need to be filtered. It is required to specify a value for this parameter. environmentId String The environment ID by which the results need to be filtered. It is required to specify a value for this parameter. environmentIds [String] The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter. tenant String! The name of the tenant by which the results need to be filtered. It is required to specify a value for this parameter. projectId String The project ID by which the results need to be filtered. It is optional to specify a value for this parameter. Note that providing a project ID with an on-prem key is not allowed."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#devicefilter","title":"DeviceFilter","text":"Filters results related to devices.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorcountbystatuscodefilter","title":"ErrorCountByStatusCodeFilter","text":"Filters errors by status code results.
Field Type Description apiId String The results are filtered by the API ID specified here. errorType ErrorType! The type of the error. It is required to specify a value for this parameter. errorCodeType ErrorCodeType The error code type. If this parameter is not configured, both client-related error response codes (401, 404, etc.) and server-related response codes (500, 501, etc.) are included in the result set. paginationFilter PaginationFilter The pagination filter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsbycategoryfilter","title":"ErrorsByCategoryFilter","text":"Filters errors by category results.
Field Type Description apiId String The ID of the API. categories [String] The list of categories by which the results need to be filtered. Category values that you can specify here areAUTH, TARGET_CONNECTIVITY, THROTTLED, and OTHER. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are 1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsbystatuscodefilter","title":"ErrorsByStatusCodeFilter","text":"Filters errors by status code results.
Field Type Description apiId String The results are filtered by the API ID specified here. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorsdetailsfilter","title":"ErrorsDetailsFilter","text":"Filters the results for error details.
Field Type Description apiId String The results are filtered by the API ID specified here. appId String The application ID by which the results need to be filtered. category String The error category by which the results need to be filtered. The error category that you can specify here must be one of theAUTH TARGET_CONNECTIVITY, THROTTLED, and OTHER values. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are 1m, 15m, 1h, 1d, and 7d. paginationFilter PaginationFilter The pagination filter. searchFilter SearchFilter The search filter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#geolocationfilter","title":"GeoLocationFilter","text":"Filters the API usage by geolocation results.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#latencyfilter","title":"LatencyFilter","text":"Filters latency results.
Field Type Description apiId String! The results are filtered by the API ID specified here. It is required to specify a value for this parameter. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#latencysummaryfilter","title":"LatencySummaryFilter","text":"Filters latency summary results.
Field Type Description apiId String The results are filtered by the API ID specified here. granularity String The granularity value that is used for data retrieval. If the granularity value is not set, the default granularity for the related time range is applied. The possible granularity values that you can specify are1m, 15m, 1h, 1d, and 7d."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#orgfilter","title":"OrgFilter","text":"Filters results for the given organization.
Field Type Description orgId String! The ID of the organization by which the results need to be filtered. It is required to specify a value for this parameter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#paginationfilter","title":"PaginationFilter","text":"Filters related to pagination.
Field Type Description limit Int The total number of rows in the result set. This value must be a positive integer. If this limit value is not set, the total number of rows is five by default. offset Int The offset value to set when filtering results. This value must be zero or a positive integer. If you do not specify an offset value, the default offset value (i.e.,0) applies. sortBy String The column name by which the results are sorted. If the sortBy value is not set, the default column of the related operation that is available for sorting purposes is used. sortOrder String The order in which the results are sorted. Possible values are asc (to sort in ascending order) and desc (to sort in descending order). If no value is specified, the results are sorted in ascending order by default (except for count-specific operations such as getTopAPIsByAlertCount where the results are always sorted in descending order)."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#resourceusagefilter","title":"ResourceUsageFilter","text":"Filters resource usage results.
Field Type Description paginationFilter PaginationFilter The pagination filter. searchFilter SearchFilter The search filter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#searchfilter","title":"SearchFilter","text":"Filters results by searching matching results for the provided search text.
Field Type Description apiIds [String] The list of API IDs that need to be searched with the given search text. Note that it is not possible to define API IDs without a search text in the search filter. searchText String! Text which needs to be searched among the results. It is required to specify a value for this parameter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#subscriberfilter","title":"SubscriberFilter","text":"Filters the subscriber results.
Field Type Description apiIds [String] The results are filtered for the list of APIs you specify here. A maximum of five API IDs can be defined."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#successapiusagebyappfilter","title":"SuccessAPIUsageByAppFilter","text":"Filters successful API usage by application results.
Field Type Description apiIds [String] The list of API IDs by which the results need to be filtered. tenantDomains [String] The tenant domain name by which the results need to be filtered."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#tenantdatafilter","title":"TenantDataFilter","text":"Filters results by the tenant.
Field Type Description orgId String! The ID of the organization by which the results need to be filtered. It is required to specify a value for this parameter. envId String The ID of the environment by which the results need to be filtered. It is required to specify a value for this parameter. environmentIds [String] The environment IDs by which the results need to be filtered. It is required to specify a value for this parameter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#timefilter","title":"TimeFilter","text":"Filters results by the provided date range.
Field Type Description from String! The start date of the time range. The date specified here must be a date earlier than the date specified via theto parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is required to specify a value for this parameter. e.g., '2021-08-16T12:00:00.000+05:30'. to String! The end date of the time range. The date specified here must be a date later than the date specified via the from parameter. If the defined date and time entry do not have a timezone, the UTC time zone (z) is used. It is required to specify a value for this parameter. e.g., '2021-08-16T12:30:00.000+05:30'."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#topapisbyalertcountfilter","title":"TopAPIsByAlertCountFilter","text":"Filters the top APIs by alert count results.
Field Type Description paginationFilter PaginationFilter The pagination filter. searchFilter SearchFilter The search filter."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#enums","title":"Enums","text":""},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#environmenttype","title":"EnvironmentType","text":"Represents an error type.
Value Description CHOREO The Choreo environments. CHOREO_PRIVATE The private data-plane Choreo environments. ON_PREM The On-Premise environments."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errorcodetype","title":"ErrorCodeType","text":"Represents an error code type.
Value Description _4XX The client-side errors. _5XX The server-side errors."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#errortype","title":"ErrorType","text":"Represents an error type.
Value Description PROXY The proxy-related errors. TARGET The target-related errors."},{"location":"monitoring-and-insights/work-with-choreo-insights-api/choreo-insights-api/#groupbyfield","title":"GroupByField","text":"Represents an groupByField used in CustomReports.
Represents a metric used in CustomReports.
The Boolean scalar type represents true or false.
The Float scalar type represents signed double-precision fractional values as specified by IEEE 754.
The ID scalar type represents a unique identifier, often used to re-fetch an object or as the key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as \"4\") or integer (such as 4) input value is accepted as an ID.
The Int scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.
The String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
Choreo is an Internal Developer Platform (IDevP) that streamlines the entire process of building, deploying, monitoring, and managing your cloud-native applications easily.
In this quick start guide, you will explore how to expose a service endpoint via Choreo and securely consume the service from a web application. You will use a simple reading list web application with a sign-in page and functionality to interact with a secure backend service. You will also use Choreo's managed authentication to easily set up authentication for your web application without having to dive into the details of security protocols. The application will allow users to sign in and view their reading lists, add books to a reading list, delete books from the reading list, and sign out of the application effortlessly.
This guide walks you through the following steps:
Before you try out this guide, complete the following:
Create a GitHub repository to save the service implementation. For this guide, you can fork the Choreo sample book list app repository.
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the organization home page.
Follow the steps given below to create a project:
Enter a display name, unique name, and description for the project. You can enter the values given below:
Tip
In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project.
Field Value Project Display NameSample project Name sample-project Project Description My sample project Click Create. This creates the project and opens the project home page.
To connect to the repository you forked in the prerequisites and configure the sample service, follow the steps given below:
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo sample book list app repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Value Organization Your GitHub account Repository choreo-sample-book-list-app Branchmain In the Add Component Directories pane under Configure Components, click the + icon corresponding to reading-list-service.
In the Component Configuration dialog that opens, specify values as follows for each of the fields:
Field Value Component Display Name Reading List Service Component Name reading-list-service Path reading-list-service Component Type Service Buildpack NodeJS Language Version 20.x.xClick Save. This adds the Reading List Service component to the Configured Components pane.
Click Finish. This initializes the service with the implementation from your GitHub repository and takes you to the project home page.
You can see the Reading List Service component listed under Component Listing on the project home page.
To build the service, follow the steps given below:
Reading List Service component listed under Component Listing. This takes you to the component overview page.!!! note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
"},{"location":"quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service/#step-4-deploy-the-service","title":"Step 4: Deploy the service","text":"For the REST endpoint of the service to be invokable, you need to deploy it. To deploy the service, follow the steps given below:
To test the endpoint via the integrated OpenAPI Console in Choreo, follow the steps given below:
Update the request body so that the parameters have the values given below:
Parameter Value author Bram Stoker status to_read title DraculaThe request body should look as follows:
{\n\"author\": \"Bram Stoker\",\n\"status\": \"to_read\",\n\"title\": \"Dracula\"\n}\n 9. Click Execute. Check the Server Response section. On successful invocation, you will receive the 201 HTTP code.
Similarly, you can expand and try out the GET and DELETE methods.
"},{"location":"quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service/#step-6-consume-the-service","title":"Step 6: Consume the service","text":"Now that the Reading List Service is deployed and available in the Choreo Marketplace, application developers can discover the service via the Marketplace and consume it.
In this section of the guide, you will deploy a sample front-end application to consume the service. This application will serve as the interface for users to interact with the reading list. The sample application used in this guide is designed to personalize the book lists based on the user ID that it obtains from its identity provider.
To host the front-end application in Choreo, you will create a web application component, set up authentication for it, and deploy it. To establish a connection between your web application and the deployed service, you will create a Connection.
"},{"location":"quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service/#step-61-create-a-web-application-to-consume-the-service","title":"Step 6.1: Create a web application to consume the service","text":"To create a web application component, follow the steps given below:
Enter a display name, unique name, and a description to create the web application. You can enter the values given below:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display Name Reading List Web App Component Name reading-list-web-app Description Front-end application for the reading list serviceGo to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo sample Book List Service repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repository choreo-sample-book-list-app Branch mainSelect React as the buildpack because the sample front-end application is a React application built with Vite.
Enter the following information:
Field Value Project Directory /choreo-sample-book-list-app/reading-list-front-end-with-managed-auth Build Command npm install && npm run build Build Path dist Node Version 18Click Create. This initializes the component with the implementation from your GitHub repository and takes you to the Overview page of the component.
A connection allows you to integrate the service you intend to deploy on Choreo with other services on Choreo or external resources. For more information on Choreo Connections refer to the Connection documentation.
To establish a connection between the web application you created and the deployed service, follow the steps given below:
Reading List Service.`Specify values as follows for each of the fields:
Field Value Name Reading List Connection Description Connection to the reading listClick Create. This creates the connection and displays the service URL of the connection for each environment the service is deployed in. In this guide, you will see the service URL for the Development environment. You can copy the service URL to use when you configure the web application before deploying it.
To build the web application, follow the steps given below:
!!! note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
"},{"location":"quick-start-guides/deploy-a-web-application-that-consumes-a-backend-service/#step-64-configure-and-deploy-the-web-application","title":"Step 6.4: Configure and deploy the web application","text":"In this step, you will configure managed authentication, create a user to access the web application, and then deploy the web application. For more information on Choreo's managed authentication capability, see the Managed Authentication documentation.
To configure managed authentication, follow the steps given below:
Specify the following in the config.js file mount.
You must replace <Service URL> with the value that you copied when creating a connection to the Reading List Service in step 6.2.
window.configs = {\napiUrl: '<Service URL>',\n};\n Tip
You can refer to the configuration file mounted at /app/public as ./public/config.js within your web application.
Click Next. This opens the Authentication pane.
Under Authentication Settings, make sure that you have the Managed authentication with Choreo toggle enabled.
Tip
Managed authentication is enabled by default when you create a web application using React, Angular, or Vue.js buildpacks.
Specify values as follows for each of the fields:
Field Value Post Login Path / Post Logout Path / Error Path /Next, you can create a user to access the web application.
To create a user to access the readingListApp application, follow the steps given below:
To proceed with creating a user with the populated username and password, click Create. Make sure you copy the populated username and password to use when you test the front-end application.
Tip
Now, you can deploy the web application.
To deploy the web application and obtain the URL to access it, follow the steps given below:
To test the front-end application and send requests to the Reading List Service via it, follow the steps given below:
Click Login, and sign in with the credentials of the user that you created.
The application opens as follows.
Add three new reading items with different statuses.
For example, the details can be as follows:
Title Author Status The Museum of Innocence Orhan Pamuk reading The Remains of the Day Kazuo Ishiguro to_read David Copperfield Charles Dickens readTo add each record, follow the steps given below:
Three tabs open for each status. To delete a reading list item, you can click Delete.
To verify whether the reading list is personalized for each user, you can sign in as a different user. The reading list items you entered above will not appear for the other user.
Congratulations! You have successfully exposed a service endpoint via Choreo and securely consumed it from a web application.
After you have successfully tested your service and web application, you can now try out various other Choreo features such as managing, observing, DevOps, etc., similar to any other component type within Choreo.
"},{"location":"quick-start-guides/deploy-your-first-service/","title":"Deploy Your First Service","text":"Choreo, an Internal Developer Platform (IDevP), simplifies the deployment, monitoring, and management of your cloud-native services, allowing you to focus on innovation and implementation.
Choreo allows you to easily deploy services you've created in your preferred programming language in just a few steps.
In this guide, you will:
Nodejs buildpack. It runs on port 8080.For a video tutorial that walks you through these steps, see Deploy Your First Service with Choreo.
"},{"location":"quick-start-guides/deploy-your-first-service/#prerequisites","title":"Prerequisites","text":"You must have a GitHub account with a repository that contains your service implementation. To proceed with the steps in this guide, you can fork the Choreo sample book list service repository, which contains the sample for this guide.
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the organization home page.
Let's familiarize ourselves with the key files in this sample application. The below table gives a brief overview of the important files in the sample book list service.
Note
The following file paths are relative to the path <choreo-sample-book-list-service>/.
Let's get started!
"},{"location":"quick-start-guides/deploy-your-first-service/#step-1-create-a-project","title":"Step 1: Create a project","text":"Follow the steps given below to create a project:
Enter a display name, unique name, and description for the project. You can enter the values given below:
Info
In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project.
Field Value Project Display Name Book List Project Name book-list-project Project Description My sample projectClick Create. This creates the project and takes you to the project home page.
Let's create a service component by following these steps:
Enter a unique name and a description for the service. For this guide, let's enter the following values:
Field Value Component Display Name Book List Description Gets the book listGo to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo sample Book List Service repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Description Organization Your GitHub account Repository choreo-sample-book-list-service Branch mainSelect the NodeJS buildpack.
Enter the following information.
Field Description NodeJS Project Directory / Language Version 20.x.xClick Create.
You have successfully created a Service component with the NodeJS buildpack. Now let's build and deploy the service.
"},{"location":"quick-start-guides/deploy-your-first-service/#step-3-build-and-deploy","title":"Step 3: Build and deploy","text":"Now that the source repository is connected and Choreo has set up the endpoints based on the repository's configuration, it's time to proceed with building the service. Choreo will create a Docker image in the build process. You can then deploy the built Docker image and test the book list service.
"},{"location":"quick-start-guides/deploy-your-first-service/#step-31-build","title":"Step 3.1: Build","text":"To build the service, follow these steps:
Book List component listed under Component Listing. This takes you to the component overview page.!!! note Building the service component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
"},{"location":"quick-start-guides/deploy-your-first-service/#step-32-deploy","title":"Step 3.2: Deploy","text":"Now you are ready to deploy the service. Follow these steps:
Review the Endpoint Details and click Deploy.
Note
Deploying the service component may take a while. You can track the progress by observing the logs. Once the deployment is complete, the build status changes to Active on the Development environment card.
To test the Book List service via the integrated OpenAPI Console in Choreo, follow the steps given below:
Similarly, you can expand and try out the other methods.
After you have successfully tested your service, you can now try out various other Choreo features such as managing, observing, DevOps, etc., similar to any other component type within Choreo.
"},{"location":"quick-start-guides/deploy-your-first-static-web-application/","title":"Deploy Your First Static Web Application","text":"Choreo is an internal developer platform as a service that takes care of the complexities of building platforms, allowing application developers to focus on innovation and implementation. Choreo streamlines the entire process of building, deploying, monitoring, and managing your cloud-native applications.
In this quick start guide, you will explore how easy it is to deploy a web application using Choreo. Here, you will use a simple web application designed to add tasks to a to-do list.
This guide walks you through the following steps:
For a video tutorial that walks you through these steps, see Deploy a Static Web App on Choreo.
"},{"location":"quick-start-guides/deploy-your-first-static-web-application/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the organization home page.
Follow the steps given below to create a project:
Enter a display name, unique name, and description for the project. You can enter the values given below:
Tip
In the Name field, you must specify a name to uniquely identify your project in various contexts. The value is editable only at the time you create the project. You cannot change the name after you create the project.
Field Value Project Display NameSample project Name sample-project Project Description My sample project Click Create. This creates the project and opens the project home page.
To create a Web Application component, follow the steps given below:
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the choreo-sample-todo-list-app repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Enter the following information:
Field Value Organization Your GitHub account Repository choreo-sample-todo-list-app Branchmain Select NodeJS as the Buildpack
Enter the following information:
Field Value NodeJS Project Directory / Language Version 20.x.x Port8080 Click Create. Choreo initializes the component with the sample implementation and opens the Overview page of the component.
Now let's build and deploy the web application.
"},{"location":"quick-start-guides/deploy-your-first-static-web-application/#step-3-build-your-web-application","title":"Step 3: Build your web application","text":"To build the web application, follow the steps given below:
In the Builds pane, click Build Latest.
Note
Building the component may take a while. You can track the progress via the logs in the Build Details pane. Once the build process is complete, the build status changes to Success.
Now you can proceed to deploy your web application.
"},{"location":"quick-start-guides/deploy-your-first-static-web-application/#step-4-deploy-and-access-your-web-application","title":"Step 4: Deploy and access your web application","text":"After you have successfully tested your web application, you can now try out various other Choreo features such as observability, DevOps, etc., similar to any other component type within Choreo.
"},{"location":"references/choreo-limitations/","title":"Choreo Limitations","text":"Explore key limitations in Choreo, covering areas like HTTP request parameters, components, applications, and API definition files. You can gain insights into the limitations to enhance your understanding and optimize your use of Choreo effectively.
"},{"location":"references/choreo-limitations/#api-management-limits","title":"API management limits","text":"Below are key limitations when working with APIs in Choreo:
Resource Limit Maximum request payload 10 MB URL size 2 KB Request headerBelow are key limitations when working with web applications in the Choreo cloud data plane:
Resource Limit Request size limit (including headers, cookies, and payloads) 256 KB Response body size limit 20 MB Number of open ports permitted per web application 1 While it is possible to have multiple ports open for project-level communication within a data plane, incoming internet traffic can only be directed to a single port. This contrasts with Service-type components, which allow for multiple endpoints."},{"location":"references/faq/","title":"Frequently Asked Questions","text":""},{"location":"references/faq/#general","title":"General","text":""},{"location":"references/faq/#q-what-is-choreo","title":"Q: What is Choreo?","text":"Choreo is an internal developer platform designed to accelerate the creation of digital experiences. With Choreo, you can effortlessly build, deploy, monitor, and manage your cloud native applications. Our goal is to enhance developer productivity and enable innovation.
"},{"location":"references/faq/#q-what-is-an-organization-in-choreo","title":"Q: What is an organization in Choreo?","text":"An organization is a logical grouping of users and their resources. It may represent a company, community, or a single user. Users can belong to multiple organizations, and each organization can have different roles assigned to its users to control access to Choreo features.
"},{"location":"references/faq/#q-what-is-a-project-in-choreo","title":"Q: What is a project in Choreo?","text":"A project is a logical grouping of related components to help you organize your work. Each project provides runtime isolation through namespaces when you deploy components.
"},{"location":"references/faq/#q-what-is-a-component-in-choreo","title":"Q: What is a component in Choreo?","text":"A component is a workload designed to run on Choreo. Examples of components include integrations, APIs, microservices, manual/scheduled jobs, web apps, and triggers.
"},{"location":"references/faq/#q-what-is-the-difference-between-an-internal-and-external-api","title":"Q: What is the difference between an internal and external API?","text":"In Choreo, you can publish an API as an internal or an external API. A user or an application can access an external API publicly over the internet, whereas an internal API is only accessible through other components within the same organization.
"},{"location":"references/faq/#q-what-is-a-connector-in-choreo-marketplace","title":"Q: What is a connector in Choreo Marketplace?","text":"A connector is a reusable Ballerina package that simplifies connecting to external or internal systems and APIs, such as Salesforce, SAP, GitHub, and Twilio. You can use the connectors available in the Choreo marketplace to implement your integration use cases. Connectors can be created and published by both WSO2 and Choreo users.
"},{"location":"references/faq/#q-what-is-a-trigger-in-choreo-marketplace","title":"Q: What is a trigger in Choreo Marketplace?","text":"A trigger is a construct that enables users to receive known event payloads from external systems, facilitating event-driven programming.
"},{"location":"references/faq/#q-what-is-a-sampletemplate-in-choreo","title":"Q: What is a sample/template in Choreo?","text":"A sample or template is a prebuilt Ballerina program that covers a popular integration use case or pattern. Examples include connecting Salesforce to Slack or implementing content-based routing.
"},{"location":"references/faq/#q-what-are-the-support-options-in-choreo","title":"Q: What are the support options in Choreo?","text":"You can find information about our support plans, including free, basic, and enterprise options at https://wso2.com/choreo/customer-support/.
If you have a log monitoring product or service, such as Azure Monitor, you can use it together with Choreo. Note: The log monitoring tool is not included in the infrastructure cost.
"},{"location":"references/faq/#q-what-is-the-maximum-request-payload-size-supported-by-choreo","title":"Q: What is the maximum request payload size supported by Choreo?","text":"Choreo allows a maximum request payload size of 10 MB.
"},{"location":"references/faq/#q-what-source-control-software-does-choreo-support","title":"Q: What source control software does Choreo support?","text":"Choreo now supports GitHub, Bitbucket and GitLab.
"},{"location":"references/faq/#q-why-dont-i-see-the-undeployed-builds-for-my-component-in-choreo","title":"Q: Why don't I see the undeployed builds for my component in Choreo?","text":"You are allowed to build your component any number of times. However, Choreo has a limit on retaining undeployed builds. For users on the free-tier, Choreo will retain only one undeployed build. For those on any other tier, Choreo will retain the latest five undeployed builds.
"},{"location":"references/faq/#q-what-is-ballerina","title":"Q: What is Ballerina?","text":"Ballerina is an open-source programming language designed for the cloud. It simplifies the process of using, combining, and creating network services. When you use Ballerina to write integrations in Choreo, you can save time and deliver 2-3x faster. To learn more, check out https://ballerina.io/.
"},{"location":"references/faq/#q-what-is-asgardeo","title":"Q: What is Asgardeo?","text":"Asgardeo is an identity provider (IdP) that allows developers to secure access for consumers, business partners, employees, and APIs. Asgardeo is Choreo\u2019s default IDP. To learn more, visit https://wso2.com/asgardeo/.
"},{"location":"references/faq/#q-why-dont-i-see-the-region-selector-on-the-project-creation-page","title":"Q: Why don\u2019t I see the region selector on the project creation page?","text":"If you are a Choreo cloud data plane user, you can create projects in multiple regions only if you have a paid subscription in Choreo. Otherwise, your projects will be created in the same region you selected when onboarding the organization.
If you are a private data plane user, there will be no region selector in project creation at all.
"},{"location":"references/faq/#q-as-a-cloud-data-plane-user-how-can-i-create-components-in-multiple-data-planes","title":"Q: As a Cloud Data Plane user, how can I create components in multiple data planes?","text":"When an organization admin onboards a new organization in Choreo, they can choose the preferred data plane. Choreo then sets the selected data plane as the default for the entire organization. Subsequently, users within the free tier of the cloud data plane can create components only in the set default data plane. If a free-tier user needs to create components in a different data plane, the user must get a paid subscription.
"},{"location":"references/faq/#security-and-data-protection","title":"Security and data protection","text":""},{"location":"references/faq/#q-how-is-data-managed-in-choreo","title":"Q: How is data managed in Choreo?","text":"Choreo manages data using WSO2 containers and Kubernetes clusters, which provide scalability, resilience, and security. Find out more here.
"},{"location":"references/faq/#q-what-is-the-wso2-subprocessor-list","title":"Q: What is the WSO2 Subprocessor list?","text":"This is a detailed list of all subprocessors used by WSO2, including their name, location, and purpose. This information is updated frequently to ensure compliance with data protection regulations and is found here.
"},{"location":"references/faq/#q-how-do-we-secure-wso2-private-and-public-clouds","title":"Q: How do we secure WSO2 Private and Public Clouds?","text":"WSO2 uses a range of security controls and design patterns to protect against several threats, including internal attacks, software supply chain attacks, service and platform attacks, and more. Find out more regarding this here.
"},{"location":"references/faq/#q-how-can-i-connect-a-choreo-component-with-a-protected-third-party-application","title":"Q: How can I connect a Choreo component with a protected third-party application?","text":"To connect a Choreo component with a third-party application, it is necessary to establish seamless communication between the component and the protected third-party application, especially when connecting to external databases like MySQL, MSSQL, PGSQL, Oracle DB, etc. To ensure this, the requests coming from the Choreo data plane must be allowed by adding the specific data plane IP ranges to your allowlist.
If your component is deployed in the Choreo US data plane, add the following IP range to your allowlist:
If your component is deployed in the Choreo EU data plane, add the following IP range to your allowlist:
If you are working on the Cybertruck Challenge, add the following IP range to your allowlist:
The Choreo control plane is a centralized management component that oversees and coordinates the workloads deployed by customers. It provides a unified point of control and visibility for the organization, allowing administrators to manage, monitor, and orchestrate the organization\u2019s resources efficiently.
"},{"location":"references/faq/#q-what-is-a-data-plane","title":"Q: What is a data plane?","text":"A data plane in Choreo is a computing environment designed for running customer workloads. These environments are hosted in either a dedicated cloud infrastructure owned by the customer (private data planes) or on public cloud infrastructure owned by WSO2, also known as the Choreo data plane.
"},{"location":"references/faq/#q-which-regions-support-the-choreo-data-planecdp","title":"Q: Which regions support the Choreo data plane(CDP)?","text":"The Choreo data plane is currently supported in the US East 2 and North Europe. However, WSO2 is planning to add support for additional regions as needed.
"},{"location":"references/faq/#q-which-regions-support-private-data-planespdps","title":"Q: Which regions support private data planes(PDPs)?","text":"Private data planes can be deployed in any region where Azure and AWS are available and meet the requirements for PDPs.
"},{"location":"references/faq/#q-if-i-want-to-use-my-azure-aks-instances-as-the-private-data-plane-what-are-the-minimum-requirements-i-should-meet","title":"Q: If I want to use my Azure AKS instances as the private data plane, what are the minimum requirements I should meet?","text":"We recommend using a minimum of two (2) workload nodes to ensure high availability.
"},{"location":"references/faq/#q-are-the-choreo-control-plane-and-data-planes-highly-available-are-they-running-on-multiple-clusters","title":"Q: Are the Choreo control plane and data planes highly available? Are they running on multiple clusters?","text":"The Choreo control plane and data plane are designed for high availability using Azure components like AKS, MSSQL, ACR, KV, Service Bus, and so on, with a high availability of 99.99%, which allows at least three workload nodes. In the event of a node failure or upgrade, this setup provides reliable failover. WSO2 also has a backup and recovery strategy in place, including continuous restore drills. If you require AKS cluster-level redundancy, we can consider multiple zones. In this case, the cost will include an additional infrastructure cost.
"},{"location":"references/faq/#environments","title":"Environments","text":""},{"location":"references/faq/#q-as-a-choreo-cloud-data-plane-user-why-cant-i-create-environments","title":"Q: As a Choreo cloud data plane user, why can't I create environments?","text":"You can create environments only if you have a paid subscription in Choreo. It can be either Pay-as-you-Go (PAYG) or an Enterprise plan.
"},{"location":"references/faq/#q-i-am-a-pay-as-you-go-payg-customer-using-the-choreo-cloud-data-plane-how-many-environments-can-i-create","title":"Q: I am a Pay-As-You-Go (PAYG) customer using the Choreo cloud data plane. How many environments can I create?","text":"You can create up to 5 environments at the organization level, including the existing Development & Production environments by default. If you have projects in both data planes (US & EU), there will be 4 environments already created in total, and you will only be allowed to create one additional environment either in the US or EU data plane.
"},{"location":"references/faq/#q-i-am-an-enterprise-subscription-customer-using-the-choreo-private-data-plane-how-many-environments-do-i-get","title":"Q: I am an Enterprise subscription customer using the Choreo private data plane. How many environments do I get?","text":"As an Enterprise subscription customer, the number of environments you can use is not limited. However, the more environments you use, the more resources you will consume in the data plane for the workload you deploy. This may result in higher infrastructure costs for the private data plane.
"},{"location":"references/faq/#q-as-a-choreo-cloud-data-plane-user-why-dont-i-see-both-us-eu-data-planes-in-the-data-plane-selector-when-creating-an-environment","title":"Q: As a Choreo cloud data plane user, why don\u2019t I see both US & EU data planes in the data plane selector when creating an environment?","text":"You will see both US & EU data planes only if you have a paid subscription and have created projects in both US & EU data planes.
"},{"location":"references/faq/#q-i-am-a-customer-who-use-choreo-in-a-private-data-plane-how-many-environments-can-i-create","title":"Q: I am a customer who use Choreo in a private data plane. How many environments can I create?","text":"Initially, you will receive the requested number of environments when establishing your private data plane. Subsequently, you can create additional environments as needed.
"},{"location":"references/faq/#billing-and-support","title":"Billing and support","text":""},{"location":"references/faq/#q-whom-do-i-reach-out-to-if-i-have-a-billing-question","title":"Q: Whom do I reach out to if I have a billing question?","text":"You can reach out to cloud-billing-support@wso2.com or create a support ticket via our support portal.
"},{"location":"references/faq/#q-whats-a-developer-plan","title":"Q: What's a Developer plan?","text":"A Developer plan allows you to try out Choreo\u2019s capabilities at no cost. It\u2019s ideal for proof of concept (PoC) tasks or workloads with limited transactions. This plan allows you to experiment with up to 5 components and provides US$1,000/year of Choreo data plane (CDP) credits.
"},{"location":"references/faq/#q-how-do-i-calculate-the-infrastructure-costs","title":"Q: How do I calculate the infrastructure costs?","text":"Calculating infrastructure costs depends on the type of workload you want to manage. Here are a few examples:
Your bill will detail the number of components used, infrastructure consumed, support plans used, and any additional services you may have purchased. If you are unsure about any charges on your bill, reach out to choreo-support@wso2.com for clarification.
"},{"location":"references/faq/#q-is-support-included-in-the-choreo-enterprise-plan","title":"Q: Is support included in the Choreo Enterprise plan?","text":"The Choreo Enterprise plan does not automatically include support; however, you can purchase support plans in addition to the Enterprise plan at any time. Find out more at https://wso2.com/choreo/customer-support/.
"},{"location":"references/faq/#q-i-am-an-enterprise-subscription-customer-who-wants-to-use-the-choreo-private-data-plane-what-costs-will-i-incur-in-addition-to-the-subscription-and-support-plan","title":"Q: I am an Enterprise subscription customer who wants to use the Choreo private data plane. What costs will I incur in addition to the subscription and support plan?","text":"You can start by using a basic plan or contact us for an Enterprise support plan.
"},{"location":"references/faq/#q-i-want-to-upgrade-from-payg-to-an-enterprise-subscription-will-there-be-an-outage-during-the-upgrade","title":"Q: I want to upgrade from PAYG to an Enterprise subscription. Will there be an outage during the upgrade?","text":"No, there are no outages when upgrading a plan.
"},{"location":"references/faq/#choreo-cli","title":"Choreo CLI","text":""},{"location":"references/faq/#q-how-do-i-uninstall-the-cli","title":"Q: How do I uninstall the CLI?","text":"If you didn't download the binary directly, you can uninstall the CLI by deleting the .choreo directory in the home directory of your operating system.
You can update the CLI by running the following command:
curl -o- https://cli.choreo.dev/install.sh | bash\n"},{"location":"references/faq/#q-what-are-the-supported-component-types-in-the-cli","title":"Q: What are the supported component types in the CLI?","text":"The Choreo CLI currently supports the following component types: - Service - Web Application - Webhook - Scheduled Task - Manual Task
"},{"location":"references/faq/#q-how-do-i-get-help-with-a-specific-command-in-the-cli","title":"Q: How do I get help with a specific command in the CLI?","text":"You can get help with a specific command by running the following command:
choreo <command> --help\n"},{"location":"references/faq/#q-what-are-the-build-configurations-required-when-creating-components-using-the-cli","title":"Q: What are the build configurations required when creating components using the CLI?","text":"You can configure the component build configurations depending on the component type as follows:
choreo create component <name> --project <name> --build-configs='key1=value1,key2=value2'\nchoreo create component <name> --project <name> --build-configs='key1=value1' --build-configs='key2=value2'\n The build configurations required for existing buildpacks are as follows:
Component Type Buildpack Required Configurations Service PythonChoreo supports various management models for private data planes (PDPs), fostering collaboration between WSO2 and customers across diverse scenarios. The following sections provide insights into WSO2's fully managed solutions and shared responsibility models, allowing you to make informed decisions regarding cloud-based operations and security.
"},{"location":"references/private-data-plane-management-models/#wso2-fully-managed-infrastructure-and-pdp-in-wso2-subscription-model","title":"WSO2 fully managed (infrastructure and PDP in WSO2 subscription) model","text":"WSO2 fully managed private data planes are supported only on Azure, AWS, and GCP cloud providers.
Task Task description Responsible party Accountable Consulted Informed Subscription prerequisites - Create subscriptions - Check quota and service limits - Run the Choreo compatibility prerequisite script WSO2 WSO2 Customer (If required) Customer (If required) Remote access for installation Provide owner access WSO2 WSO2 WSO2 WSO2 Network management - Obtain customers backend CIDR in case of VPN/peering - Check end-to-end connectivity (primary and failover) WSO2/Customer WSO2/Customer Customer Customer Firewall rules/access control Set up firewall and required rules depending on the security tier WSO2 WSO2 Customer Customer Infrastructure provisioning - Provision Bastion - Provision Kubernetes clusters WSO2 WSO2 - Customer(If required) Kubernetes cluster management - Manage Kubernetes versions - Increase node pool size WSO2 WSO2 Customer Customer Infrastructure monitoring Set up alerts WSO2 WSO2 - Customer(If required) DNS management for Choreo system - Manage DNS infrastructure - Manage SSL certificates for Choreo system components WSO2/Customer WSO2/Customer Customer Customer Choreo system components deployment Set up PDP agents via Helm WSO2 WSO2 - - Choreo system components management Upgrade/patch/debug versions WSO2 WSO2 - Customer(If required) Choreo system components monitoring - Set up continuous monitoring 24x7 - Provide monthly uptime reports WSO2 WSO2 - Customer Choreo system security monitoring If basic tier - CSPM - Apply security patches - Manage supply chain security (Image scanning, SAST) - Manage security incidents If standard tier/premium tier - CSPM - Apply security patches - Manage supply chain security - Monitor runtime security alerts (Azure Defender) - Monitor security incident and event management (SIEM) alerts - Manage security incidents - Adhere to compliance standards WSO2/Customer WSO2/Customer WSO2/Customer WSO2/Customer Choreo application creation/deployment Customer Customer Customer Customer Choreo application management Customer Customer Customer Customer Choreo application monitoring Customer Customer Customer Customer Choreo application logs Customer Customer Customer Customer"},{"location":"references/private-data-plane-management-models/#wso2-fully-managed-infrastructure-and-pdp-in-customer-subscription-model","title":"WSO2 fully managed (infrastructure and PDP in customer subscription) model","text":"Task Task description Responsible party Accountable Consulted Informed Subscription prerequisites - Create subscriptions - Check quota and service limits - Run the Choreo compatibility prerequisite script Customer Customer WSO2 - Remote access for installation Provide access Customer Customer WSO2 WSO2 Network management - Obtain customers backend CIDR in case of VPN/peering - Check end-to-end connectivity (primary and failover) WSO2/Customer WSO2/Customer Customer Customer Firewall rules/access control Set up firewall and required rules depending on the security tier WSO2/Customer WSO2/Customer Customer Customer Infrastructure provisioning - Provision Bastion - Provision Kubernetes clusters WSO2 WSO2 Customer Customer Kubernetes cluster management - Manage Kubernetes versions - Increase node pool size WSO2 WSO2 Customer Customer Infrastructure monitoring Set up alerts WSO2 WSO2 - Customer(If required) DNS management for Choreo system - Manage DNS infrastructure - Manage SSL certificates for Choreo system components WSO2/Customer WSO2/Customer Customer Customer Choreo system components deployment Set up PDP agents via Helm WSO2 WSO2 Customer - Choreo system components management Upgrade/patch/debug versions WSO2 WSO2 - Customer(If required) Choreo system components monitoring - Set up continuous monitoring 24x7 - Provide monthly uptime reports WSO2 WSO2 - Customer Choreo system security monitoring If basic tier - CSPM - Apply security patches - Manage supply chain security (Image scanning, SAST) - Manage security incidents If standard tier/premium tier - CSPM - Apply security patches - Manage supply chain security - Monitor runtime security alerts (Azure Defender) - Monitor security incident and event management (SIEM) alerts - Manage security incidents - Adhere to compliance standards WSO2/Customer WSO2/Customer WSO2/Customer WSO2/Customer Choreo application creation/deployment Customer Customer Customer Customer Choreo application management Customer Customer Customer Customer Choreo application monitoring Customer Customer Customer Customer Choreo application logs Customer Customer Customer Customer"},{"location":"references/private-data-plane-management-models/#customer-self-managed-wso2-provides-installation-script-and-updates-model","title":"Customer self-managed (WSO2 provides installation script and updates) model","text":"Task Task description Responsible party Accountable Consulted Informed Subscription prerequisites - Create subscriptions - Check quota and service limits - Run the Choreo compatibility prerequisite script Customer Customer WSO2 WSO2 Remote access for installation Provide owner access Customer Customer WSO2 - Network management - Obtain customers backend CIDR in case of VPN/peering - Check end-to-end connectivity (primary and failover) Customer Customer WSO2 WSO2 Firewall rules/access control Set up firewall and required rules depending on the security tier Customer Customer WSO2 WSO2 Infrastructure provisioning - Provision Bastion - Provision Kubernetes clusters Customer Customer WSO2 WSO2(If required) Kubernetes cluster management - Manage Kubernetes versions - Increase node pool size Customer Customer WSO2 WSO2(If required) Infrastructure monitoring Set up alerts Customer Customer WSO2 - DNS management for Choreo system - Manage DNS infrastructure - Manage SSL certificates for Choreo system components Customer Customer WSO2 - Choreo system components deployment Set up PDP agents via Helm Customer Customer WSO2 - Choreo system components management Upgrade/patch/debug versions Customer Customer WSO2 - Choreo system components monitoring - Set up continuous monitoring 24x7 - Provide monthly uptime reports Customer Customer WSO2 - Choreo system security monitoring If basic tier - CSPM - Apply security patches - Manage supply chain security (Image scanning, SAST) - Manage security incidents If standard tier/premium tier - CSPM - Apply security patches - Manage supply chain security - Monitor runtime security alerts (Azure Defender) - Monitor security incident and event management (SIEM) alerts - Manage security incidents - Adhere to compliance standards WSO2/Customer WSO2/Customer WSO2/Customer WSO2/Customer Choreo application creation/deployment Customer Customer Customer Customer Choreo application management Customer Customer Customer Customer Choreo application monitoring Customer Customer Customer Customer Choreo application logs Customer Customer Customer Customer"},{"location":"references/private-data-plane-security-levels/","title":"Private Data Plane Security Levels","text":"The following table outlines the private data plane security levels supported in Choreo:
Basic tier Standard tier Premium tier Distributed denial-of-service (DDoS) protection basic * Distributed denial-of-service (DDoS) protection basic * Distributed denial-of-service (DDoS) protection premium * Controlled admin access * Controlled admin access * Controlled admin access * End-to-end data encryption in transit End-to-end data encryption in transit End-to-end data encryption in transit Data encryption at rest * Data encryption at rest * Data encryption at rest * Secret management Secret management Secret management Foundational CSPM * Foundational CSPM * Premium CSPM * Static application security testing (SAST) Static application security testing (SAST) Static application security testing (SAST) Infrastructure as code (IaC) scanning Infrastructure as code (IaC) scanning Infrastructure as code (IaC) scanning Software composition analysis Software composition analysis Software composition analysis Docker image security scanning Docker image security scanning Docker image security scanning N/A Kubernetes runtime protection * Kubernetes runtime protection * N/A Web application firewall (WAF) * Web application firewall (WAF) * N/A N/A Network firewall ** Not available in the on-premises private data plane.
Tip
Available add-ons: - Security incident and event management (SIEM). - 24/7 security operation center.
"},{"location":"references/troubleshoot-choreo/","title":"Troubleshoot Choreo","text":"This page walks you through common problems you may encounter when building and deploying components with Choreo, along with the recommended solutions to resolve each issue.
"},{"location":"references/troubleshoot-choreo/#troubleshoot-component-build-errors","title":"Troubleshoot component build errors","text":""},{"location":"references/troubleshoot-choreo/#deploying-an-angular-web-application-displays-the-nginx-welcome-page-instead-of-the-applications-homepage","title":"Deploying an Angular web application displays the Nginx welcome page instead of the application's homepage.","text":"This occurs due to specifying an incorrect build output directory when you set up your Angular application in Choreo. To resolve the issue, follow the guidelines given below:
dist/<project-name>.The recommended approach to address this issue is to fix the identified vulnerability and rebuild the component.
However, if you want to add a .trivyignore file to overcome the issue, ensure to add it to the Docker build context path specified when creating the component. For example, {buildContextPath}./trivyignore.
config.js file is not properly mounted in a web application.","text":"To resolve this issue, follow the steps given below:
config.js file to the app/public directory in your repository.Reference it from the index.html file by adding a script tag as follows:
<script src=\"public/config.js\"></script>
config.js file is not properly integrated during the deployment of a React application, causing it to render with unexpected HTML instead of the expected JavaScript configuration.","text":"To ensure correct loading of the config.js file, follow the steps given below:
Reference the config.js file from the index.html file of your application by adding a script tag as follows:
<script src=\"public/config.js\"></script>
Verify that the path in the script tag matches the location where the config.js file is stored in your repository.
<body> tag in your index.html file. You must ensure that it is not mistakenly placed within another HTML element.Merge commits and commits pushed directly to the branch can trigger a build in Choreo.
"},{"location":"references/troubleshoot-choreo/#troubleshoot-web-application-issues","title":"Troubleshoot web application issues","text":""},{"location":"references/troubleshoot-choreo/#after-building-a-web-application-the-nginx-welcome-page-is-displayed-instead-of-the-web-application-home-page","title":"After building a web application, the Nginx welcome page is displayed instead of the web application home page.","text":"This can happen if an incorrect build output directory is specified during component creation.
During the build process, output files including the index.html are copied to the Nginx root directory. To ensure that the correct files are copied during the build process, you must check the Docker build logs.
In such scenarios, you can use the Dockerfile buildpack to create the component.
"},{"location":"references/troubleshoot-choreo/#i-mistakenly-used-an-incorrect-build-command-when-creating-a-web-application-how-can-i-update-it-before-triggering-a-build","title":"I mistakenly used an incorrect build command when creating a web application. How can I update it before triggering a build?","text":"You can go to the build page of the component and update the build command in the build configurations section.
"},{"location":"references/troubleshoot-choreo/#troubleshoot-managed-authentication-issues","title":"Troubleshoot managed-authentication issues","text":""},{"location":"references/troubleshoot-choreo/#after-securing-a-web-application-with-managed-authentication-im-not-able-to-add-users-who-can-sign-in-to-the-application","title":"After securing a web application with managed authentication, I\u2019m not able to add users who can sign in to the application.","text":"For step-by-step instructions on how to manage users with Choreo's built-in identity provider (IdP), see Configure a User Store with the Built-In IdP.
For details on setting up other OpenID Connect (OIDC) supported IdPs, see Manage OAuth Keys.
"},{"location":"references/troubleshoot-choreo/#troubleshoot-tailscale-proxy-issues","title":"Troubleshoot Tailscale proxy issues","text":""},{"location":"references/troubleshoot-choreo/#where-can-i-find-logs-to-troubleshoot-tailscale-proxy-issues","title":"Where can I find logs to troubleshoot Tailscale proxy issues?","text":"To troubleshoot Tailscale proxy issues, you can view the Runtime Logs of the running container for your Tailscale proxy deployment. These logs can help you diagnose most of the issues. You can also view real-time container logs via the Runtime page under DevOps. For more details, see Observe real-time container logs.
"},{"location":"references/troubleshoot-choreo/#im-not-able-to-connect-the-tailscale-proxy-node-to-my-tailscale-network-due-to-an-authentication-failure","title":"I'm not able to connect the Tailscale proxy node to my Tailscale network due to an authentication failure.","text":"If you encounter the following log lines in your Tailscale proxy deployment, it indicates a misconfiguration of the TS_AUTH_KEY:
2024-06-04T10:38:53.885800940Z To authenticate, visit:\n2024-06-04T10:38:53.885802684Z \n2024-06-04T10:38:53.885815708Z https://login.tailscale.com/a/696841f011517\n2024-06-04T10:38:53.885817457Z \n2024-06-04T10:38:55.194344862Z Waiting for tailscale up to complete...\n2024-06-04T10:38:57.198970796Z Waiting for tailscale up to complete...\n2024-06-04T10:38:59.203265659Z Waiting for tailscale up to complete...\n To resolve this, you must re-check your authentication key and ensure you have entered the correct key. If you encounter the following log lines in your Tailscale proxy deployment, it indicates that your authentication key is invalid or expired.
2024-06-04T11:33:58.762363181Z 2024/06/04 11:33:58 Received error: invalid key: unable to validate API key\n2024-06-04T11:33:58.762458209Z backend error: invalid key: unable to validate API key\n To resolve this, you must verify the correctness of your authentication key. If the key has expired, you must generate a new key from Tailscale admin console.
To resolve this, do the following:
Config.yaml file (mounted to Tailscale proxy during deployment) match the IP addresses in your Tailscale network.endpoints.yaml file with the port mappings in the Config.yaml file.Testing APIs is an essential step in the API development process. Choreo simplifies the testing task by allowing you to engage with your APIs using natural language through Choreo API Chat. It eliminates manual test scenario creation and JSON payload accuracy concerns. It enables easy API communication using human language and requires no coding for handling sequences with multiple resource calls. This makes your API testing efficient and user-friendly.
Info
This feature is available for REST API Proxy components and Service components with REST endpoints.
"},{"location":"testing/test-apis-with-choreo-apichat/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, be sure that you have the following:
A REST API Proxy component or a Service component that exposes a REST API with a valid OpenAPI specification.
Info
Follow the steps below to test an API with API Chat:
Testing APIs is an essential step in the API development process. Choreo simplifies the testing task by allowing you to use cURL commands generated by Choreo.
You can follow the steps below to generate a cURL command and test your API method:
Sign in to the Choreo Console.
In the Component Listing pane, click on the component you want to test.
Click Test in the left navigation menu and then click cURL. This opens the cURL pane.
In the cURL pane, select the environment from the drop-down list.
Select an appropriate HTTP method from the Method list.
Click the Parameters tab and add the necessary parameters for the API method.
Click the Headers tab and add the required header values.
Click the Body tab and select the message body type to invoke the API method.
Copy the generated cURL command.
Use the copied cURL command via a cURL client to test your API method.
Test Runner is a component type in Choreo that simplifies the process of running automated tests against your components deployed in Choreo. This capability helps developers evaluate applications in different setups and environments, leading to more confidence and improved visibility into the application's status.
You can create tests using popular programming languages like Go, Java, JavaScript, Python, and more. Additionally, you have the option to build a test runner component by supplying a Dockerfile containing a series of test scripts or by offering a set of Postman Collections.
"},{"location":"testing/test-components-with-test-runner/#prerequisites","title":"Prerequisites","text":"Before you try out the steps in this guide, complete the following:
Stark Industries.You can develop tests in a language of your choice and execute them within the Choreo platform.
"},{"location":"testing/test-components-with-test-runner/#create-a-test-runner-component-using-a-buildpack","title":"Create a test runner component using a buildpack","text":"Enter a display name, unique name, and description for the test runner component. For this guide, enter the following values:
Info
In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Component Display NameGo Test Runner Component Name go-test-runner Description Test Runner implemented in Go Go to the GitHub tab.
To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
Note
The Choreo GitHub App requires the following permissions:
You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
Under Connect Your Repository, enter the following information:
Field Value Organization Your GitHub account GitHub Repository choreo-samples Branchmain Under Buildpack, select a buildpack based on the language of your choice.
Based on the buildpack you chose, go to the relevant tab below and enter the respective values for the Project directory and Language version fields:
GoJavaScriptPythonJavaDockerfilePostman Field Value Go Project Directory /test-runner-go Language Version 1.x Field Value Project Directory /test-runner-javascript Language Version 18.x.x Field Value Project Directory /test-runner-python Language Version 3.10.x Field Value Project Directory /test-runner-java Language Version 17For programming languages that doesn't support buildpacks or for advanced use cases, you can define your own Dockerfile and run test workloads. Refer to for more information. Field Value Postman Directory /postman-collection-dir
Click Create.
You have successfully created a Test Runner component using a buildpack of your choice. Now let's build and run the tests.
"},{"location":"testing/test-components-with-test-runner/#build-and-deploy-the-test-runner-component-to-execute-the-tests","title":"Build and deploy the test runner component to execute the tests","text":"Once the execution is completed it is listed on the execution page. This may take some time. Once the execution is listed, you can click on a particular execution to view the test result(s).
Inject dynamic values into your application as command-line arguments
If you want to inject dynamic values into your application as command-line arguments when you run a test runner component, follow the steps given below:
Tip
For Postman Collections:
-f or --files as the first argument, followed by a comma-separated list of collections.Choreo provides an integrated GraphQL Console to test publicly exposed GraphQL endpoints of Service components you create and deploy. The GraphQL Console allows you to write queries and mutations interactively. As Choreo uses OAuth2.0 authentication by default to secure GraphQL APIs, the GraphQL Console generates test keys to test APIs.
Follow the steps below to test a GraphQL endpoint via the GraphQL Console:
Sign in to the Choreo Console.
In the Component Listing pane, click on the component you want to test.
Click Test in the left navigation menu and then click Console. This opens the GraphQL Console pane.
In the GraphQL Console pane, select the environment from the drop-down list.
Select the required endpoint from the Endpoint list.
Note
If the Network Visibility of the endpoint is set to Organization, click on Generate URL to generate a temporary test URL that will be active for 15 minutes. Else, skip this step.
Note
The temporay test URL will be available only for 15 minutes and it will get expired after. You can deactivate the test URL by clicking on the Deactivate URL button.
Enter the API path and the query or mutation you want to test.
Click the play icon.
Tip
If you want to generate a required query or mutation for testing via the GraphQL Explorer, click Explorer to open the GraphQL Explorer.
Note
GraphQL Explorer has a known issue causing improper construction of list inputs. To work around this, you must manually update the list input in the generated query before executing it.
Choreo provides an integrated OpenAPI Console to test REST endpoints of Service components that you create and deploy. As Choreo uses OAuth2.0 authentication to secure REST APIs, the OpenAPI Console generates test keys to test APIs.
Follow the steps below to test a REST endpoint via the integrated OpenAPI Console:
Sign in to the Choreo Console.
In the Component Listing pane, click on the component you want to test.
Click Test in the left navigation menu and then click Console. This opens the OpenAPI Console pane.
In the OpenAPI Console pane, select the environment from the drop-down list.
Select the required endpoint from the Endpoint list.
Note
If the Network Visibility of the endpoint is set to Organization, click on Generate URL to generate a temporary test URL that will be active for 15 minutes. Else, skip this step.
Note
The temporary test URL will be available only for 15 minutes and it will get expired after. You can deactivate the test URL by clicking on the Deactivate URL button.
Expand the resource you want to test.
Click Try it out.
Enter values for parameters if applicable.
Click Execute. You can see the response body under Responses.
Choreo simplifies securely exposing existing services as managed APIs. It also allows you to effectively manage all aspects of an API's lifecycle, security, throttling, and governance so that you can focus more on service development.
In this tutorial, you will use Choreo to expose a service as an API proxy and publish it to the Choreo Developer Portal for application developers to consume.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#prerequisites","title":"Prerequisites","text":"Before you try out this tutorial, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this tutorial, you will use a URL of a sample OpenAPI specification.
Follow the steps given below:
Update the populated API proxy details with the values given in the following table:
Info
In the Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
Field Value Display NameSwagger Petstore Name swagger-petstore Context api/v3 Version 1.0 Target https://petstore3.swagger.io/api/v3 Access Mode External: API is publicly accessible Click Create. This creates the component and takes you to the Overview page of the component.
To see the resources of the API proxy, go to the left navigation menu, click Develop, and then click Resources.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#step-2-deploy-the-api-proxy","title":"Step 2: Deploy the API proxy","text":"To deploy the API proxy to the development environment, follow the steps given below:
In the Build Area card, click Configure & Deploy. This opens the Configure & Deploy pane, where you can select the API access mode depending on how you want the API to be accessible.
Here, you can select External to make the API publicly accessible, and then click Deploy.
Once the deployment is complete, the Development card indicates the Deployment Status as Active.
Now you are ready to test the API proxy.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#step-3-test-the-api-proxy","title":"Step 3: Test the API proxy","text":"You can test the API proxy in the development environment before promoting it to production. Choreo provides the following options to test your API proxy: - OpenAPI Console - cURL
In this guide, you will use the OpenAPI Console.
To test the API proxy via the OpenAPI Console, follow the steps given below:
In the left navigation menu, click Test and then click OpenAPI Console.
Tip
Since the API proxy is secured when it is deployed, you will need a key to invoke it. Choreo automatically generates a key when you navigate to the OpenAPI Console pane.
In the OpenAPI Console pane, select Development from the environment drop-down list.
GET /pet/findByStatus method and click Try it Out to test it.Select available as the status and click Execute. You will see a response similar to the following:
This indicates that your API proxy is working as expected.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#step-4-promote-the-api-proxy-to-production","title":"Step 4: Promote the API proxy to production","text":"Once you verify that the API proxy is working as expected in the development environment, you can follow the steps given below to promote it to production:
In the Configure & Deploy pane that opens, click Next.
Tip
If you want to specify a different endpoint for your production environment, you can make the change in the Configure & Deploy pane.
The Production card indicates the Deployment Status as Active when the API proxy is successfully deployed to production.
If you want to verify that the API proxy is working as expected in production, you can test the API in the production environment.
Now that your API is deployed in both development and production environments and can be invoked, the next step is to publish it so that consumers can discover and subscribe to it.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#step-5-publish-the-api-proxy","title":"Step 5: Publish the API proxy","text":"To publish the API to the Choreo Developer Portal, follow the steps given below:
You can observe that the API lifecycle stage has changed to Published. Now the API is available for consumption. API consumers can consume the API via the Choreo Developer Portal.
"},{"location":"tutorials/expose-a-service-as-a-managed-api/#step-6-invoke-the-api","title":"Step 6: Invoke the API","text":"To generate credentials for the published API and to invoke it via the Developer Portal, follow the steps below:
In the Lifecycle Management pane, click Go to DevPortal. This takes you to the Petstore API published to the Choreo Developer Portal.
To generate credentials for testing the API, follow the steps given below:
To invoke the API, follow the steps given below:
GET /pet/findByStatus operation and click Try it out.Now you have successfully created, deployed, tested, and published an API proxy using Choreo.
"},{"location":"tutorials/secure-an-api-with-role-based-access-control/","title":"Secure an API with Role-Based Access Control","text":"Role-based access control is a flexible and scalable approach to manage access to API resources. In this approach, each user or group is assigned a specific role that determines the permission granted to perform operations on an API resource.
This tutorial explains how to implement role-based access control using Choreo and Asgardeo. It includes a real-world scenario with instructions to create and publish an API proxy component in Choreo and apply role-based access control.
"},{"location":"tutorials/secure-an-api-with-role-based-access-control/#scenario","title":"Scenario","text":"An organization needs to implement a user management service to keep track of users. The service needs to perform the following four operations:
There are two types of users in the organization:
Each user type requires different levels of access to the user management service.
Let\u2019s take a look at the steps to follow to implement the scenario described above using Choreo and Asgardeo.
"},{"location":"tutorials/secure-an-api-with-role-based-access-control/#prerequisites","title":"Prerequisites","text":"Before you try out this guide, complete the following:
If you are signing in to the Choreo Console for the first time, create an organization as follows:
Stark Industries.This creates the organization and opens the home page of the default project created for you.
Enable Asgardeo as the key manager
If you created your organization in Choreo before the 21st of February 2023, and you have not already enabled Asgardeo as the key manager, follow these steps to enable Asgardeo as the default key manager:
In the confirmation dialog that opens, click Yes.
Tip
Enabling Asgardeo as the default key manager has the following effects:
Follow these steps to create an API proxy component, add resources, and deploy it:
In the Resources pane, follow the steps given below to add resources:
/users as the URI Pattern, and click + to add the resource./users/{userID} as the URI Pattern, and click + to add the resource./users as the URI Pattern, and click + to add the resource./users/{userID} as the URI Pattern, and click + to add the resource.To remove the five default resources that start with /*, click the delete icon corresponding to each resource. This marks the resources for deletion.
Click Save. The API resources will be as follows:
In the left navigation menu, click Deploy.
Follow these steps:
get_user_list as the permission value and click +Add New.get_user, create_user, and delete_user as permission values.In the Permissions section, expand each resource and select the permission values as follows for each:
Resource Permission GET/usersget_user_list GET/users/{userID} get_user POST/users create_user DELETE/users/{userID} delete_user Click Apply.
Now you are ready to promote the API to production.
Now, an application developer can discover the API, subscribe to it and then invoke it.
"},{"location":"tutorials/secure-an-api-with-role-based-access-control/#step-3-subscribe-to-the-published-api","title":"Step 3: Subscribe to the Published API","text":"In this step, you take the role of an application developer who consumes the published API. To consume the API, you must create an application, generate keys, and subscribe to the API.
Follow these steps:
User Management App as the Application Name and click Create. This creates the application and takes you to the application overview page.In this step, you define roles, create necessary groups and assign appropriate roles to groups so that you can easily manage user permission.
Follow these steps:
In the Permissions section, click Manage Permissions. This takes you to the Roles tab of the User Management App application in Asgardeo, where you can add applicable roles.
Follow these steps to add roles:
admin as the Role Name, and click Next.get_user_list, get_user, create_user, and delete_useras Role Permissions.user as the Role Name and get_user_list, and get_user as Role Permissions.Now you can proceed to create groups and assign applicable roles to the groups.
In the Asgardeo Console left navigation menu, click User Management and then click Groups.
HR-Manager as the Group Name, and click Finish.HR-Officer as the Group Name and assign the user role to it.In this step, you define users and assign them to groups depending on the job function of the user. This allows you to manage permission at the group level instead of for individual users.
Follow these steps:
Cameron and Alex. For step-by-step instructions on adding a user, see Manage users in the Asgardeo documentation.Cameron to the HR-Manager group and assign Alex to the HR-Officer group. For step-by-step instructions on assigning a user to a group, see Assign groups in the Asgardeo documentation.Follow these steps:
Construct the authorization URL as follows by replacing the placeholders with appropriate values:
<authorize_URL>?response_type=code&client_id=<clientID>&redirect_uri=<redirect_URL>&scope=<scopes>\n Replace <authorize URL> with the URL populated as the Authorize Endpoint in the Application Keys pane.
Replace <redirect_URL> with the value specified as the Callback URL under Advanced Configurations in the Application Keys pane.
Replace <scopes> with the permission(scopes) applicable to the user. You can copy the applicable permission(scopes) from the API Overview page. Here let\u2019s copy the permission(scopes) applicable to the user Alex.
Replace <clientID> with the value populated as Consumer Key in the Application Keys pane.
Open the constructed URL via a web browser. This will take you to a sign-in page provided by Asgardeo.
Sign in with credentials of Alex and click Allow to approve the consent.
This redirects you to the callback URL of the application. The URL includes a code as a query parameter.
Copy the code and use it to replace <code> in the following cURL command to invoke the authorization code grant token request:
curl <token_url> -d \"grant_type=authorization_code&code=<code>&redirect_uri=<redirect_uri>\" -H \"Authorization: Basic <base64(clientId:clientSecret)>\"\n Replace <token_url> with the URL populated as the Token Endpoint in the Application Keys pane.
Replace <redirect_uri> with the value specified as the Callback URL under Advanced Configurations in the Application Keys pane.
Use a Base64 encoder to encode your client ID and client secret in the following format and replace <base64(clientId:clientSecret)> with the encoded value:
<clientId>:<clientSecret>
Note
WSO2 does not recommend the use of online Base64 encoders for this purpose.
Extract the access token from the response that you get.
Go to the API Developer Portal, try out the HR API using the access token you extracted, and observe the responses.
You\u2019ll observe that it is only possible to access the following resources because the access token only contains the permission(scopes) to invoke those resources:
Invoking any other resource gives you a scope validation failed response because the token doesn't include the required scopes to invoke them.
Similarly, if you use Cameron\u2019s credentials and sign in to obtain an access token, you'll observe that you can invoke all four resources because it would contain all the required permission(scopes).
Now you have gained hands-on experience in implementing role-based access control with Choreo and Asgardeo.
"}]} \ No newline at end of file diff --git a/en/site/sitemap.xml b/en/site/sitemap.xml deleted file mode 100644 index bee42de259..0000000000 --- a/en/site/sitemap.xml +++ /dev/null @@ -1,598 +0,0 @@ - -
-
-
-
- Testing APIs is an essential step in the API development process. Choreo simplifies the testing task by allowing you to engage with your APIs using natural language through Choreo API Chat. It eliminates manual test scenario creation and JSON payload accuracy concerns. It enables easy API communication using human language and requires no coding for handling sequences with multiple resource calls. This makes your API testing efficient and user-friendly.
-Info
-This feature is available for REST API Proxy components and Service components with REST endpoints.
-Before you try out this guide, be sure that you have the following:
-A REST API Proxy component or a Service component that exposes a REST API with a valid OpenAPI specification.
-Info
-| Component type | -Sample source | -Reference documentation | -
|---|---|---|
| REST API Proxy | -https://raw.githubusercontent.com/wso2/choreo-sample-apps/main/rest-api-proxy/pet-store/openapi.yaml | -Develop an API Proxy | -
| Service (Exposing a REST API endpoint) | -https://github.com/wso2/choreo-sample-apps/tree/main/java/pet-store | -Develop a Service | -
Follow the steps below to test an API with API Chat:
-
-
-
-
- Testing APIs is an essential step in the API development process. Choreo simplifies the testing task by allowing you to use cURL commands generated by Choreo.
-You can follow the steps below to generate a cURL command and test your API method:
-Sign in to the Choreo Console.
-In the Component Listing pane, click on the component you want to test.
-Click Test in the left navigation menu and then click cURL. This opens the cURL pane.
-In the cURL pane, select the environment from the drop-down list.
-Select an appropriate HTTP method from the Method list.
-Click the Parameters tab and add the necessary parameters for the API method.
-Click the Headers tab and add the required header values.
-Click the Body tab and select the message body type to invoke the API method.
-Copy the generated cURL command.
-Use the copied cURL command via a cURL client to test your API method.
-
-
-
-
- Test Runner is a component type in Choreo that simplifies the process of running automated tests against your components deployed in Choreo. This capability helps developers evaluate applications in different setups and environments, leading to more confidence and improved visibility into the application's status.
-You can create tests using popular programming languages like Go, Java, JavaScript, Python, and more. Additionally, you have the option to build a test runner component by supplying a Dockerfile containing a series of test scripts or by offering a set of Postman Collections.
-Before you try out the steps in this guide, complete the following:
-Stark Industries.You can develop tests in a language of your choice and execute them within the Choreo platform.
-Enter a display name, unique name, and description for the test runner component. For this guide, enter the following values:
-Info
-In the Component Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
-| Field | -Value | -
|---|---|
| Component Display Name | -Go Test Runner |
-
| Component Name | -go-test-runner |
-
| Description | -Test Runner implemented in Go |
-
Go to the GitHub tab.
-To allow Choreo to connect to your GitHub account, click Authorize with GitHub. If you have not already connected your GitHub repository to Choreo, enter your GitHub credentials and select the repository you created in the prerequisites section to install the Choreo GitHub App.
-Alternatively, you can paste the Choreo samples repository URL in the Provide Repository URL field to connect to it without requiring authorization from the Choreo Apps GitHub application. However, authorizing the repository with the Choreo GitHub App is necessary if you want to enable Auto Deploy for the component.
-Note
-The Choreo GitHub App requires the following permissions:
-You can revoke access if you do not want Choreo to have access to your GitHub account. However, write access is exclusively utilized for sending pull requests to a user repository. Choreo will not directly push any changes to a repository.
-Under Connect Your Repository, enter the following information:
-| Field | -Value | -
|---|---|
| Organization | -Your GitHub account | -
| GitHub Repository | -choreo-samples | -
| Branch | -main |
-
Under Buildpack, select a buildpack based on the language of your choice.
-Based on the buildpack you chose, go to the relevant tab below and enter the respective values for the Project directory and Language version fields:
-| Field | -Value | -
|---|---|
| Go Project Directory | -/test-runner-go | -
| Language Version | -1.x | -
| Field | -Value | -
|---|---|
| Project Directory | -/test-runner-javascript | -
| Language Version | -18.x.x | -
| Field | -Value | -
|---|---|
| Project Directory | -/test-runner-python | -
| Language Version | -3.10.x | -
| Field | -Value | -
|---|---|
| Project Directory | -/test-runner-java | -
| Language Version | -17 | -
For programming languages that doesn't support buildpacks or for advanced use cases, you can define your own Dockerfile and run test workloads. Refer to
| Field | -Value | -
|---|---|
| Postman Directory | -/postman-collection-dir | -
Click Create.
-You have successfully created a Test Runner component using a buildpack of your choice. Now let's build and run the tests.
-Once the execution is completed it is listed on the execution page. This may take some time. Once the execution is listed, you can click on a particular execution to view the test result(s).
-Inject dynamic values into your application as command-line arguments
-If you want to inject dynamic values into your application as command-line arguments when you run a test runner component, follow the steps given below:
-Tip
-For Postman Collections:
-f or --files as the first argument, followed by a comma-separated list of collections.
-
-
-
- Choreo provides an integrated GraphQL Console to test publicly exposed GraphQL endpoints of Service components you create and deploy. The GraphQL Console allows you to write queries and mutations interactively. As Choreo uses OAuth2.0 authentication by default to secure GraphQL APIs, the GraphQL Console generates test keys to test APIs.
-Follow the steps below to test a GraphQL endpoint via the GraphQL Console:
-Sign in to the Choreo Console.
-In the Component Listing pane, click on the component you want to test.
-Click Test in the left navigation menu and then click Console. This opens the GraphQL Console pane.
-In the GraphQL Console pane, select the environment from the drop-down list.
-Select the required endpoint from the Endpoint list.
-Note
-If the Network Visibility of the endpoint is set to Organization, click on Generate URL to generate a temporary test URL that will be active for 15 minutes. Else, skip this step.
-Note
-The temporay test URL will be available only for 15 minutes and it will get expired after. You can deactivate the test URL by clicking on the Deactivate URL button.
-Enter the API path and the query or mutation you want to test.
-Click the play icon.
-Tip
-If you want to generate a required query or mutation for testing via the GraphQL Explorer, click Explorer to open the GraphQL Explorer.
-Note
-GraphQL Explorer has a known issue causing improper construction of list inputs. To work around this, you must manually update the list input in the generated query before executing it.
-
-
-
-
- Choreo provides an integrated OpenAPI Console to test REST endpoints of Service components that you create and deploy. -As Choreo uses OAuth2.0 authentication to secure REST APIs, the OpenAPI Console generates test keys to test APIs.
-Follow the steps below to test a REST endpoint via the integrated OpenAPI Console:
-Sign in to the Choreo Console.
-In the Component Listing pane, click on the component you want to test.
-Click Test in the left navigation menu and then click Console. This opens the OpenAPI Console pane.
-In the OpenAPI Console pane, select the environment from the drop-down list.
-Select the required endpoint from the Endpoint list.
-Note
-If the Network Visibility of the endpoint is set to Organization, click on Generate URL to generate a temporary test URL that will be active for 15 minutes. Else, skip this step.
-Note
-The temporary test URL will be available only for 15 minutes and it will get expired after. You can deactivate the test URL by clicking on the Deactivate URL button.
-Expand the resource you want to test.
-Click Try it out.
-Enter values for parameters if applicable.
-Click Execute. You can see the response body under Responses.
- -
-
-
-
- Choreo simplifies securely exposing existing services as managed APIs. It also allows you to effectively manage all aspects of an API's lifecycle, security, throttling, and governance so that you can focus more on service development.
-In this tutorial, you will use Choreo to expose a service as an API proxy and publish it to the Choreo Developer Portal for application developers to consume.
-Before you try out this tutorial, complete the following:
-If you are signing in to the Choreo Console for the first time, create an organization as follows:
-Stark Industries.This creates the organization and opens the Project Home page of the default project created for you.
-To create an API proxy, you can either upload an OpenAPI specification or provide an OpenAPI specification URL. In this tutorial, you will use a URL of a sample OpenAPI specification.
-Follow the steps given below:
-Update the populated API proxy details with the values given in the following table:
-Info
-In the Name field, you must specify a name to uniquely identify the component in various contexts. The value is editable only at the time you create the component. You cannot change the name after you create the component.
-| Field | -Value | -
|---|---|
| Display Name | -Swagger Petstore |
-
| Name | -swagger-petstore |
-
| Context | -api/v3 |
-
| Version | -1.0 |
-
| Target | -https://petstore3.swagger.io/api/v3 |
-
| Access Mode | -External: API is publicly accessible |
-
Click Create. This creates the component and takes you to the Overview page of the component.
-To see the resources of the API proxy, go to the left navigation menu, click Develop, and then click Resources.
-To deploy the API proxy to the development environment, follow the steps given below:
-In the Build Area card, click Configure & Deploy. This opens the Configure & Deploy pane, where you can select the API access mode depending on how you want the API to be accessible.
-Here, you can select External to make the API publicly accessible, and then click Deploy.
-Once the deployment is complete, the Development card indicates the Deployment Status as Active.
-Now you are ready to test the API proxy.
-You can test the API proxy in the development environment before promoting it to production. Choreo provides the following options to test your API proxy: -- OpenAPI Console -- cURL
-In this guide, you will use the OpenAPI Console.
-To test the API proxy via the OpenAPI Console, follow the steps given below:
-In the left navigation menu, click Test and then click OpenAPI Console.
-Tip
-Since the API proxy is secured when it is deployed, you will need a key to invoke it. Choreo automatically generates a key when you navigate to the OpenAPI Console pane.
-In the OpenAPI Console pane, select Development from the environment drop-down list.
-GET /pet/findByStatus method and click Try it Out to test it.Select available as the status and click Execute. You will see a response similar to the following:
- -This indicates that your API proxy is working as expected.
-Once you verify that the API proxy is working as expected in the development environment, you can follow the steps given below to promote it to production:
-In the Configure & Deploy pane that opens, click Next.
-Tip
-If you want to specify a different endpoint for your production environment, you can make the change in the Configure & Deploy pane.
-The Production card indicates the Deployment Status as Active when the API proxy is successfully deployed to production.
-If you want to verify that the API proxy is working as expected in production, you can test the API in the production environment.
-Now that your API is deployed in both development and production environments and can be invoked, the next step is to publish it so that consumers can discover and subscribe to it.
-To publish the API to the Choreo Developer Portal, follow the steps given below:
-You can observe that the API lifecycle stage has changed to Published. Now the API is available for consumption. API consumers can consume the API via the Choreo Developer Portal.
-To generate credentials for the published API and to invoke it via the Developer Portal, follow the steps below:
-In the Lifecycle Management pane, click Go to DevPortal. This takes you to the Petstore API published to the Choreo Developer Portal.
-To generate credentials for testing the API, follow the steps given below:
-To invoke the API, follow the steps given below:
-GET /pet/findByStatus operation and click Try it out.Now you have successfully created, deployed, tested, and published an API proxy using Choreo.
- - - - - - -
-
-
-
- Role-based access control is a flexible and scalable approach to manage access to API resources. In this approach, each user or group is assigned a specific role that determines the permission granted to perform operations on an API resource.
-This tutorial explains how to implement role-based access control using Choreo and Asgardeo. It includes a real-world scenario with instructions to create and publish an API proxy component in Choreo and apply role-based access control.
-An organization needs to implement a user management service to keep track of users. The service needs to perform the following four operations:
-There are two types of users in the organization:
-Each user type requires different levels of access to the user management service.
-Let’s take a look at the steps to follow to implement the scenario described above using Choreo and Asgardeo.
-Before you try out this guide, complete the following:
-If you are signing in to the Choreo Console for the first time, create an organization as follows:
-Stark Industries.This creates the organization and opens the home page of the default project created for you.
-Enable Asgardeo as the key manager
-If you created your organization in Choreo before the 21st of February 2023, and you have not already enabled Asgardeo as the key manager, follow these steps to enable Asgardeo as the default key manager:
-In the confirmation dialog that opens, click Yes.
-Tip
-Enabling Asgardeo as the default key manager has the following effects:
-Follow these steps to create an API proxy component, add resources, and deploy it:
-In the Resources pane, follow the steps given below to add resources:
-/users as the URI Pattern, and click + to add the resource./users/{userID} as the URI Pattern, and click + to add the resource./users as the URI Pattern, and click + to add the resource./users/{userID} as the URI Pattern, and click + to add the resource.To remove the five default resources that start with /*, click the delete icon corresponding to each resource. This marks the resources for deletion.
Click Save. The API resources will be as follows:
- -In the left navigation menu, click Deploy.
-Follow these steps:
-get_user_list as the permission value and click +Add New.get_user, create_user, and delete_user as permission values.In the Permissions section, expand each resource and select the permission values as follows for each:
-| Resource | -Permission | -
|---|---|
| GET/users | -get_user_list |
-
| GET/users/{userID} | -get_user |
-
| POST/users | -create_user |
-
| DELETE/users/{userID} | -delete_user |
-
Click Apply.
-Now you are ready to promote the API to production.
-Now, an application developer can discover the API, subscribe to it and then invoke it.
-In this step, you take the role of an application developer who consumes the published API. -To consume the API, you must create an application, generate keys, and subscribe to the API.
-Follow these steps:
-User Management App as the Application Name and click Create. This creates the application and takes you to the application overview page.In this step, you define roles, create necessary groups and assign appropriate roles to groups so that you can easily manage user permission.
-Follow these steps:
-In the Permissions section, click Manage Permissions. This takes you to the Roles tab of the User Management App application in Asgardeo, where you can add applicable roles.
Follow these steps to add roles:
-admin as the Role Name, and click Next.get_user_list, get_user, create_user, and delete_useras Role Permissions.user as the Role Name and get_user_list, and get_user as Role Permissions.Now you can proceed to create groups and assign applicable roles to the groups.
-In the Asgardeo Console left navigation menu, click User Management and then click Groups.
-HR-Manager as the Group Name, and click Finish.HR-Officer as the Group Name and assign the user role to it.In this step, you define users and assign them to groups depending on the job function of the user. This allows you to manage permission at the group level instead of for individual users.
-Follow these steps:
-Cameron and Alex. For step-by-step instructions on adding a user, see Manage users in the Asgardeo documentation.Cameron to the HR-Manager group and assign Alex to the HR-Officer group. For step-by-step instructions on assigning a user to a group, see Assign groups in the Asgardeo documentation.Follow these steps:
-Construct the authorization URL as follows by replacing the placeholders with appropriate values:
-<authorize_URL>?response_type=code&client_id=<clientID>&redirect_uri=<redirect_URL>&scope=<scopes>
-Replace <authorize URL> with the URL populated as the Authorize Endpoint in the Application Keys pane.
Replace <redirect_URL> with the value specified as the Callback URL under Advanced Configurations in the Application Keys pane.
Replace <scopes> with the permission(scopes) applicable to the user. You can copy the applicable permission(scopes) from the API Overview page. Here let’s copy the permission(scopes) applicable to the user Alex.
Replace <clientID> with the value populated as Consumer Key in the Application Keys pane.
Open the constructed URL via a web browser. This will take you to a sign-in page provided by Asgardeo.
-Sign in with credentials of Alex and click Allow to approve the consent.
This redirects you to the callback URL of the application. The URL includes a code as a query parameter.
- -Copy the code and use it to replace <code> in the following cURL command to invoke the authorization code grant token request:
curl <token_url> -d "grant_type=authorization_code&code=<code>&redirect_uri=<redirect_uri>" -H "Authorization: Basic <base64(clientId:clientSecret)>"
-Replace <token_url> with the URL populated as the Token Endpoint in the Application Keys pane.
Replace <redirect_uri> with the value specified as the Callback URL under Advanced Configurations in the Application Keys pane.
Use a Base64 encoder to encode your client ID and client secret in the following format and replace <base64(clientId:clientSecret)> with the encoded value:
<clientId>:<clientSecret>
Note
WSO2 does not recommend the use of online Base64 encoders for this purpose.
- -Extract the access token from the response that you get.
- -Go to the API Developer Portal, try out the HR API using the access token you extracted, and observe the responses.
-You’ll observe that it is only possible to access the following resources because the access token only contains the permission(scopes) to invoke those resources:
-Invoking any other resource gives you a scope validation failed response because the token doesn't include the required scopes to invoke them.
-
Similarly, if you use Cameron’s credentials and sign in to obtain an access token, you'll observe that you can invoke all four resources because it would contain all the required permission(scopes).
-Now you have gained hands-on experience in implementing role-based access control with Choreo and Asgardeo.
- - - - - - -
-
-
-
- Choreo is an internal developer platform that redefines how you create digital experiences. Choreo empowers you to seamlessly design, develop, deploy, and govern your cloud native applications, unlocking innovation while reducing time-to-market.
-The following are some of the cutting-edge capabilities of Choreo:
-Design that leads to end-to-end security, governance, and operational efficiency:
-Efficient and effective development:
-Seamless deployment:
-Effortless management of APIs, integrations, microservices, and web applications:
-Reusable digital assets:
-Comprehensive observability:
-Robust governance:
-
-
+
+ {% include "partials/logo.html" %}
+ {% include "partials/perspective-selector.html" %}