Guide for Isolated Environment

Standard Procedure for Skybuffer Components in Isolated Pre-Production Landscapes

This procedure applies to isolated pre-production landscapes and must be executed prior to delivery to higher environments. All operations must be carried out by an authorized technical user with OS-level permissions (SAP HANA host) and SAP HANA XS Advanced administrative privileges (Space Developer / Space Manager).

Network Requirement During Initial Deployment: Staging processes for Python runtimes and buildpacks require downloading external dependencies, libraries, and models. If outbound connections are blocked, deployment will fail. The customer must provide temporary outbound internet access or configure an enterprise proxy for the initial deployment.

1. Network & Proxy Configuration

If an outbound proxy is required in your enterprise landscape, configure the XS CLI and environment variables:

# Configure proxy environment variables for staging/runtime
xs set-env <app_name> HTTP_PROXY http://<proxy-host>:<port>
xs set-env <app_name> HTTPS_PROXY http://<proxy-host>:<port>

Ensure that firewall rules permit outbound HTTPS traffic (port 443) to the following endpoints during staging:

• .pytorch.org
• .pypi.org
• .pythonhosted.org
• .python.org
• .npmjs.org
• .hf.co
• huggingface.co
• .unstructured.io
• .githubusercontent.com
• download.geonames.org:443

2. Prerequisites & Verification

In an isolated environment, UI libraries cannot be pulled on-the-fly from the public internet. Skybuffer provides local delivery applications to host and serve these UI libraries directly within the XSA landscape.

Important Notice !

Node.js ≥22.14.0 must already be installed on the XSA host before you begin the deployment steps in Section 3 below — this is an offline environment, so it cannot be downloaded mid-deployment. Node 24 is not supported on XSA — stay on the 22.x LTS line.
See Section: Runtimes Handling/Pre-Deployment Runtime Check on the XS Deployment Process page for the install procedure — this must be done while temporary outbound access is available, per the Network Requirement above.

Switch to the directory containing your packages and verify the presence of all .mtar archives and the extension descriptor (sapui5rt.mtaext):

ls -la *.mtar sapui5rt.mtaext

3. Deployment Sequence

Step 1: Authenticate to Target Space

Log in to the XS Advanced Controller and target the dedicated deployment space:

xs login -a https://<xsa-controller-host>:39030 -u <tech_user> -s <target_space>

Verification: Run ‘xs target’ to confirm active Organization and Space.

Steps 2–3: Deploy Local UI & Runtime Foundation

Deploy the local UI library providers first before launching consumer apps:

xs deploy skybfrxts.mtar
xs deploy xsafecrt.mtar

Verification: CLI must output ‘Process finished with status: SUCCESS’.

Step 4: Deploy Core Application (Skybuffer YAI)

Deploy the core module with the UI runtime extension file attached:

xs deploy skybfryai_0.0.1.mtar -e sapui5rt.mtaext

Verification: Run ‘xs app skybfryai’ — instance status must be RUNNING.

Steps 5–6: Deploy AI Core & RAG Services

Install the Python AI core engine and the Retrieval-Augmented Generation (RAG) module:

xs deploy skybfryai_py_ai_core.mtar
xs deploy skybfryai_rag_m.mtar

Verification: Run ‘xs apps’ and confirm both services report 1/1 instances running.

Steps 7–8: Deploy Bot Connector & Translation Module

Deploy the integration client connector and translation service:

xs deploy botclientconnector.mtar
xs deploy xsa_release_skybfryai_translate.mtar

Verification: Execute ‘xs apps’ and ensure all 7 components have status RUNNING.

4. Post-Deployment Routing & Port Validation

SAP XS Advanced connects to deployed services via application hostnames + default domains or dedicated port mappings. During deployments or updates, routes and ports may be reassigned or unmapped.

Option A: Validation via XS Advanced Cockpit

• Open XS Advanced Cockpit in your browser.
• Navigate to Space -> Routes.
• Verify that URLs and port assignments correspond to the target applications. If missing, recreate and rebind.

Option B: CLI Route Re-mapping

If a route is unmapped, missing, or assigned an incorrect port, execute:

# Unmap conflicting/outdated route
xs unmap-route <app-name> <your-xsa-domain> --port <old-port>

# Map correct route and port
xs map-route <app-name> <your-xsa-domain> --port <expected-port>

# Example for Bot Client Connector
xs map-route botclientconnector <your-xsa-domain> --port <expected-port>

Verification: Access the endpoint via browser or run a health-check curl command. The application should respond normally without 502/404 errors.