Search: "deploy architecture"

Should you have any questions in advance, please get in touch with us at [[productmanagement@emagiz.com>>mailto:academy@emagiz.com]]. == **Deploy Architecture - Apply To Environment improvements ** == As of this release, we will show you a list of all changes about to be changed once you press "Apply to the environment" in Deploy Architecture.

The Cloud architecture can be designed in the Design - Architecture section and effectuated via the Deploy - Architecture section. Please check out the microlearnings mentioned below for more information on how to configure these or make the right architecture decisions. **Design Architecture** [[image:Main.Images.Fundamental.WebHome@fundamental_architecture-2.png]] **Deploy Architecture** [[image:Main.Images.Fundamental.WebHome@fundamental_architecture-3.png]] == 4.

New features Deploy - Architecture: We add a new option per container to open a page that you can use a feature "Start / Stop flows" for runtime running on the 3rd generation runtime.

====New features==== * Deploy - Architecture: We add a new option per container to open a page that you can use a feature "Start / Stop flows" for runtime running on the 3rd generation runtime.

For this, a new runtime image is available. Deploy - Architecture: It is now possible to search in the Start/Stop flows overview. (#1311) Manage - Alerting: The new queue triggers feature has been updated to be able to handle redelivery-enabled messaging queues.

For this, a new [[runtime image>>doc:Main.Release Information.Runtime Images.V312.WebHome||target="blank"]] is available. * Deploy - Architecture: It is now possible to search in the Start/Stop flows overview. (#1311) * Manage - Alerting: The new queue triggers feature has been updated to be able to handle redelivery-enabled messaging queues.

Key concepts == * This migration path allows you to maintain your hosted REST web service in the 3rd generation runtime * Consequences of this migration are: ** Your all-entry will be split up into separate entries ** HTTP Settings now need to be configured under Deploy -> Architecture == 3. Technical Migration Path == As part of the "Transfer Settings from Design" step in the general migration path on migrating to the 3rd generation runtime, you will see an additional option displayed below this option called "Split Combined Entries."

{{/warning}} [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--release-overview-splitted-entry-rest-web-service.png]] === 3.5 Check the Runtime Settings === One last step of the migration is to check the runtime settings of the runtime you are migrating under Deploy -> Architecture. This new functionality allows you to define the port on which the REST web service needs to be running (and optionally SSL settings when running it on-premise).

Key takeaways == * This migration path allows you to maintain your hosted REST web service in the 3rd generation runtime * Consequences of this migration are: ** Your all-entry will be split up into separate entries ** HTTP Settings now need to be configured under Deploy -> Architecture == 5. Suggested Additional Readings == * [[Migration Paths (Navigation)>>doc:Main.eMagiz Support.Migration Paths.WebHome||target="blank"]] ** [[eMagiz Runtime Generation 3 (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-emagiz-runtime-generation-3||target="blank"]] * [[Fundamentals (Navigation)>>doc:Main.eMagiz Academy.Fundamentals.WebHome||target="blank"]] ** [[eMagiz Runtime Generation 3 (Explanation)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-runtime-generation3||target="blank"]] * [[Intermediate (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]] ** [[Runtime Management (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.WebHome||target="blank"]] *** [[Runtime Settings (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.intermediate-emagiz-runtime-management-runtime-settings.WebHome||target="blank"]] * [[Host Rest Web Service (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?

This can be done by moving to Deploy -> Architecture and pressing 'Reset H2'. Do remember that resetting the H2 database or removing and readding it will result in a loss of all the data on the database. == 5.

{{info}}After you create a new version of your flow, before you create and deploy a new release, you also need to configure a new route in Deploy>Architecture of your desired environment for the clients (publishers and subscribers) of this MQTT broker to connect.

This holds for releases that are deployed and promoted to a next environment. Deploy - Architecture: The risk level of pending changes is now shown in the pop up that appears after clicking 'Apply to environment'.

This holds for releases that are deployed and promoted to a next environment. * Deploy - Architecture: The risk level of pending changes is now shown in the pop up that appears after clicking 'Apply to environment'.

Key concepts == * This migration path allows you to maintain your hosted SOAP web service in the 3rd generation runtime * Consequences of this migration are: ** Your all-entry will be split up into seperate entries ** Your WSDL will be generated based on your system message ** The system message will be altered based on your configuration in Design by adding a new root entity named Send{givenname}Request ** This alteration of your system message will not impact your transformation towards your data model ** HTTP Settings now need to be configured under Deploy -> Architecture == 3. Technical Migration Path == As part of the "Transfer Settings from Design" step in the general migration path on migrating to the 3rd generation runtime you will see an additional option displayed below this option called "Split Combined Entries".

{{/warning}} [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--release-overview-splitted-entry-soap-web-service.png]] === 3.5 Check the Runtime Settings === One last step of the migration is to check the runtime settings of the runtime you are migrating under Deploy -> Architecture. This is a new piece of functionality that allows you define the port on which the SOAP web service needs to be running (and optionally SSL settings when running it on-premise).

Key takeaways == * This migration path allows you to maintain your hosted SOAP web service in the 3rd generation runtime * Consequences of this migration are: ** Your all-entry will be split up into seperate entries ** Your WSDL will be generated based on your system message ** The system message will be altered based on your configuration in Design by adding a new root entity named Send{givenname}Request ** This alteration of your system message will not impact your transformation towards your data model ** HTTP Settings now need to be configured under Deploy -> Architecture == 5. Key takeaways == * [[Migration Paths (Navigation)>>doc:Main.eMagiz Support.Migration Paths.WebHome||target="blank"]] ** [[eMagiz Runtime Generation 3 (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-emagiz-runtime-generation-3||target="blank"]] * [[Fundamentals (Navigation)>>doc:Main.eMagiz Academy.Fundamentals.WebHome||target="blank"]] ** [[eMagiz Runtime Generation 3 (Explanation)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-runtime-generation3||target="blank"]] * [[Intermediate (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]] ** [[Runtime Management (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.WebHome||target="blank"]] *** [[Runtime Settings (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.intermediate-emagiz-runtime-management-runtime-settings.WebHome||target="blank"]] * [[Host SOAP Web Service (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?

. * The first is to execute a "restart runtime" action via Deploy Architecture or the on-premise server. * Secondly, you could deploy a new version of the infra (via the Releases functionality).