Deploying a project uploads compiled LU artifacts to a Fabric server, making them active and ready for use.
Deployment not performed from Fabric Studio can be done in two ways:
buildAndDeployArtifacts.sh — builds artifacts and deploys them in a single command.deploy-artifacts.sh — deploys artifacts that were previously built and stored, for example from a separate CI build stage.You can also deploy a single LU directly on the Fabric server using the DEPLOY command, or remotely using the Fabric REST API.
All script-based methods support local and remote deployment:
-r flag). Does not require a local Fabric installation.buildAndDeployArtifacts.sh orchestrates the full pipeline: build → optionally deploy environment → deploy LU artifacts. It calls buildArtifacts.sh, deploy-environment.sh, and deploy-artifacts.sh internally, stopping if any step fails.
The script is located under $FABRIC_HOME/fabric/scripts.
Usage:
./buildAndDeployArtifacts.sh -pd <PATH_TO_PROJECT> [options]
Options:
The options are passed as command-line arguments. They can also be set as environment variables before running the script, although passing them as arguments is the recommended approach.
The port depends on the deploy mode. A local deploy connects to the Fabric JDBC endpoint, using the default port 5124. A remote deploy connects to the Fabric REST API endpoint, whose default port is 3213 — set it explicitly unless it is already part of the host URL.
Authentication: the script accepts -b / --bearer, -t / --token, or -u / --username with -p / --password. If more than one is set, --bearer is used first, then --token, then --username/--password.
Example — build and deploy to a remote server:
./buildAndDeployArtifacts.sh \
-pd /opt/apps/MyProject \
-host 10.0.0.5 \
-u admin -p mypassword \
-r
Example — deploy-only (pre-built artifacts) with environment activation:
./buildAndDeployArtifacts.sh \
-pd /opt/apps/MyProject \
-host 10.0.0.5 -r \
-d \
-de -e Production
deploy-artifacts.sh deploys LU artifacts that have already been built, for example using buildArtifacts.sh in a separate CI stage. The script is located under $FABRIC_HOME/fabric/scripts.
Usage:
./deploy-artifacts.sh [options]
Options:
The options are passed as command-line arguments. They can also be set as environment variables before running the script, although passing them as arguments is the recommended approach.
The port depends on the deploy mode. A local deploy connects to the Fabric JDBC endpoint, using the default port 5124. A remote deploy connects to the Fabric REST API endpoint, whose default port is 3213 — set it explicitly unless it is already part of the host URL.
Authentication: the script accepts -b / --bearer, -t / --token, or -u / --username with -p / --password. If more than one is set, --bearer is used first, then --token, then --username/--password.
The script enforces a fixed deployment order: k2_ref is deployed first, all other LUs follow, and k2_ws (Web Services) is deployed last.
Example — deploy from a CI artifact store to a remote server:
./deploy-artifacts.sh \
-ad $FABRIC_HOME/artifacts/MyProject \
--remote-deploy \
--host 10.0.0.5 \
--port 3124 \
-b $API_TOKEN
On the Fabric server, deploy a single LU directly using the DEPLOY command. Copy the ludb.jar and ludbXMLs.zip files to the target server, then run:
DEPLOY <LUT> WITH JAR <'jar_path'> ZIP_FILE <'zip_path'> [WS_METHODS <'string'>] NOSYNC <Boolean>;
Options:
Option |
Description |
|---|---|
LUT |
Logical Unit Type name. |
JAR |
Mandatory. Path to the JAR file, relative to USER_DIR. |
ZIP_FILE |
Path to the ZIP file, relative to USER_DIR. |
NOSYNC |
TRUE — only schema changes trigger a sync after deploy. FALSE — any deploy triggers a sync on the first instance access. Note that NOSYNC FALSE is equivalent to checking the Force Upgrade Post Deploy checkbox in the Server Configuration window. |
SOFT_DEPLOY |
Default: FALSE. When TRUE, skips automatic processes: jobs, parsers, interface listeners, and deploy.flow. |
WS_METHODS |
When LUT = k2_ws (Web Services), specify which methods to deploy, separated by ",". Empty or omitted = all methods. |
Example:
DEPLOY k2_ws WITH JAR '/home/k2view/project/k2_ws/ludb.jar' ZIP_FILE '/home/k2view/project/k2_ws/ludbXMLs.zip' WS_METHODS 'dbQueryOnAnyDB' NOSYNC true;
Use the Fabric REST API to deploy remotely without a local Fabric installation.
POST https://<FABRIC-IP>:<FABRIC-PORT>/deploy?luName=<LUT-NAME>[&noSync=true|false][&softDeploy=true|false][&methodList=<LIST-OF-METHODS>]&[token=<APIKEY>][user=<USER-NAME>&password=<PASSWORD>]
Authenticate with any one of the following.
Request header:
Authorization: Bearer <APIKEY> — available from Fabric 8.5.1.Authorization: Basic <base64(user:password)>URL parameters:
token=<APIKEY>user=<USER-NAME>&password=<PASSWORD>The caller must hold deploy permissions. See Fabric Credentials.
Send with Content-Type: multipart/form-data.
Parameter |
Description |
Mandatory |
jar |
Path to the JAR file. |
Y |
projectXmlData |
Path to the ludbXMLs ZIP file. When not specified, only Java files are deployed. |
N |
Deploying a project uploads compiled LU artifacts to a Fabric server, making them active and ready for use.
Deployment not performed from Fabric Studio can be done in two ways:
buildAndDeployArtifacts.sh — builds artifacts and deploys them in a single command.deploy-artifacts.sh — deploys artifacts that were previously built and stored, for example from a separate CI build stage.You can also deploy a single LU directly on the Fabric server using the DEPLOY command, or remotely using the Fabric REST API.
All script-based methods support local and remote deployment:
-r flag). Does not require a local Fabric installation.buildAndDeployArtifacts.sh orchestrates the full pipeline: build → optionally deploy environment → deploy LU artifacts. It calls buildArtifacts.sh, deploy-environment.sh, and deploy-artifacts.sh internally, stopping if any step fails.
The script is located under $FABRIC_HOME/fabric/scripts.
Usage:
./buildAndDeployArtifacts.sh -pd <PATH_TO_PROJECT> [options]
Options:
The options are passed as command-line arguments. They can also be set as environment variables before running the script, although passing them as arguments is the recommended approach.
The port depends on the deploy mode. A local deploy connects to the Fabric JDBC endpoint, using the default port 5124. A remote deploy connects to the Fabric REST API endpoint, whose default port is 3213 — set it explicitly unless it is already part of the host URL.
Authentication: the script accepts -b / --bearer, -t / --token, or -u / --username with -p / --password. If more than one is set, --bearer is used first, then --token, then --username/--password.
Example — build and deploy to a remote server:
./buildAndDeployArtifacts.sh \
-pd /opt/apps/MyProject \
-host 10.0.0.5 \
-u admin -p mypassword \
-r
Example — deploy-only (pre-built artifacts) with environment activation:
./buildAndDeployArtifacts.sh \
-pd /opt/apps/MyProject \
-host 10.0.0.5 -r \
-d \
-de -e Production
deploy-artifacts.sh deploys LU artifacts that have already been built, for example using buildArtifacts.sh in a separate CI stage. The script is located under $FABRIC_HOME/fabric/scripts.
Usage:
./deploy-artifacts.sh [options]
Options:
The options are passed as command-line arguments. They can also be set as environment variables before running the script, although passing them as arguments is the recommended approach.
The port depends on the deploy mode. A local deploy connects to the Fabric JDBC endpoint, using the default port 5124. A remote deploy connects to the Fabric REST API endpoint, whose default port is 3213 — set it explicitly unless it is already part of the host URL.
Authentication: the script accepts -b / --bearer, -t / --token, or -u / --username with -p / --password. If more than one is set, --bearer is used first, then --token, then --username/--password.
The script enforces a fixed deployment order: k2_ref is deployed first, all other LUs follow, and k2_ws (Web Services) is deployed last.
Example — deploy from a CI artifact store to a remote server:
./deploy-artifacts.sh \
-ad $FABRIC_HOME/artifacts/MyProject \
--remote-deploy \
--host 10.0.0.5 \
--port 3124 \
-b $API_TOKEN
On the Fabric server, deploy a single LU directly using the DEPLOY command. Copy the ludb.jar and ludbXMLs.zip files to the target server, then run:
DEPLOY <LUT> WITH JAR <'jar_path'> ZIP_FILE <'zip_path'> [WS_METHODS <'string'>] NOSYNC <Boolean>;
Options:
Option |
Description |
|---|---|
LUT |
Logical Unit Type name. |
JAR |
Mandatory. Path to the JAR file, relative to USER_DIR. |
ZIP_FILE |
Path to the ZIP file, relative to USER_DIR. |
NOSYNC |
TRUE — only schema changes trigger a sync after deploy. FALSE — any deploy triggers a sync on the first instance access. Note that NOSYNC FALSE is equivalent to checking the Force Upgrade Post Deploy checkbox in the Server Configuration window. |
SOFT_DEPLOY |
Default: FALSE. When TRUE, skips automatic processes: jobs, parsers, interface listeners, and deploy.flow. |
WS_METHODS |
When LUT = k2_ws (Web Services), specify which methods to deploy, separated by ",". Empty or omitted = all methods. |
Example:
DEPLOY k2_ws WITH JAR '/home/k2view/project/k2_ws/ludb.jar' ZIP_FILE '/home/k2view/project/k2_ws/ludbXMLs.zip' WS_METHODS 'dbQueryOnAnyDB' NOSYNC true;
Use the Fabric REST API to deploy remotely without a local Fabric installation.
POST https://<FABRIC-IP>:<FABRIC-PORT>/deploy?luName=<LUT-NAME>[&noSync=true|false][&softDeploy=true|false][&methodList=<LIST-OF-METHODS>]&[token=<APIKEY>][user=<USER-NAME>&password=<PASSWORD>]
Authenticate with any one of the following.
Request header:
Authorization: Bearer <APIKEY> — available from Fabric 8.5.1.Authorization: Basic <base64(user:password)>URL parameters:
token=<APIKEY>user=<USER-NAME>&password=<PASSWORD>The caller must hold deploy permissions. See Fabric Credentials.
Send with Content-Type: multipart/form-data.
Parameter |
Description |
Mandatory |
jar |
Path to the JAR file. |
Y |
projectXmlData |
Path to the ludbXMLs ZIP file. When not specified, only Java files are deployed. |
N |