Search: "deploy architecture"

. === 3.1 How to use it === You can access this functionality via the [["Deploy Architecture">>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-understanding-deploy-architecture-basic||target="blank"]] overview in the Deploy phase.

Suggested Additional Readings == If you are interested in this topic and want more information, please read the help text provided by eMagiz and check out these links: * [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]] ** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]] *** [[Understanding Deploy Architecture - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-understanding-deploy-architecture-basic||target="blank"]] * [[Start Stop Flows (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?

{{container}} {{container layoutStyle="columns"}} ((( In this microlearning, we will focus on how to influence the runtime settings via the Deploy -> Architecture overview. With the help of this functionality, you can configure two settings.

For example, part of these settings is located on the runtime level in Deploy -> Architecture. Executing a right-click while in "Start Editing" mode on a runtime provides you with one of the following context menus.

Key takeaways == * On the runtime level in Deploy -> Architecture, you have a context menu item called "Runtime Settings." * In this context menu item, you can configure the HTTP Settings and whether the control bus is enabled. * HTTP Settings are needed when hosting a SOAP or REST web service. ** When enabling, the port needs to be filled in. ** Optionally, you can configure one-way or two-way SSL for an on-premise endpoint. * By disabling the control bus, you will lose (parts of) the functionality that allows you to view or halt data. ** Queue browser. ** Message redelivery. ** Start/Stop flow components. * Changes must be deployed by creating a new release and deploying it via a deployment plan. == 5.

This guide will help you understand how to make these adjustments within the Deploy Architecture, whether you’re working in the cloud or on-premises.

In cases where all or part of the assumptions are violated, you should determine the correct number and based on that change the settings to mimic your calculations. === 3.1 Deploy Architecture === Editing the memory settings can be done within the Deploy Architecture overview.

Pressing this button will send a command to the eMagiz Cloud to change the configuration of your eMagiz Cloud setup based on the changes made in Deploy Architecture. [[image:Main.Images.Microlearning.WebHome@intermediate-emagiz-runtime-management-configure-needed-memory--deploy-architecture-apply-to-environment.png]] When you open the context menu on the eMagiz cloud slot itself (right mouse click in Deploy Architecture away from the integration landscape overview) you can access the details page [[image:Main.Images.Microlearning.WebHome@intermediate-emagiz-runtime-management-configure-needed-memory--deploy-architecture-cloud-slot-details.png]] On this page, you can track the progress of your update.

Deploy Phase Possibilities == === 3.1 Deploy Architecture === After finishing up your configuration in the Create phase, you can then move to your Deploy>Architecture.

As you might have noticed in the Deploy>Architecture earlier when opening the "Failover" tab in your machines' "Details", there are properties regarding the machines' "Internal IP address" and "Failover port".

To continue failover behavior, please use the steps above in Deploy -> Architecture. ===== 3.5.1.4 Leader (single node) Status ===== The last possible status is Leader (single node).

As you all are working in the same integration data model eMagiz will actualize **all** changes when your colleague presses Apply to Environment in Deploy Architecture. So be aware of when you change things and when you do ensure to communicate with all stakeholders related to the project how you plan to actualize those changes. === 3.4 Design vs Deploy Architecture === In the previous segment, we talked about the impact of changing things in Design Architecture. In this segment, we will look at some scenarios in which the Design Architecture view can differ from the Deploy Architecture view. There are three main reasons why both of them differ: * This is the first time you open Deploy Architecture * This means you need to spin up your cloud infrastructure for the first time * There is no flow related to the runtime embedded in the release * Runtimes won't show up in Deploy Architecture when no flow should be deployed on them within the currently active release * The runtime is excluded in Design Architecture * With this functionality, you explicitly mention that a certain runtime should not be deployed Knowing this should make you better equipped to handle 'unexpected' situations you occur while implementing your data model with the help of the eMagiz platform.

Coordinate with stakeholders to manage changes in Design Architecture and avoid conflicts. * Understand why Design and Deploy Architectures may differ due to setup, dependencies, and exclusions. == 5.

{{container}}{{container layoutStyle="columns"}}((( With this exercise, we learn how to use the "apply to environment" functionality in Deploy -> Architecture. This functionality is a key component in sending changes to our eMagiz cloud to actualize these changes.

To complete this exercise you need to execute the following steps: * Navigate to Deploy -> Architecture * Enter "Start Editing" mode and open the context menu (by clicking on the white area of the canvas) * Select the certificate option and fill in the following things: ** CN Name ** Client Name * Save your changes on certificate level * Open the context menu again and select the route option. * Fill in the following things: ** DNS Left most label ** Port ** Runtime(s) ** Certificate to use * Save your changes == 3.

* Configuration of the SSL configuration (HTTPS, TLS, and client certificates) is done in Deploy -> Architecture * Certificate is generated via the support department (with or without CSR) or the client * No actions are needed on the flow level, only in the Deploy Architecture * You need a valid truststore and keystore to make it work == 3. Securing a hosted web service with certificates on-premise == To secure a web service that runs on-premise with the help of certificates, we need to navigate to Deploy -> Architecture. Here, we have the "Runtime settings" option that allows us to configure SSL options, such as HTTPS, TLS, and client certificates).

[[image:Main.Images.Microlearning.WebHome@intermediate-securing-your-data-traffic-securing-a-hosted-webservice-with-certificates-on-premise--truststore-config.png]] Once configuring your endpoint, clients must provide a client certificate to exchange data. === 3.4 Deployment === To update your configuration, you need to create a new release and deploy it to actualize the changes made for TLS, HTTPS, and client certificate configuration. === 3.5 Recap === Important things to remember are: * Configuration of the SSL configuration (HTTPS, TLS, and client certificates) is done in Deploy -> Architecture * Certificate is generated via the support department (with or without CSR) or the client * No actions are needed on the flow level, only in the Deploy Architecture * You need a valid truststore and keystore to make it work == 4.

Prerequisites == * Basic knowledge of the eMagiz platform * Basic Understanding of certificates * Flow that hosts the web service is successfully created and deployed to the correct environment * Route in Deploy Architecture has been configured for this specific web service == 2.

Important things to remember are: * Configuration on eMagiz Cloud level is done via Deploy -> Architecture * Certificate is generated via the support department (with or without CSR) * No actions are needed on flow level, only on Cloud level * All you need for the configuration is the common name of the certificate Now that we have introduced the topic let us see how to configure the certificate within Deploy -> Architecture.

Key takeaways == * Certificates serve as essential tools for establishing trust between parties by verifying identities, which is crucial for secure communications. * Easily enhance the security of your eMagiz web service in the eMagiz Cloud by configuring it with certificates, ensuring that only authenticated clients can access it. * The main configuration happens at the eMagiz Cloud level through the Deploy -> Architecture section, with no changes needed at the flow level. * When applying changes, ensure you’re aware of other modifications, as they will be updated simultaneously in the eMagiz Cloud. == 5.

. * With "apply to environment", we mean: Actualizing all changes, with an indirect effect, within the eMagiz Cloud that were made by users on the Deploy Architecture canvas after the last press on this button. == 3.

As we saw in previous microlearnings and will see in microlearnings to come with regards to cloud management is that some actions in Deploy Architecture have a direct effect (i.e. Slot Wakeup, Restart Runtime, Reset Runtime, etc.) and others have an indirect effect (i.e.

{{/info}} So, in short, when you execute one (or more) actions on Deploy Architecture that have an indirect effect, you need to press Apply to Environment to actualize the changes within the eMagiz Cloud.

The exact command to run inside the Docker instance is specific for the machine configured inside eMagiz Design & Deploy Architectures. It can be found inside the eMagiz iPaaS portal under Deploy Architecture.

This way, deploying multiple machines from different environments (machines from Deploy architecture) to the same on-premise machine (the 'physical' machine) running Windows Server 2022 as an operating system is possible.