Customizing Email and SMS Messaging Provider

Prerequisites

Ensure you have the following prerequisites before proceeding:

Oracle Linux 7.x environment
JDK 1.8.x for compilation
Apache Maven 3.6.2 or later
Any third-party jars necessary for your implementation

Perform the following to customize email and SMS Messaging Provider:

Implement Custom Logic and Create Jar files

Download the project zip file from the following location in the management container: /u01/oracle/libs/messagingprovider-interface-12.2.1.4.1-<date>.jar and extract it to your working directory.
Create an implementation of your custom logic for email and SMS. For more information about the interface and methods, see the Javadoc reference.

Note:

E-mail and SMS must have separate implementation classes.

In the implementation class that implements the sender interface, make sure that @Service declaration is created with necessary imports. This declaration helps the framework to load the custom implementation at runtime.
Make changes to the pom file for compiling and generating a jar file that includes this implementation. Ensure the following:
- The jersey-hk2 dependency must be declared as dependency in the pom file for the build.
- The MessagingProvider interface must be used and declared as dependency in the pom file for the build.
- The implementation must generate one jar and additional third-party jars. You can choose to implement the send method using one or more classes and package them into this jar file.
Test the implementation to make sure that it works as necessary.

Integrate the Implementation with OAA

Configure the custom implementation class in OAA.
- For e-mail:
  Update the customProvider property of the ChallengeEmail enum with fully qualified class name of the implementation class.
  
  For example, if the name of the implementation class is com.company.MyCustomEmailMessagingSender, update the ChallengeEmail enum property as bharosa.uio.default.challenge.type.enum.ChallengeEmail.customizedProvider=com.company.MyCustomEmailMessagingSender
  
  To do this, use the configuration property REST API as shown in the following sample request:
```
curl  --request PUT 'https://<PolicyUrl>/policy/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \
--data '[
{
"name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.customizedProvider"
"value": "com.company.MyCustomEmailMessagingSender"
}
]'
```
  Note:
  
  In this case, and elsewhere in this section, remove /oaa-policy from the <PolicyUrl>, for example use https://<host>:<port>/policy/config/property/v1 not https://<host>:<port>/oaa-policy/policy/config/property/v1
  
  For details about finding the PolicyUrl and authenticating, see OAA Admin API.
  
  For details about the Configuration Properties REST Endpoint, see Configuration Properties REST Endpoints
- For SMS:
  Update the customProvider property of the ChallengeSMS enum with fully qualified class name of the implementation class.
  
  For example, if the name of the implementation class is com.company.MyCustomSMSMessagingSender, update the ChallengeSMS enum property as bharosa.uio.default.challenge.type.enum.ChallengeSMS.customizedProvider=com.company.MyCustomSMSMessagingSender
  
  To do this, use the configuration property REST API as shown in the following sample request:
```
curl  --request PUT 'http://<PolicyUrl>/policy/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \
--data '[
{
"name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.customizedProvider"
"value": "com.company.MyCustomSMSMessagingSender"
}
]'
```

Make the Implementation Available at Runtime

When the e-mail or SMS service pods are configured/started, shared volume information is made part of that configuration. It appears in the deployment.yaml file of that chart.

Create a persistent NFS volume and provide that information in the values.yaml for the email chart as shown in the following sample.

Note:

Do not change the mountPathPrefix value

# volume to store customized email sending implementation
customizedFactorImplVolume:
  # name of the volume
  name: "nfsvolume"
  # server where the volume is located
  server: <NFS_IP_ADDRESS>
  # path on the server where the volume is located
  path: <NFS_PATH>/FactorProviderImpls
  # prefix of volume's mounted path in email container
  mountPathPrefix: /u01/oracle/
  # relative path of mounted volume, relative to the above prefix
  mountRelativePath: <NFS_VOLUME>/customprovider
  # indicate whether the volume should be readOnly
  readOnly: false
  # names of customizedJars expected in mounted volume, separated by comma
  customizedJars: "OAACustomMessaging-Provider.jar"

If the external volume is not NFS then perform the following:

Edit the deployment.yaml file in the email chart as shown:

{{- if .Values.customizedFactorImplVolume }}
        - name: {{.Values.customizedFactorImplVolume.name}}
          nfs:
            server: {{.Values.customizedFactorImplVolume.server}}
            path: {{.Values.customizedFactorImplVolume.path}}
{{- end }}

Copy the custom implementation and third party dependency jar files to the following folder: <mountPathPrefix><mountRelativePath>/.

Stop and start the nodes in the pod to start loading your custom implementation.