Summary

  • An alternative for heavy integrations with middleware solutions
    • powerdata’s powerintegrations enables customers to integrate different systems according to modern best-practice applications and to implement asynchronous data exchange between systems
  • Cloud-based high available and scalable
    • Implementation of powerintegrations is performed exclusively in Amazon Web Services (AWS). With the serverless deployment, the necessary resources are allocated dynamically and billed only during use, thus achieving high scaling and availability. Exchange of information is organized based on best practices for decoupled architecture across queues; complex integrations are orchestrated in workflows. A high degree of transparency and monitoring is ensured by the powerdata team ensures a high degree of transparency and monitoring. 
  • cost-efficient and customizable
    • using powerintegrations saves customers implementation, maintenance, and hardware costs of middleware solutions, and offers much greater flexibility, scalability, and customizability.

Example integration of powercloud-Events

  1. Configuration
    • Relevant events are defined, mapped and assigned in settings. If needed, additional logic / events are implemented direct in powercloud system
  2. Transfer
    • Events are passed to the powerintegrations’ interface (API Gateways, REST API Post). Simple json filtering, mappings and transformations are done on API level in powerdata system f. e. by using apache VTL
  3. Process
    • Event processing is triggered. Complex transformations for ach event by event type and/or by customer – if customer specific – are done
  4. Assign configuration
    • Configuration for API, event type, client and assigned components / queues is loaded from configuration database
    • Save execution context and events
    • This step is repeatedly executed in subsequent steps
  5. Enqueue
    • Processed events are enqueued as messages with meta attributes and json bodies
  6. Push message (to customer)
    • Messages are delivered to customers’ systems f. e. posted through customers’ REST API (other options are also available)
  7. Pull message (by customer)
    • As alternative to (6), customer systems read their messages from queue through REST API GET. After processing they are responsible to delete messages with REST API DELETE
    • Configuration is read and assigned as in (4)
  8. Push message (to powercloud)
    • customer systems deliver messages to powercloud (f. e. status change in process) through REST API POST. Simple json filtering, mappings and transformations are done on API level in powerdata system f. e. by using apache VTL
  9. Process & enqueue
    • Processing is triggered. Complex transformations for ach event by event type and/or by customer – if customer specific – are done
    • Processed messages from customer are enqueued with meta attributes and json bodies
    • Configuration is read and assigned as in (4)
  10. Push message to powercloud
    • Messages are dequeued and  delivered to powercloud systems f. e. posted through powercloud’s REST API (other options are also available)
    • Configuration is read and assigned as in (4)
  11. Logging
    • Processing information and metrics are permanently saved and can be read by customer (RESP API)
  12. Alerting via email / SMS
    • Customer can be informed / alerted via email and / or SMS f. e. about arrival of events from powercloud or about processing errors
  13. Visualization
    • Visualization of information can be done for customer f. e. of different metrics such as retrieved/processed messages