SOA and Gmail or how to send emails using your Oracle SOA Suite domain and your Gmail account.
Actually it can be any other email account but here we will focus on the Gmail option.
Note: For the Yahoo details scroll down.
This post is nothing new for sure....
Already my AMIS friends covered this in the past:
- "Setup GMail as mail provider for SOA Suite 12c – configure SMTP certificate in trust store".
- "Configure SOA Suite 11g for sending email notifications with Google Mail"
Oracle Blog covers the same details in the "Configuring Notification Mailer using GMail's SMTP and IMAP servers (Using new certificates)" - more important are the new Gmail features related with security: enable the "Allow less secure apps" option.
So, in case you have issues and no emails are sent from SOA side, then make sure that Gmail "Allow less secure apps: ON" is in use.
Now, is there any real reason for me to cover the same details ? Probably not but I can add some extra details like...
- Using the KeyStore Explorer tool to import the Gmail certificate.
- Finding the Gmail certificate using the Ubuntu on Windows option.
- Security details you need to be aware about
I am actually very happy to see such a default Windows + Ubuntu option on my Windows machine: no need to create a virtual machine just for some Linux tests here and there, no need to install Cygwin for basic Linux features and tests.
Long story short we need the below:
- Bash on Ubuntu on Windows
- KeyStore Explorer
- SOA-BPM 12c domain
Gmail smtp.gmail.com certificate
Open your Bash on Ubuntu on Windows and run the below:
openssl s_client -connect smtp.gmail.com:465
Copy the "BEGIN CERTIFICATE" -> "END CERTIFICATE" rows into a new "pem" text file.
You can also generate the same file by using the below:
openssl s_client -connect smtp.gmail.com:465 > /mnt/d/GMAIL/gmail-smtp-cert.pem
The above will create a "gmail-smtp-cert.pem" file inside the D:\GMAIL folder.
You can stop the script and ignore the error like "verify error:num=20:unable to get local issuer certificate" - check the new ".pem" file and you will see that the certificate is there 😉
At the end you only need the "BEGIN CERTIFICATE" -> "END CERTIFICATE" rows:
-----BEGIN CERTIFICATE-----
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua. Ut enim ad minim veniam, quis nostrud
ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit
esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia
deserunt mollit anim id est laborum Lorem ipsum dolor
-----END CERTIFICATE-----
Real life experience: if you have future issues and you will not be able to use SOA to send emails STOP there and generate a new smtp.gmail.com certificate ! Double check the current certificate you have and the new generated certificate and there is a chance to see that actually a new certificate should be used. If you still have issues, later you can check for all other possible "1000" solutions but make sure you never end up testing solutions that will never help since a new certificate should be used. And use this scenario even if the certificate was imported only some 3 days ago.
I am not sure about the full story behind a new certificate after only 3 days but chances are that after some time you will actually end up using a different Gmail server [so not the same one as some 3 days ago] and since a new server then a new certificate should be imported.
Now that we have the "BEGIN CERTIFICATE" -> "END CERTIFICATE" rows in the ".pem" file we will go and import it into the JKS.
JKS and Gmail import
For this we will use the KeyStore Explorer tool. This is a very nice alternative to the command line script.
Go into the SOA-BPM binaries location; this is not the DOMAIN HOME ! This is the ORACLE_HOME binaries. In my case is about the "Jdev_BPM_Binaries_Home".
From here we will navigate to the "wlserver\server\lib".
So at the end the location we need is like "Oracle_Home\wlserver\server\lib".
Here we have a default key store: DemoTrust.jks. We will import this gmail-smtp-cert.pem certificate by just "drag and drop".
Using the KeyStore Explorer tool we will open this DemoTrust.jks; default password is "DemoTrustKeyStorePassPhrase":
Import this gmail-smtp-cert.pem certificate by just "drag and drop" and at the end you will have the below:
Note: Please ignore the "*.google.com" row /certificate. This is not related with this gmail-smtp-cert stept.
Save and close and all done.
Note: Of course if you have a different key store in use then you need to follow the same above details but this time using your custom key store.... but I think you know this already since you have a non-default key store in use.
Before going with a restart -since we do need to restart the server- there is something more to see about: "Hostname Verification".
Hostname Verification
Open the Admin Console: http://localhost:7601/console.
Go to servers:
And click on the Admin Server - as the only available server for your test domain:
Click on the SSL tab and click again on the "Advanced" link.
Here, change the "Hostname Verification" from the default "BEA..." one to "None".
At the end, details will look like below:
Note: If you already implemented the "Luhn Checker web service: how to validate a credit card" composite then the "Hostname Verification" is already on "None".
Restart the server.
SOA Suite: Email driver update
Now that "SOA Platform is running and accepting requests" open the EM Console: http://localhost:7601/em
From the main menu open the "User Messaging Service" -> "usermessagingdriver-email" - > "Email Driver Properties":
Note: Based on the installation type you used, it can be that more or less options will be visible for the "User Messaging Service"; just go with the one that has the "email" key word and open the "Email Driver Properties".
Since by default the list is empty, looks we need to use the "Create" button:
We will go now with the "Common Configuration" details and make sure we only choose the "Send" option - since for now we just want to "Send" emails and nothing more:
Make sure that "EMAIL:" pattern is used when you update the "Use Default Sender Address" with your own Gmail account.
Once done, we will go and implement the "Driver-Specific Configuration" - is a long table with different options but, since we only want to "Send" emails, we don't have to care about all the options:
Once done, you can "Test" and later "OK" to save this configuration:
SOA Suite: Test
Now that we are done with the configuration we can send emails even with no composite deployed. We will use the built-in feature provided by the "Human Workflow"... but this is actually a "2 steps" task.
Open the EM Console: http://localhost:7601/em
From the "soa-infra" level go to the "SOA Administration" -> "Workflow Properties":
Update the email details - using the below pattern:
Note: Of course, it should be "your_email_adress@gmail" and for the reply option it can be something different. Save it.
Now that we are done with this above extra step [do not ignore it] we can actually use the same EM Console and deliver some emails.
From the "soa-infra" level go to the "Service Engines" -> "HumanWorkflow":
Here, switch on the "Notification Management" tab...but do keep in mind there is a "Deployed Components" tab that will be used once you will deploy a composite having a "Human Task" component.
Back to the "Notification Management" tab, use the "Send Test Notification" button:
Check your inbox now and you will find a new email. In addition you will also see this information in the below table - if not by default the click the "Search" button:
That's all folks !
What next ? We can always create SOA-BPM composites that will send emails/notifications based on some specific patterns. As we can see below all details are by default covered when using the specific notification component:
Security details
Here I would like to add some "security" details that you should be aware about it.
Going back to the email account options we used before...
....we can see some other options to choose from; like:
So, then, where is the problem with this "Cleartext Password"?
To better understand: go first into the DOMAIN_HOME\config\fmwconfig folder and open the usermessagingconfig.xml file. You can actually see that the password is in "Cleartext" - per the below demo:
<ns1:Property name="ReceiveFolder" value="Inbox"/>
<ns1:Property name="OutgoingMailServer" value="smtp.gmail.com"/>
<ns1:Property name="OutgoingMailServerPort" value="465"/>
<ns1:Property name="OutgoingMailServerSecurity" value="SSL"/>
<ns1:Property name="OutgoingDefaultFromAddr" value=""/>
<ns1:Property name="OutgoingUsername" value="your_email@gmail.com"/>
<ns1:Property name="OutgoingPassword" value="welcome1"/>
So, it looks that "welcome1" is the password for your "your_email@gmail.com" account.
Is this a real problem ? No.... if you use this domain for tests only and you are the only one able to use the machine hosting the domain.
For all other scenarios: make sure you do not use the "Cleartext Password" option.
Yahoo certificate & EM Console settings
In case you want to use the Yahoo email account, just follow the same approach and generate the .pem certificate file using the below details:
openssl s_client -connect smtp.mail.yahoo.com:465 > yahoo-smtp-cert.pem
In addition, the below main setting should be used in the EM Console:
"SupportedDeliveryTypes" : "EMAIL"
"SupportedContentTypes" : "*"
"Capability" : "SEND"
"Cost" : "0"
"Speed" : "10"
"SupportedCarriers" : "*"
"SupportedProtocols" : "SMTP"
"SupportsCancel" : "false"
"SupportsReplace" : "false"
"SupportsStatusPolling" : "false"
"SupportsTracking" : "false"
"SupportedStatusTypes" : "DELIVERY_TO_GATEWAY_SUCCESS, DELIVERY_TO_GATEWAY_FAILURE, USER_REPLY_ACKNOWLEDGEMENT_SUCCESS, USER_REPLY_ACKNOWLEDGEMENT_FAILURE"
"SenderAddresses" : ""
"SupportedApplicationNames" : ""
"DefaultSenderAddress" : "EMAIL:your_email@yahoo.com"
"SendingQueuesInfo" : "OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1"
"MailAccessProtocol" : "IMAP"
"AutoDelete" : "false"
"Debug" : "false"
"CheckMailFreq" : "30"
"DisconnectAfterPoll" : "false"
"ReceiveFolder" : "INBOX"
"OutgoingMailServer" : "smtp.mail.yahoo.com"
"OutgoingMailServerPort" : "465"
"OutgoingMailServerSecurity" : "SSL"
"OutgoingDefaultFromAddr" : ""
"OutgoingUsername" : "your_email@yahoo.com"
"OutgoingPassword" : "your_account_Password"
"IncomingMailServer" : ""
"IncomingMailServerPort" : "143"
"IncomingMailServerSSL" : "false"
"IncomingMailIDs" : ""
"IncomingUserIDs" : ""
"IncomingUserPasswords" : ""
"ProcessingChunkSize" : "100"
"ImapAuthPlainDisable" : "false"
Don't forget to update also the Yahoo details on the "Workflow Properties" page :
