Deploying a Fabric Project

What Is Fabric Deployment?

The implementation of a Fabric project can be divided into 2 on-going 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 in a way that 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 and Graphit and it is required whenever these objects are created or modified.

The deployment of a Fabric project is performed on the following levels:

  • Deployment of Logical Units, each LU is deployed separately.

    • When needed, a deployment can be performed on a specific LU only if the 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 from either one of the below two locations:

  • The Fabric Studio, using Deploy to Server.
  • The Fabric server, using an Offline Deploy, an act that refers to deploying the artifacts that were created in the Fabric Studio, by choosing Build Deploy Artifacts.

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.

Soft Deploy

Soft Deploy is Fabric's ability to exclude automatic processes from the LU deployment. Soft Deploy is mostly useful for implementors that work in a development environment and that frequently change their code, such as Broadway flows or Java functions.

You can use the Soft Deploy option to deploy changes without triggering automatic processes such as:

  • User jobs
  • Parsers
  • Interface listener

Moreover, when the Soft Deploy is used, the deploy.flow is not running.

To activate the Soft Deploy when deploying from the Fabric Studio, mark the Soft Deploy checkbox in the User Preferences > Server Configuration window.

To activate the Soft Deploy during the Offline Deploy, set the SOFT_DEPLOY optional parameter to TRUE.

To activate Soft Deploy, right-click on a Logical Unit name, and select Soft Deploy.

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 (click this icon from next to Fabric in the Debug Panel to open the console):

To check the project’s deployment in the Fabric server, use the SET command from the Fabric terminal (Choose Fabric -> Open Fabric Terminal)

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 by 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 either 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:

    • If LU_NAME is supplied, the command lists only Broadway flows belonging to the LU.
    • If FLOW is specified, the result shows a row for each input and output argument of the flow, along with their type and schema. If more than one flow is found with the same name, the result will be a list of LUs. Specify the LU_NAME to ensure that a single flow is found.
  • list INSTANCE_GROUPS/IGS, lists all instance groups of all LU Types deployed to the server.

  • list DB_SOURCES, lists all the DB interfaces.

  • list INTERFACES, lists all the 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;
    list INTERFACES;

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 may 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. For this purpose, Fabric supports the creation of a zip file for a selected LU name, enabling the implementor to download the code deployed in the environment and to 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.

Deploying a Fabric Project

What Is Fabric Deployment?

The implementation of a Fabric project can be divided into 2 on-going 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 in a way that 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 and Graphit and it is required whenever these objects are created or modified.

The deployment of a Fabric project is performed on the following levels:

  • Deployment of Logical Units, each LU is deployed separately.

    • When needed, a deployment can be performed on a specific LU only if the 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 from either one of the below two locations:

  • The Fabric Studio, using Deploy to Server.
  • The Fabric server, using an Offline Deploy, an act that refers to deploying the artifacts that were created in the Fabric Studio, by choosing Build Deploy Artifacts.

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.

Soft Deploy

Soft Deploy is Fabric's ability to exclude automatic processes from the LU deployment. Soft Deploy is mostly useful for implementors that work in a development environment and that frequently change their code, such as Broadway flows or Java functions.

You can use the Soft Deploy option to deploy changes without triggering automatic processes such as:

  • User jobs
  • Parsers
  • Interface listener

Moreover, when the Soft Deploy is used, the deploy.flow is not running.

To activate the Soft Deploy when deploying from the Fabric Studio, mark the Soft Deploy checkbox in the User Preferences > Server Configuration window.

To activate the Soft Deploy during the Offline Deploy, set the SOFT_DEPLOY optional parameter to TRUE.

To activate Soft Deploy, right-click on a Logical Unit name, and select Soft Deploy.

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 (click this icon from next to Fabric in the Debug Panel to open the console):

To check the project’s deployment in the Fabric server, use the SET command from the Fabric terminal (Choose Fabric -> Open Fabric Terminal)

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 by 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 either 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:

    • If LU_NAME is supplied, the command lists only Broadway flows belonging to the LU.
    • If FLOW is specified, the result shows a row for each input and output argument of the flow, along with their type and schema. If more than one flow is found with the same name, the result will be a list of LUs. Specify the LU_NAME to ensure that a single flow is found.
  • list INSTANCE_GROUPS/IGS, lists all instance groups of all LU Types deployed to the server.

  • list DB_SOURCES, lists all the DB interfaces.

  • list INTERFACES, lists all the 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;
    list INTERFACES;

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 may 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. For this purpose, Fabric supports the creation of a zip file for a selected LU name, enabling the implementor to download the code deployed in the environment and to 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.