Deploying a Fabric Project

What Is Fabric Deployment?

The implementation of a Fabric project can be divided into two steps:

• Design, configuration and coding, which includes the creation of a Fabric project and the definition of the relevant objects in the Fabric Studio in order to implement the business requirements.
• Deployment of the project into the Fabric server so that the first deployment of the new project or all recent changes since its last deployment are compiled and become effective on the server side.

A deployment includes the definition of Fabric objects like the LU Schema, LU Tables, Interfaces, Globals, Project functions, Web Services, Broadway flows, Graphit and Translations and is required whenever these objects are created or modified.

Deployment is needed for any change operated in any of these objects, excluding the migration of source data into the Fabric server. The deployment of a Fabric project is performed on the following levels:

• Deployment of Logical Units, each LU should be deployed separately.
  • When needed, a deployment can be performed on a specific LU if only that LU has been modified.
• Deployment of Broadway flows as part of the LU to which they belong.
• Deployment of References objects, when they exist in a project. All Reference (common) tables are deployed together.
• Deployment of Web Services, when they exist in the project. The following deployment options are available:
  • Deployment of all Web Services.
  • Deployment of selected Web Services category files.
  • Deployment of selected Web Services.
• Deployment of Graphit, when it exists in the project. The following deployment options are available:
  • Each Graphit object can be deployed separately or all Graphit objects can be deployed as part of the Web Services.
• Deployment of Environments.

Deployment can be performed either:

• From the Fabric Studio using Deploy to Server.
• Offline Deploy by creating the artifacts in the Fabric Studio using Build Deploy Artifacts and running the deployment on the server side.

When a Fabric object is deployed to the server, the deployment artifacts are created in the /storage/lu directory of the Fabric server – one ludb.jar for each deployment. A folder is created under /storage/lu for each object’s first deployment. For example, when the CRM LU is deployed for the first time, the CRM folder is created under /storage/lu. The /storage/lu/CRM will include the folder named as the deployment time and will include the ludb.jar.

Note that Shared Objects are not independent objects in a project and therefore cannot be deployed as stand-alone items. You must re-deploy the object using the updated Shared Object to make the change in a shared object available in the Fabric server. For example, when an interface is updated, all LU using this interface should be re-deployed to make this change effective.

How Do I Check Which Project Is Deployed to Fabric?

Only one project can be deployed to each Fabric cluster. If a project has been deployed and an attempt to deploy a different project to the same cluster is made, an error message is displayed.

To check the project’s deployment in the Fabric server, use the SET command from the Fabric console.

Syntax:

set;

This command displays the currently deployed project name, as well as the values of various project parameters.

Click for more information about Fabric Basic Commands.

How Are Deployed Objects Reflected in the Fabric Server?

You can check which objects are deployed in the Fabric server using the Fabric LIST command.

• list LU_TYPES/LUT, provides a list of LU Types deployed to the Fabric server and can display an LU's storage type. This command can be invoked for all deployed LU Types or for a specific one.
• list WS, provides a list of all Web Service methods deployed to the Fabric server.
• list ENVIRONMENTS/ENVS, provides a list of environments deployed to the Fabric server.
• list BF/BROADWAY_FLOWS, lists all Broadway flows of all LU Types with their inputs and outputs deployed to the server .
• list INSTANCE_GROUPS/IGS, lists all instance groups of all LU Types deployed to the server.
• list DB_SOURCES, lists all the DB interfaces.

Syntax:

    list lut; 
    list lu_types;
    list lut storage=y;
    list ws;
    list ENVIRONMENTS; 
    list ENVS;
    list BF;
    list BROADWAY_FLOWS;
    list IGS;
    list INSTANCE_GROUPS;
    list DB_SOURCES;

Examples:

fabric>list lut storage=y;
|LU_NAME        |STORAGE|
+---------------+-------+
|SummaryExercise|Default|
|Customer       |Default|
|ORDERS         |Default|
|CRM            |Default|

How Are Deployed Objects Reflected in Cassandra?

Project deployment is reflected in Cassandra as follows:

• The deployment of a Logical Unit, References and Web Services creates new records in the k2_lut_info table under the k2system keyspace. A separate record is created for each LU and Reference table and for each deployed Web Service.
• Each deployed LU creates a new Cassandra keyspace named k2view_[LU Name]_[cluster id if exists].
• The first deployed WS creates a new Cassandra keyspace named k2view_k2_ws.

How Do I Get the Deployed Implementation?

After the project is deployed to the server, there might be a need to clarify which code has been deployed in a specific environment. For example, if there are many code changes in the project and you need to verify whether a specific change has already been deployed to the server. Fabric supports the creation of a zip file for a selected LU name, so that the implementer can download the code deployed in the environment and check it.

Syntax:

    http://[host]:3213/lut?lutName=[luname]&token=[token]
    http://[host]:3213/lut?lutName=k2_ws&token=[token]
    http://[host]:3213/lut?lutName=k2_ref&token=[token]

The outcome of this command is that ludbXMLs.zip is downloaded to your local machine and can be opened in the Studio.