- This project is a collection with out-of-the box engagements data
- This project helps to build docker image with pre-populated Engagements data (your own set of customized Engage Defaults) and can be customized with customer-specific settings
- This project uses technologies broadly used in Backbase, like Docker
This repository contains collections with out-of-the box engagements data. These collections contain the following data:
- Events with general notifications
- Templates (general notifications and custom engagements)
- Repositories (for AWS S3 and Azure Blob Storage)
This repository has the following structure:
├── .github
│ ├── actions # All GitHub Actions files
│ ├── ISSUE_TEMPLATE # Templates for 'major','minor','patch' releases
│ └── workflows # GitHub Actions workflows for CI
└── collections
├── retail # Retail collection
│ ├── general-notifications # General notifications related collection
│ │ ├── event-general-notifications
│ │ │ ├── {event-general-notifications-name}
│ │ │ │ ├── {general-notification-name} # The folder to store channel specific data for general notifications
│ │ │ │ │ ├── in-app-notification
│ │ │ │ │ │ ├── {locale} # The folder to store locale-specific engagement templates
│ │ │ │ │ │ │ └── engagement-template.json # The engagement template that contains default messages with the Handlebars expressions
│ │ │ │ │ │ └── in-app_channel-settings.json # The channel settings for in-app notification channels per locale
│ │ │ │ │ └── push
│ │ │ │ │ ├── {locale}
│ │ │ │ │ │ └── engagement-template.json
│ │ │ │ │ └── in-app_channel-settings.json
│ │ │ │ └── event-general-notifications.json # The event with one or more general-notification definitions
│ │ │ └── ...
│ │ ├── templates # The folder to store templates
│ │ │ ├── {template-name}
│ │ │ │ ├── content-schema.json # A structure of an engagement template based on a given template
│ │ │ │ └── template.json # A template definition
│ │ │ └── ...
│ │ └── placeholders # The folder to store placeholder group
│ │ ├── {placeholder-group-name}
│ │ │ └── placeholders.json # A placeholder group configuration
│ │ └── ...
│ ├── custom-engagements # Custom engagements related collection
│ │ └── templates # The folder to store templates
│ │ ├── {template-name}
│ │ │ ├── content-schema.json # A structure of an engagement template based on a given template (Specifies the path to image as {{contextRoot}}/assets/apple-pay.png)
│ │ │ ├── template.json # A template definition
│ │ │ └── assets # Folder that contains all assets (index.html, image.png, thumbnail.png)
│ │ │ ├── index.html # HTML file with embedded styling, expressions and templating language placeholders that should match the layoutPath property specified in the content schema
│ │ │ ├── image.png # Images that are used within the template
│ │ │ └── thumbnail.png # A representation of the rendered version of your template (recommended size: 164 x 217)
│ │ └── ...
│ ├── engagement-types # The folder to store engagement types definition
│ │ └── engagement-types
│ │ └── engagement-types.json
│ └── repositories # The folder with a repository definition.
│ ├── {repositories-type} # Contains a repository that has a cloud storage (AWS S3 or Azure) as the underlying storage
│ │ ├── {repository-name}
│ │ │ ├── format.txt # Applicable package format
│ │ │ ├── package.txt # List of items to be imported into a repository
│ │ │ └── repository.xml # A repository definitions
│ │ └── ...
│ └── ...
└── business # Business collection
├── general-notifications # General notifications related collection
│ ├── event-general-notifications
│ │ ├── {event-general-notifications-name}
│ │ │ ├── {general-notification-name} # The folder to store channel specific data for general notifications
│ │ │ │ ├── in-app-notification
│ │ │ │ │ ├── {locale} # The folder to store locale-specific engagement templates
│ │ │ │ │ │ └── engagement-template.json # The engagement template that contains default messages with the Handlebars expressions
│ │ │ │ │ └── in-app_channel-settings.json # The channel settings for in-app notification channels per locale
│ │ │ │ └── push
│ │ │ │ ├── {locale}
│ │ │ │ │ └── engagement-template.json
│ │ │ │ └── in-app_channel-settings.json
│ │ │ └── event-general-notifications.json # The event with one or more general-notification definitions
│ │ └── ...
│ ├── templates # The folder to store templates
│ │ ├── {template-name}
│ │ │ ├── content-schema.json # A structure of an engagement template based on a given template
│ │ │ └── template.json # A template definition
│ │ └── ...
│ └── placeholders # The folder to store placeholder group
│ ├── {placeholder-group-name}
│ │ └── placeholders.json # A placeholder group configuration
│ └── ...
└── repositories # The folder with a repository definition.
├── {repositories-type} # Contains a repository that has a cloud storage (AWS S3 or Azure) as the underlying storage
│ ├── {repository-name}
│ │ ├── format.txt # Applicable package format
│ │ ├── package.txt # List of items to be imported into a repository
│ │ └── repository.xml # A repository definitions
│ └── ...
└── ...
└── oneruntime # Oeruntime collection
└── general-notifications # General notifications related collection
└── event-general-notifications
├── {event-general-notifications-name}
│ ├── {general-notification-name} # The folder to store channel specific data for general notifications.
│ │ ├── in-app-notification
│ │ │ ├── {locale} # The folder to store locale-specific engagement templates
│ │ │ │ └── engagement-template.json # The engagement template that contains default messages with the Handlebars expressions
│ │ │ └── in-app_channel-settings.json # The channel settings for in-app notification channels per locale
│ │ └── push
│ │ ├── {locale}
│ │ │ └── engagement-template.json
│ │ └── in-app_channel-settings.json
│ └── event-general-notifications.json # The event with one or more general-notification definitions
└── ...
For customers that only use Headless General Notification and will not migrate to Premium license Backbase recommends using private instead of protected repository definition for engagement-template-general-notification repository.
Example:
<ns2:repositories
xmlns:ns2="http://www.backbase.com/content/model/1.0">
<ns2:repository>
<ns2:repositoryId>engagement-template-notification</ns2:repositoryId>
<ns2:name>Engagement Template General Notification Repository</ns2:name>
<ns2:description>Repository to store engagement templates for engagements where engagement is general notification</ns2:description>
<ns2:isPrivate>true</ns2:isPrivate>
<ns2:implementation>s3</ns2:implementation>
<ns2:c3RepositoryId>engagement-template-notification</ns2:c3RepositoryId>
<ns2:versioningEnabled>false</ns2:versioningEnabled>
</ns2:repository>
</ns2:repositories>A general notification template defines the structure of a general notification sent to bank customers, including its name, description, title, engagement type, channel, and corresponding placeholder groups.
{
"eventClassName": "com.backbase.dbs.messages.pandp.event.spec.v4.MessageReceivedEvent",
"id": "message-received",
"eventBusinessName": "Message Received",
"recipientType": "internal",
"extractor": "#this['recipient']",
"generalNotifications": [
...
]
}More information on how to create a custom Event General Notification.
There are two types of recipients of Genera Notifications Notifications. internal - This recipient type requires the event to include the user’s internalId to be present in the trigger event. subscription - This type of GN requires the user to opt in via a notification preference.
If your GN is of type subscription you need to build a UI (Android, IOS, Web) that uses the pre-existing backend API, allowing users to opt-in to your GN.
More information on how to build notification preferences UI for OOTB general notification.
- Engagements Capability
- Provisioning Capability
- Document Storage Capability
- Provisioner
To create new or modify existing General Notification you'll have to modify JSON files (event definition, templates, and content-schema, etc). Once changes to those files are pushed to the version control system, pipeline would automatically build provisioning packages and package them to the docker image:
Once projects clone the repo, the docker image should be built with the pipeline described above. Docker image will contain out-of-the-box Engagements data package, that can be used from day 1.
More information on how to create custom General notifications.
Engagements data and Provisioner images should be deployed to the environment. These 2 containers have shared volume. Provisioner would scan folders defined in its configuration and send provisioning packages found in those folders to Provisioning service. Provisioning service would distribute it to corresponding destinations (Engagement, Content Enricher)
More information on how to provision Engagements data.
Building Engagements data collection (your own set of customized Engage Defaults) is easy, just run the following maven command:
mvn clean installGenerated collections will be located under target/assembly folder. In order to create docker image locally use docker profile:
mvn clean install -PdockerNOTE: applicable only for UNIX-based machines.
- Engage App (Premium version)
- Foundation (Headless General Notification)
- How to provision Engagements data
- How to import collections using Provisioner container
- Clone the Engagements Data project from the GitHub repository.
- Create a
feature/*branch based on themasterbranch. - Create new or edit existing General Notifications or Message Center template definitions by copying and modifying the existing JSON and HTML files in your branch, for example, event definition, templates, content schema.
Backbase recommends using the
feature/andhotfix/prefixes in branch names during development. This will trigger the corresponding out-of-the-box workflows. - Create a pull request based on your branch.
Every time the pipeline is run, the Docker image is built but not pushed into the Docker container registry. To push to Elastic Container Registry, credentials must be configured in pom.xml and .github/workflows.
| Property name | Example | Description |
|---|---|---|
project.version |
• 0.1.0 is used in the master branch |
This property may vary depending on the branch you are working on. The deployment pipeline automatically changes the version property depending on the branch. |
backbase-bom.version |
2022.11 |
This is defined in the parent pom.xml file and matches the released Backbase version. |
To build the Docker image, take one of the following actions:
- Merge your pull request to the
masterbranch.
The format of the
project.versionproperty isX.Y.Z.
- The Engage Defaults collection is packaged and the Docker image is created, for example
engagements-data-retail:2022.11-0.10.0andengagements-data-sme:2022.11-0.10.0.
This is not pushed to the Docker container registry, unless you configure credentials in
pom.xmland.github/workflows.
- After the PR is merged to the
masterbranch,project.versionis automatically increased based on the type of the source branch:
- Minor release: a pull request is raised from the
feature/*branch. - Hotfix release: a pull request is raised from the
hofitx/*branch.
The
hotfix/*branch is only available for the latest version on the master branch.
Please create a feature branch from develop and a PR with your contributions. Commit messages should follow semantic commit messages