Changes for page 185 - Get ready
Last modified by Carlijn Kokkeler on 2024/04/18 13:22
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -10,8 +10,15 @@ 10 10 [[image:Main.Images.Release Blog.WebHome@185 - Release blog 1.png]] 11 11 12 12 ==**Next Generation Monitoring & Alerting engine**== 13 -In the recent sprints, we have completed our alerting & monitoring engine for our new runtime architecture. Effectively that means that we are now used State Generation components inside this architecture, and all error messages, runtime metrics and logging are now passing through this engine. All of our regular Manage phase screens have been updated to point to the new storage locations. In the Manage phase we have introduced proper means to toggle between data of the current and the new monitoring stack (transition to the new runtime can be a runtime by runtime approach). We have already released and described the new Manage phase graphs in [[Release blog 183>>https://docs.emagiz.com/bin/view/Main/Release%20Information/Release%20Blogs/Rainbow%20World||target="blank"]]13 +In the recent sprints, we have completed our alerting & monitoring engine for our new runtime architecture. Effectively that means that we are now used State Generation components inside this architecture, and all error messages, runtime metrics and logging are now passing through this engine. All of our regular Manage phase screens have been updated to point to the new storage locations. 14 14 15 +* In the Manage phase we have introduced proper means to toggle between data of the current and the new monitoring stack (transition to the new runtime can be a runtime by runtime approach). 16 +* We have also released and described the new Manage phase graphs in [[Release blog 183>>https://docs.emagiz.com/bin/view/Main/Release%20Information/Release%20Blogs/Rainbow%20World||target="blank"]]. 17 +* In the new architecture all error messages are automatically send to the eMagiz monitoring & alerting stack, which means that these flow components are no longer required. During migration these will be removed. In case custom error handling is required, these components are made available in the Create Store and will point to the current error flow (which serves a new purpose from then onwards) 18 +* Hosted SOAP Webservices can be migrated to the new architecture which removes the need to use the Jetty component, and introduces the request layer as root element in the System Message. This removes the need for custom XSD to validate incoming request to the SOAP webservice. The new HTTP Statistics page can be leveraged to review SOAP traffic as well. 19 +* The Docker Cloud templates are now also connected to the eMagiz support infrastructure providing cloud instance level alarms 20 + 21 + 15 15 === **Improvements** === 16 16 17 17 * Performance Deployment plan ... ... @@ -22,6 +22,11 @@ 22 22 23 23 [[image:Main.Images.Release Blog.WebHome@185 - Release blog 2.png]] 24 24 32 +* Store 33 +We have fixed several smaller Store import issues to improve the user experience. Furthermore, we have released several Store items that can be used in the Design Store and which include complete data models and transformations. See the list below of the components that have these. 34 + 35 +[[image:Main.Images.Release Blog.WebHome@185 - Release blog 3.png]] 36 + 25 25 == **Fancy Forum Answers** == 26 26 27 27 As always, a gentle reminder to all to ask questions via the Q&A forum. The Q&A forum is available in the eMagiz iPaaS portal, so we can all benefit from the knowledge within the community. For some inspiration, take a look at these forum answers: