Project Deployment and Execution
Last updated
Last updated
In order for the project to become available for use and further integration, it is necessary to deploy it. As a result of creating a project deployment, a Java application is built up and endpoints are formed for each flow.
To deploy a project, the user should click the gray Run button with the Play symbol at the top center of the IDE. The build process of the project is initiated. The button changes its state and a green progress bar appears. Please wait for the process to finish. If there are any errors during the project build, please contact technical support.
The user can start the deployment if at least one flow has been previously created.
There is a grey Loading symbol instead of the Play symbol. This means project deploy is in progress, wait for it to be completed.
If the Run button is initially red, that means that the project can’t be deployed. You need to go to the error panel and make fixes to the project. Then try again.
If the deployment process was successful, the user sees a green button with a Pause symbol. Test Helper and Debug become available after a successful run or build of the project.
If the project was deployed, but the user made changes to the project that caused errors, the Run button turns red with an update symbol.
If the project was deployed, but the user made changes to the project, the deploy button is blue. To start deploying the project with changes, refresh the deployment by clicking the Run button.
To fork a project means creating a copy of the project's source code to use it independently of the original project. You create a separate branch of the project to familiarize yourself with the functionality and be able to reuse or modify it without affecting the original project.
To go to the Test Helper, the user should click on the corresponding button if it is available.
To go to the Debug, the user should click on the corresponding button, if it is available, to the left of the green button with the Pause symbol.
After the successful deployment of the project, the user can get the project data in a convenient form for further use and integration.
To do this, in the top panel of the IDE, select the Project section. After that project Export.
The following export types are available:
Project Instance (only for on-premises installations) — a project presented in the JSON format in accordance with a predefined file structure. The exported Project Instance can be reused by the user in the system via import.
JAR (Java Archive) — is a package file format typically used to aggregate many Java class files and associated metadata and resources into one file to distribute application software or libraries on the Java platform. Users can run a JAR file using Java 11.
WAR (Web Archive) — is an archive that contains all the parts of a web application: Java class files for servlets and web services, and other resources.To deploy a WAR archive, the user can use Apache Tomcat or Wildfly 14.0.1.
Source code — is an archive that contains the pure Java code of an application. It is necessary to create a copy of the project in the form of source code, which can be used in other development environments or shared with other developers.
Swagger — is a project used to describe and document RESTful APIs. The Swagger specification defines a set of files required to describe such an API. As part of the platform, the user receives SwaggerUI, which contains requests to the API, which can be used for integration with other services.
WSDL — is an XML notation for describing a web service. A WSDL definition tells a client how to compose a web service request and describes the interface that the web service provider provides.
Project Instance is always available for export, and Swagger or WSDL is available only after project deployment.
To get the project in a certain view for use, the user needs to click on the required view.
To interact with a deployment via an external system or application (for example, Postman), the user needs to add a binding URL and Access Key to their request.
A binding URL typically consists of a base URL of the deployment and a path that identifies an endpoint (flow) to be accessed.
To get a base URL, export the project to Swagger and copy a base URL.
Also in the SWAGGER you can find all available endpoints for the project, use /eval endpoint to send a request to perform in the flow.
The Access Key is stored in the deployment settings within the Deployment section of the Home application. The administrator and owner can get the Access Key. To start the flow you need to add its value to the header of the request as an API-Key to receive access.
To deploy a JAR or WAR file, you can do so on either a remote server or a local machine.
Steps:
Install an application server.
Download the JAR or WAR file.
Launch the JAR or WAR file using Java and define variables.
To ensure the successful deployment of JAR and WAR archives exported from the system, specific environment variables need to be set:
crypto.rsa.key.public
crypto.rsa.key.private
RSA keys should be defined even if variables are set for the DB Connector password but they won't use. It is also possible to set the following variables for the DB Connector:
project.connector.<connector name>.connection.jdbcUrl
project.connector.<connector name>.connection.username
project.connector.<connector name>.connection.password
For Rest Connector:
project.connector.<connector name>.connection.baseurl
Additionally, the project-specific variables can be set: :
prmix.project.var.<project short id>.<variable name>
These variables should be configured in the configuration files of the application server, such as Tomcat or WildFly. If you are using a Standalone server, you can add these variables to the standalone.xml configuration file, which contains all the necessary environment variables that need to be set before starting. This ensures that the application server has access to these variables during runtime, enabling proper functionality of the deployed JAR or WAR files.
For optimal functionality, it's recommended to utilize WildFly 14.0.0.1 Final with servlet-only configuration.
Use "_" instead of "." for environment variables. The use of dots in variables is for Windows Operating Systems.
Some variables are responsible for connecting the timeout to the application.
REST_ENDPOINT_REQUEST_TIMEOUT - the only variable available for client (application) configuration used for the generated application. It sets the maximum duration of one HTTP request to an application.
There are HTTP internal client settings used to communicate with external REST services. If the model uses a REST connector to an external system, the application uses the REST client to send and receive messages from that connector. The connector can fine-tune the settings (if the external system is slow, you can manage it). HTTP Integration variables - configuring the Internal Client to interact with external REST services. You can add them to the application to fine-tune the connectors inside the model.
HTTP_INTEGRATION_RETRY_ENABLE - The retry command controls whether to enable the logic for the retransmission of previously sent outbound messages that are not acknowledged. It has a boolean type: "true" for retrying requests that were sent and "false" for not retrying.
HTTP_INTEGRATION_RETRY_MAX_RETRIES - the max-retries command specifies the maximum number of attempts to retransmit a failed message. This command is relevant only when the value set by the retry command is on.
HTTP_INTEGRATION_INTERVAL - The retry-interval command sets the number of seconds to wait before the sender retransmits a message. This command is relevant only when the value set by the retry command is on.
HTTP_INTEGRATION_REQUEST_SENT_RETRY_ENABLED - The retry command controls whether to enable the logic for the retransmission of previously sent non-idempotent requests. It has a boolean type: "true" for retrying non-idempotent requests that were sent and "false" for not retrying.
HTTP_INTEGRATION_CONNECT_TIMEOUT (Connection Timeout): This timeout specifies the maximum time that a client (such as your web server or application) has to connect to a remote server. If no connection is established within this time, an error occurs, typically indicating that the server you are attempting to reach is either unavailable or busy.
HTTP_INTEGRATION_CONNECTION_REQUEST_TIMEOUT (Connection Request Timeout): This timeout specifies the maximum timeout for requesting a connection to a remote server. It measures the time the client waits until the remote server accepts the connection request. If the server does not accept the connection within this timeframe, an error will be generated.
HTTP_INTEGRATION_SOCKET_TIMEOUT (Socket Timeout): This timeout determines the maximum timeout for reading data from a socket after a successful connection has been established. If the data is not received within this time, the socket may be closed, resulting in a read error.
On the server, these settings have the following default values:
REST_ENDPOINT_REQUEST_TIMEOUT:15
HTTP_INTEGRATION_RETRY_ENABLE: true
HTTP_INTEGRATION_RETRY_MAX_RETRIES: 3
HTTP_INTEGRATION_INTERVAL: 3000
HTTP_INTEGRATION_REQUEST_SENT_RETRY_ENABLED: false
HTTP_INTEGRATION_CONNECT_TIMEOUT: 420.000 mc (7 minutes)
HTTP_INTEGRATION_CONNECTION_REQUEST_TIMEOUT: 420.000 mc (7 minutes)
HTTP_INTEGRATION_SOCKET_TIMEOUT: 420.000 mc (7 minutes)\
If necessary, you can change the values for variables on the application server.
