Core module naming conventions

  1. _CS
    • Reusable Core Service
    • with
      • public entities
      • actions
      • web blocks
  2. _BL, _CW :
    • Isolated Business Logic (Actions)
    • or Core Widgets (Web blocks),
    • to manage complexity, composition or
    • to have its own lifecycle
  3. _Eng:
    • 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
  4. _Sync:
    • Logic to Synchronize data in CSs with an external system.
    • Isolating this logic makes the CS completely system agnostic and
    • it’s easier to decouple or replace the external system.
  5. _API:
    • Technical wrapper to expose an API to External consumers
    • keeping core services system agnostic and
    • supporting multiple versions of the API
  6. Add a “M” for a Mobile only module, like _MCS, _MBL or _MCW

Lifetime

  1. Extends Service Center capabilities to cross environment scenarios
  2. E.g. From Development environment -> QA environment -> Integration environment -> Production environment
  3. We can track applications, versions on each environments

Integration Studio

  1. Development environment
    1. Integrate external resource (data, .Net code extension) into OutSystems platform
    2. Provide a number of wizards and capabilities to represent external resource as a OutSystems component to publish to server
    3. E.g: Import Actions from .NET Assembly
    4. The representation can be used in Service Studio as normal OutSystems resource, even we cannot recognize the difference between internal and external resource.