Which of the below is NOT a reason why application Architecture is important when building quality software solutions? Drives Consensus : Helps create common ground with the team Manages Complexity : Helps reduce emerging complexity by focusing on relevant properties and omitting irrelevant details, thus leading to simpler representation Reduces Risk : Architecture is a cost effective way to mitigate substantial risks and ensure success Supports Planning : Helps the team anticipate and build solutions Facilitate Change : When something comes up that requires you to veer from the original design or path, architecture of your system can show you exactly what needs to change and help with communication and planning. Reduces Costs : Architecture benefits are not only technical, but affect how you operate Helps Communication : Helps you to get buy in from the business and to communicate overall plan to them.
ISO/IEC 9126:1991 included several different dimensions. Which is NOT part of ISO/IEC 9126:1991? Usability : Usability from the point of view of the users Functionality : Functionality as a set of functions that satisfy needs Efficiency : Efficiency which relates to the performance to the amount of resources used Maintainability : Maintainability which relates to the effort needed to make modifications Portability : Portability which defines the ability to move software between environments Reliability : Reliability which ensures that a software solution can maintain it performance over a period of time Security : Security which relates to the strength of the of the software against cybersecurity attacks.
ISO/IEC 25010:2011 adds two more aspect to ISO/IEC 9126:1991. Which of the below is not part of it? Security : Security ensure software solutions can protect information and data Compatibility : Compatibility was also added as a way to ensure that a piece of software can work together with other systems Integration : Integration to allow data exchange with other software.
What does NOT happen due to a lack of architecture concerns? Poor service abstraction : Business concepts not correctly isolated, business rules tend to be spread over different systems and little to no code reuse Unmanageable dependencies : System not isolated from each other. Updating or replacing a system has a cascade/snowball effect on other systems Inflexible and slow-moving legacy systems : adapting legacy systems to business changes may be difficult. Changes in complex and inflexible systems can take a long time Tech Debt : AI Mentor will raise architectural tech debt such as cyclic dependency and side to side dependency.
"Spaghetti Architecture" is also known as 'tightly coupled architecture' or 'brittle architecture'. Which is NOT a reason why is "Spaghetti Architecture" bad? Hinder future changes as they become less flexible and difficult to manage One small change in a component cause a series of cascading effects on other components Any changes is maintainable and easy to deploy.
Which of the following is a benefit of having good architecture? Unmanageable dependencies Poor service abstraction Slow-moving legacy systems Manages complexity.
Which of the following is NOT a benefit of having well-defined application architecture? Reduces costs Reduces risk Poor service abstraction Supports planning.
The Architecture Canvas is a ... framework to support application architecture design in Outsystems framework to support Architecture Design Process in Outsystems framework to support Architecture Conventions for Modules in Outsystems.
Architecture Canvas has 3 layers. Which is not part of the 3 layer framework? Ochestrator End-User Layer Core Foundation.
Foundation may have non-business services and business services in them TRUE FALSE.
Which is not a reason you should use Architecture Canvas? Promotes abstraction of reusable services Optimizes lifecycle independence Minimizes impact of changes Promotes segregation and loose coupling of services.
In the Architecture Canvas, where should the API module sit in? End-User Layer Core Layer Foundation Layer.
Which of the below is NOT part of the three step process of Architecture Design Process? Disclose Organize Assemble Shape.
Which are NOT part of the major concepts that needs to be investigated in the Disclose phase in Architecture Design Process? User Stories, Personas and Roles Information Architecture Integration Technology User Experience Expectations Architecture Canvas Modules.
What is done in the Organize part of the Architecture Design Process? Concepts are added to the layers of the Architecture Canvas Concepts are disclosed to the Architecture team Concepts are assembled into Modules.
Concepts are assembled into Modules in the Assemble step of the Architecture Design Process. Which are not principles in the Assemble step. Join conceptually-related concepts Don't join concepts with different lifecycles Isolate reusable logic from Integration logic Apply known design patterns N/A.
What is the Architecture Blueprint? Is the end result of Architecture Design Process. At this point you should add dependencies between the Modules. Above is the answer.
Of the options below, which one is a benefit of adopting the Architecture Canvas? It's a systematic approach to architecture design It's an automatic way to find and fix architecture issues. It promotes the business users' collaboration and understanding It's a faster architecture design.
The Architecture Canvas is a multi-layer framework. Which of the following is NOT a benefit of this framework? It promotes a correct abstraction of reusable services. It optimizes lifecycle independence. It identifies possible performance bottlenecks. It minimizes the impact of changes.
The Architecture Design Process has three steps. Which of the options below is NOT one of those steps? Organize Plan Assemble Disclose.
Which of the following is an Assembling principle? Disclose business concepts and integration needs. Join all integrations into a single Module. Isolate all business concepts. Keep concepts with different lifecycles apart.
Which of the below is NOT a reason for adopting Naming Conventions for Modules Reveal nature of each module Enforce the reference architecture Normalize known patterns Ensure it belongs to the correct layer.
_Lib module is for Generic Library module Technical wrapper to consume and normalize an external service have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). Theme, look & feel elements, menu, etc. Reusable UI Patterns for layout and display only - no Business logic. Reusable Core Services with public entities, actions, and blocks.
_IS module is for Generic Library module. technical wrapper to consume and normalize an external service. several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). Theme, look & feel elements, menu, etc. Reusable UI Patterns for layout and display only - no Business logic.
_Drv module is for Generic Library module. technical wrapper to consume and normalize an external service. to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). Theme, look & feel elements, menu, etc. Reusable UI Patterns for layout and display only - no Business logic.
_Th module is for Generic Library module. technical wrapper to consume and normalize an external service. to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). Theme, look & feel elements, menu, etc. Reusable UI Patterns for layout and display only - no Business logic.
_Pat module is for Generic Library module. technical wrapper to consume and normalize an external service. to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). Theme, look & feel elements, menu, etc. Reusable UI Patterns for layout and display only - no Business logic.
_CS modules is for Reusable Core Services with public entities, actions, and blocks. Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
_BL module is for Reusable Core Services with public entities, actions, and blocks. Isolated Business Logic (Actions), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
_CW module is for Reusable Core Services with public entities, actions, and blocks. Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
_Eng module is for Reusable Core Services with public entities, actions, and blocks. Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
_Sync module is for Reusable Core Services with public entities, actions, and blocks. Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
_API module is for Reusable Core Services with public entities, actions, and blocks. Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle. A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions. Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system. Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.
What is the common naming convention for a mobile version of a CS module? M_CS m_CS mobile_CS _CS m_cs.
OAPI is different compared to API. What is inside an OAPI? Service Action REST API.
Adopting a naming convention can have some benefits. Of the sentences below, which one is NOT a benefit of adopting a naming convention? Reveal the nature of each Module. Enforce the reference architecture. Avoid error codes. Normalize patterns.
Consider the following Module names and the suggested naming conventions for Modules. Which of these is a mobile Module? Mobile_API Customer_CW Pricing_MBL Service_CS.
In which Architecture Canvas layer do you expect to have a higher reusability rate? End-User layer Core layer Foundation layer.
Themes and Layouts are an important element of an application. In which of the following would you define these elements? MyApp_CS Module, in the Foundation layer MyApp_Th Module, in the End-User layer MyApp_MTh, in the Foundation layer. MyApp_BL, in the Foundation Layer.
Which of the following Data elements can we find in a Foundation layer Module? CRUD actions for Entities Non-core Entities Entities to save UI states Core Entities (exposed as read-only).
Which of the following Data elements can we find in a End-User layer Module? CRUD actions for Entities Non-core Entities Entities to save UI states Core Entities (exposed as read-only).
What is Application Composition Process? Process to package modules into apps Answer is the above.
In OutSystems, a Core Application can contain ... End-User, Core, and Foundation Modules. End-User and Core Modules. Only Foundation Modules. Foundation and Core Modules.
In OutSystems, a Foundation Application can NOT contain ... Core Modules and Foundation Modules. End-user and Core Modules. End-User and Foundation Modules.
In OutSystems, an application with Foundation, Core, and End-User Modules is a ... End-User Application. Core Application. Foundation Application.
Which of the below is NOT a reason for Validating a Modules' Architecture? Promotes abstraction of reusable services Optimizes lifecycle independence Minimizes impact of changes Avoid poor service abstraction Stop unmanageable dependencies Prevent slow deployments, inflexible legacy systems Promotes microservices.
Which of the below is not part of the Architecture Validation No Upward References No Circular References No Side References Between End-User Modules No Downward References To Foundation Modules.
Which of the below are not recommendations for Architecture Validations No front-end screens in Core Modules All public entities in Core Modules should be set to Read-only No business logic in the Foundational Modules No screens in the End User Layer No core entities in Foundational Modules.
Which of the below is not part of the Architecture Validation Rules? Layer Modules Correctly Layer Applications Correctly Don't Mix Owners Don't Mix Sponsers : Split the Apps based on the Lines of Business Layer Entities Correctly.
Which of the following recommendations should be applied to the Core layer? Core modules should have public Read-only Entities. Core modules should have Front-end Screens for testing purposes. Core modules should not have business logic. Core modules should not have Core Entities.
Regarding Validation Rules for application composition, which of the following sentences is correct? If you follow all the rules for validating modules, your application composition will be sound, and easy to maintain and deploy. Applications in the Foundation layer can reference Applications in the End-user layer. Owners of the Application should not be mixed, but mixing Sponsors has no direct impact on the release. Common modules and services should be isolated in a separate app that can be referenced by other apps.
What is the new name for Architecture Dashboard? AI Mentor Architecture Canvas Architecture Framework Architecture Validation.
Considering Architecture Dashboard(AI Mentor), which of the following sentences is FALSE? Architecture Dashboard performs a code analysis that uncovers patterns related to performance, security, architecture and maintainability. Architecture Dashboard allows you to automatically apply a solution to solve a found code pattern.
Considering Discovery, which of the following sentences is FALSE? Discovery allows you to determine for every module, which elements are being consumed by other modules. Discovery automatically assigns a module to an Architecture Canvas layer, following the module's naming convention. Discovery only validates architecture rules at the module level. Discovery cannot categorise modules to domains.
Which of the below matches the most to Library Module Pattern - Extension Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. Entity is exposed as read-only and API is available to centralize business logic for entity creation/update Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Library Module Pattern - Connector Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - Core Entity Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - Base ECS Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS with Local Replica Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS with Isolated Synchronization Logic Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS with Direct Integration Pattern... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS with Publish/Subscribe through ESB... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) Same as ECS with direct integration, but through an Enterprise Service Bus ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS Summary Cache only variation ... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below matches the most to Core Module Pattern - ECS Lazy Load variation ... ... a wrapper used to contain the logic, actions and data that will expose code that is inside of external library or to inspect external database and import the data structures so they can be used as entities inside of OS ... is a pattern with two modules, a connector module that can be used to encapsulate an external API with the input/output structures and a wrapper module to expose the normalized API to the consumers. ... Entity is exposed as read-only and API is available to centralize business logic for entity creation/update ... Entity is not in Outsystems but in an external ERP system. IS just makes remote call to external system/database. No data is being kept inside OS. Data retrieval may not be optimized as it needs to traverse two different systems to get the information back. Con: Integration API must support all use cases Same as Base ECS pattern, but have a local replica. Store data to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on source system Same as ECS with local replica but synchronization logic is separated. Pro: Code independence. Consumers of CS is not affected by Sync. Sync can orchestrate several CS Same as ECS with local replica but API module is provided. So any changes to the external system can notify OS, which OS then gets update from the ERP system (subscription system) ... caches only summary data that is frequently lister, joined or searched. Full detail for a single entry is fetched directly from external system. Use when whole database too big or costly to synchronize. Details are only required for single entities (not lists) ... tries to fetch data from local cache entity, if not there, get single entry from the external system. Cache only that record (read-through caching) Use when whole database too big or costly to synchronize. Integration only touches a small portion of the database. Avoid if access to lists of data is needed up front ... is needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data.
Which of the below best matches this statement : "Needed if data is coming from MULTIPLE external systems. IS will decide which driver to use depending on the data." Library : Extension Pattern Library : Connector Pattern Base ECS pattern ECS with isolated synchronization logic ECS with direct integration ECS with publish/subscribe through an ESB ECS Summary cache only variation ECS Lazy Load variation Transparency Service Pattern Transparency Service Pattern 1 way (simplification).
What is a best practice for Mobile Application Architecture: Local Storage? Have a local storage inside the CS Module instead of M_CS Module Do not use local storage(mobile device), instead try to use central storage(server side) Use a centralized local storage for all mobile applications to ensure maintainability Map server side static entities into local entities.
What is NOT a best practice for Mobile Application Architecture: Limit server side calls? Limit Server side calls to online transactions or Synchronization. Do the bulk of the operations on the Client Side before passing information to the Server Side. No direct calls to backend systems. Do call to Outsystems Core Services and Outsystems will handle the interaction with external backend systems.
Direct calls is bad from Security, Performance and Maintainability standpoint. Direct calls will require javascript Code and javascript Code is harder to maintain. Synchronize on every screen or online event for better granularity.
What is NOT a best practice for Mobile Application Architecture: Local Storage? Sync on every screen or online event Adopt the correct sync frequency: Either at process start and online or at process/transaction end and online Sync data required per use case: Sync summary data on Session start. On data selection, sync its details.
Example: if you are accessing Purchasing data, sync the summary data on Session start. On selecting the Purchasing item, sync the details of the Purchasing item such as photos or price.
What is NOT a best practice for Mobile Application Architecture: transactions & granularity? Have long synchronizations in a single transaction. Better UX as app does not need to sync all the time. Is prepared for constant offline or device standby Ensure order and sync granularity. Sync incrementally by entity with partial commit. This way synchronizations is prepared for constant interruptions and allow retries without repeating the entire synchronization from the start.
"Splitting UI elements per functionality" is a best practice to avoid monolithic mobile UI modules? Which of the below is not a best practice? Screens as layouts that have placeholders and load content from blocks. The blocks come from CW modules. Blocks grouped in functional modules with independent life cycles Include the Common flow and Menu artifacts Put CSS in blocks or screens. Allows better performance and seamless screen transitions CSS should only be placed in the mobile theme module.
Which of the below is not a best practice for mobile security:authentication? Authentication : Use google or facebook for online authentication or fingerprint or pin for offline authentication Store password in local storage Encrypt (only) sensitive data.
SSL Pinning is a security best practice for mobile application. Which of the below is FALSE about SSL Pinning? SSL Pinning or HTTP Public Key Pinning (HPKP) helps reduce man-in-the-middle attacks Works on the client side and adds verification of the server certificate against hashes of public keys, which are pre-bundled with the mobile app All of the above are true SSL Pinning does not mean hardcoding the public key into the code.
Which of the below are FALSE about UI framework? Theme - for the look and feel of your applications, which includes screen layouts, global stylesheet and grid definitions. Contains CSS styles and classes. Templates - Defines the structure of the application modules. Templates contains screen definitions and basic set of functionalities, including authentication.
Contains common layouts, menu, login and reference to the theme. Patterns - are blocks that provide common and reusable UI. Chat message, date picker and carousel are a few examples. Contains reusable UI components. All of the above are true.
There are generally 4 common style guide scenario. Which of the below is NOT a common style guide scenario? Built-in Style Guide: Uses Built-in style guide from Outsystems UI. Minor customizations to the Base Theme should be done inside the App Theme. Specialize a Built-in: Use when introducing changes to an existing theme for multiple apps. First, create a custom theme that REFERENCE the Base Theme. Second, clone a Custom Template from the Base Template but this custom theme will reference the custom theme created previously. Third, create new applications based on the Custom Theme and Custom Template Clone a Built-In: Use when introducing extensive changes to existing theme. First, CLONE a custom theme from a Base Theme. Second, clone a Custom Template from the Base Template but this custom theme will reference the custom theme created previously. Third, create new applications based on the Custom Theme and Custom Template.
Base Theme can be Outsystems UI or your own custom theme. Build Your Own: Use when custom style guide cannot benefit from any existing theme. Just like Clone a Built In scenario, clone both Custom Theme and Custom Template from the Base Theme and Base Template, however clone the Base Theme from Outsystems UI.
Since the theme is very basic, front-end developer will have to expand and design the theme from there. Modify Built-in Style Guide: Use when only small changes are required for single application. First, create a custom theme that REFERENCE the Base Theme. Second, clone a Custom Template from the Base Template but this custom theme will reference the custom theme created previously. Third, reference that application to the custom Theme and Template.
There are 3 common scenarios for Sharing a Style Guide. Which of the below is not part of the scenario. Independent Apps : Own Menu, Own Login Flow. Login and Menu is defined in the Custom Template. Applications reference to its own Application Theme thus do not use the Login and Menu in the Custom Template. Intranet (Single Sign On): Own Menu, Common Login Flow. Menu is defined in the Custom Template, but Login is defined in the Custom Theme. Application reference the Custom Them which picks up the Login. Portal : Common Menu, Common Login Flow. Login and Menu is defined in the Custom Theme. Application Theme reference the Custom Theme thus have a shared menu and login flow. Enterprise Apps: Common Menu, Common Login Flow. Menu is defined in the Custom Theme, but Login is defined in the Custom Template.
In which of the following scenarios should you choose to clone a built-in Style Guide? When it is not possible to benefit from any existing theme and extensive changes are needed. When minor customizations to the base theme should be done inside the app theme. When you want to introduce extensive changes to an existing theme. It is not possible to customize a built-in Style Guide, since it is part of OutSystems UI.
Consider the common style guide scenarios presented in this course. Which of the following statements is true? The "specialize a built-in Style Guide" scenario should be used when the changes to the base theme are not extensive. Build-your-own Style Guide should be used when the changes in the theme are not extensive. The "clone a built-in Style Guide" should be used when you want to extend an existing theme.
.
Elements such as the menu and login can be shared across different apps. In a specific use case, both the menu and login are defined inside the theme. Which use case is this? Portal Independent Apps Intranet.
Which of the following options denotes the advantages of defining a Style Guide up front? Security and scalability. Improve performance and maintainability. Speed up the development phase. Allows apps and the Style Guide to be deployed to Production.
Which of the below is NOT a weak dependency as of OS11? Screens Service Actions Database Entities Local Storage Entities Static Entities Structures Server Actions.
Which of the below is NOT a suitable advice for designing a LIGHTWEIGHT mobile local storage? Denormalize the local storage Group relevant information Define only used attributes Store all records no matter if relevant or irrelevant.
Which of the below is NOT a suitable advice for designing a Parallel mobile local storage? Allow table dependency : Normalize tables to promote parallel data fetch Avoid generic tables : Contains too much data, not all are relevant Use Fetch Data : Avoid cascading aggregates in OnInitialize and OnReady.
Which of the below is NOT a Synchronization Best Practice for mobile application? Do not use Entity Bulk Operation to ensure small lightweight updates Only synchronize delta : Use control timestamps Only synchronize relevant data Don't sync on every screen or online event Sync only when required.
At session start: sync summary data to local storage
At process start: sync process detail to local storage
At process/transaction end, sync back to server Sync only when strictly required Avoid long synchronization in a single transaction Ensure sync granularity: Prepare for constant retries without repeating work due to network loss. Sync in chunks, incremental by entity.
Which of the below is NOT a disadvantage of having a fragmented system or microservices? Inter-process communication : network latency and hiccups Multiple transactions committed independently Fault tolerance : communication errors, service consistency Limited data mashup in memory and limited to APIs Security : need to manage credentials and access management Complicated Debugging and troubleshooting : root cause may be deep inside the chain of services Monitoring & Logging : for effective monitoring & logging, requires centralized service All of the above.
|
