Merge branch 'subscriptionApproval2' of https://github.com/jhivandb/d…

…ocs-choreo-dev into subscriptionApproval2

en/docs/administer/configure-approvals-for-choreo-workflows.md

@@ -2,14 +2,30 @@
 
 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 workflows, with support for API subscription approvals coming soon.
+Choreo currently allows you to configure approvals for environment promotion and API subscription 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.
 
 ## Permissions to review and respond to approval requests
 
-To review and respond to 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:
+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. Administrators must ensure that users designated to review and respond to approval requests have these permissions:
+
+      - **WORKFLOW-MANAGEMENT**: Grants access to view and approve workflow requests. Each workflow type has a separate permission.
+      - **PROJECT-MANAGEMENT**: Grants access to view and approve workflow requests. This is the same permission used to update or delete projects.
+
+=== "API subscription"
 
-  - **WORKFLOW-MANAGEMENT**: Grants access to view and approve workflow requests. Each workflow type has a separate permission.
-  - **PROJECT-MANAGEMENT**: Grants access to view and approve workflow requests. This is the same permission used to update or delete projects.
+     To review and respond to API subscription 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**: Grants access to view and approve workflow requests. Each workflow type has a separate permission.
+      - **PROJECT-MANAGEMENT**: Grants access to view and approve workflow requests. This is the same permission used to update or delete projects.
+      - **Approve API subscriptions**: Grants access to approve or reject API subscription requests.
 
 ## Set up an approval process for a workflow
 
@@ -34,4 +50,12 @@ To set up an approval process for a workflow, follow these steps:
 
 7. Click **Save**. This configures and enables the approval process for the workflow.
 
-Once you configure an approval process for a workflow, developers must [submit a request for approval to use the workflow](../develop-components/submit-and-manage-workflow-approval-requests.md). An authorized assignee must then [review and approve the request](./review-workflow-approval-requests.md) for a developer to proceed with the task related to the workflow. Depending on the workflow, there can be tasks where the execution may occur automatically upon approval.
+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](../develop-components/submit-and-manage-workflow-approval-requests.md). An authorized assignee must then [review and approve the request](./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, administrators can select the **Approval required** checkbox to create or update subscription plans to require approval. For details, see [Create API Subscription Plans](../administer/create-api-subscription-plans.md). API consumers using these plans must request approval to proceed. For details, see step 7 in [Subscribe to an API with a Subscription Plan](../api-management/manage-api-traffic/subscribe-to-an-api-with-a-subscription-plan.md). An authorized approver must then [review and approve the request](./review-workflow-approval-requests.md) before the subscription is granted.

en/docs/choreo-cli/choreo-cli-overview.md

@@ -1,6 +1,6 @@
-# Choreo Command Line Interface (CLI) Overview
+# Choreo Command-Line Interface (CLI) Overview
 
-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.
+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: 
 

en/docs/choreo-cli/manage-authentication-with-personal-access-tokens.md

@@ -0,0 +1,96 @@
+# Manage Authentication with Personal Access Tokens
+
+Personal access tokens (PATs) provide a secure method to authenticate with the Choreo CLI, allowing you to manage access without relying on primary credentials.
+
+## What are personal access tokens?
+
+Personal access tokens are unique strings that provide an alternative to username and password authentication. You can create PATs for specific use cases, associating them with your account to grant granular access to your application resources as needed.
+
+!!! note 
+      PATs should be treated like passwords and stored securely.
+
+## Sample use cases for personal access tokens
+
+PATs are versatile and suitable for various tasks in the Choreo CLI:
+
+- **Automated scripting**: To use in scripts for CI/CD pipelines or task automation, avoiding repeated sign-in prompts. This simplifies setting up CI/CD pipelines or other automation that rely on the CLI.
+- **Granular permissions for specific tasks**: To limit access to certain commands or specific features without providing full access, you can configure PATs with restricted permissions.
+- **Temporary access**: To grant temporary access for short-term projects or collaborations, without sharing full credentials.
+- **Integration with third-party tools**: To authenticate other tools or services that need access to
+your resources, such as analytics tools, monitoring systems, or deployment services. This approach keeps your main
+credentials secure while allowing API access.
+- **Multiple account management**: If you work with multiple accounts or roles, you can
+use separate PATs for each role for easy context switching.
+
+## Set up personal access tokens
+
+To create a PAT to use with the Choreo CLI, you must set up and retrieve a token from the Choreo Console.
+
+Follow these steps to create a PAT for Choreo CLI:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. Go to the Choreo Console header right corner, click your profile picture, and then click **Account Settings**.
+
+    ![Profile](../assets/img/choreo-cli/personal-access-tokens/profile.png)
+
+3. Click the **Personal Access Tokens** tab.
+
+    ![Account settings](../assets/img/choreo-cli/personal-access-tokens/account-settings.png)
+
+4. Click **+ Create New**.
+5. Specify a name for your token and define its scopes and permissions. By default, all necessary scopes for CLI functionality are selected.
+
+    ![Create a PAT](../assets/img/choreo-cli/personal-access-tokens/create-a-pat.png)
+
+6. Click **Generate**.
+7. Copy and securely store the displayed token. You won’t be able to view it again.
+8. Click **Done**.
+
+!!! info "Caution" 
+     - Treat the token as confidential information. 
+     - Avoid storing the token in unprotected files.
+
+## Use a personal access token with the Choreo CLI
+
+Once you generate a token, you can use it to authenticate with the Choreo CLI and perform various operations. 
+
+### Command syntax
+
+To log in with the token, use the following command:
+
+```bash
+choreo login --with-token
+```
+
+This command reads the token from the standard input.
+
+**Example:**
+
+```bash
+export CHOREO_TOKEN= <YOUR_PERSONAL_ACCESS_TOKEN>
+echo "$CHOREO_TOKEN" | choreo login --with-token
+```
+
+!!! note 
+     Replace `YOUR_PERSONAL_ACCESS_TOKEN` with your actual token.
+
+## Manage and revoke tokens
+
+To manage or revoke existing tokens, follow these steps:
+
+1. Sign in to the [Choreo Console](https://console.choreo.dev/).
+2. Go to the Choreo Console header right corner, click your profile picture, and then click **Account Settings**.
+3. On the **Account settings** page, click the **Personal Access Tokens** tab.
+4. Go to the token you want to revoke and click **Revoke**.
+
+!!! tip 
+     To maintain security, you must regularly review and revoke tokens that are no longer in use.
+
+![PAT listing](../assets/img/choreo-cli/personal-access-tokens/pat-listing.png)
+
+## Best practices for token management
+
+- **Limit scope:** Assign only the necessary permissions to each token.
+- **Rotate tokens regularly:** Replace tokens periodically to enhance security.
+- **Use secure storage:**  Store tokens in a secure location, such as a secrets manager.
+- **Revoke unused tokens:** Regularly audit and revoke inactive tokens.

en/docs/develop-components/develop-services/expose-a-websocket-endpoint-via-a-service.md

@@ -34,7 +34,10 @@ It is important to understand the purpose of the key files in the sample service
 |Filepath                        | Description                                                     |
 |--------------------------------|-----------------------------------------------------------------|
 | `server.js`                    | The NodeJS chat service.                                        |
-| `.choreo/component-config.yaml`| The configuration file with endpoint details.                   |
+| `.choreo/component.yaml`       | The configuration file with endpoint details.                   |
+
+!!! note
+    Choreo currently supports defining WebSocket APIs using the AsyncAPI 2.0 specification.
 
 ## Step 1: Create a service component 
 
@@ -117,8 +120,8 @@ Once you have successfully deployed your service, you can [test](../../testing/t
 During testing, once the WebSocket connection is established, you can send {"type": "Connect", "username": "user1"} to the WebSocket endpoint to connect to the chat service. You can then send chat messages by using {"type": "Data", "message": "Hello, World!"}.
 
 !!! note
-     Some clients, such as certain browsers, may not support adding headers to the WebSocket handshake. In these cases, you can include the access token or Test key required for WebSocket API invocation within the `sec-websocket-protocol` header, along with any specified subprotocols.
+     Some clients, such as certain browsers, may not support adding headers to the WebSocket handshake. In these cases, you can include the access token or test key required for WebSocket API invocation within the `sec-websocket-protocol` header, along with any specified subprotocols.
 
      For example: `sec-websocket-protocol: choreo-oauth2-token, {access token}, subprotocols`
 
-     If you are using a Test Key, replace `choreo-oauth2-token` with `choreo-test-key`.
+     If you are using a test key, replace `choreo-oauth2-token` with `choreo-test-key`.

en/docs/develop-components/manage-component-source-configurations.md

@@ -94,9 +94,9 @@ Click the respective tab to view the structure for your current configuration fi
     | **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`, `gRPC`, `UDP`, or `TCP`.|
+    | **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 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 endpoint types, when using the **Ballerina** or **Dockerfile** buildpack, the path should be relative to the component root or Docker context. |
+    | **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
 
@@ -186,9 +186,9 @@ Click the respective tab to view the structure for your current configuration fi
     | **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`, `gRPC`, `UDP`, or `TCP`.|
+    | **type**             | Required     | The type of traffic the endpoint accepts. For example, `REST`, `GraphQL`, `gRPC`, `WS`, `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 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 endpoint types, when using the **Ballerina** or **Dockerfile** buildpack, the path should be relative to the component root or Docker context. |
+    | **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. |
 
     <h3> Dependency configurations </h3>