​I continue to be impressed with what may seem like minor features released by the APEX development team that turn out to be a big deal because they end up saving hundreds of lines of code. One such feature is APEX Email Templates introduced in APEX 18.1. In this post I will describe how we used them for much more than just Email Templates when building a notification framework for one of our customers.

​The goal of the project was to build a notification framework that could be used to handle just about any kind of notification that you can imagine. This includes email (via APEX_MAIL and Mailgun), SMS via Twillio and push notifications to iOS Apps using Firebase. We ended up building a generic notification queue which we processed on a schedule to send out the actual notifications. You may ask, how do APEX Email templates apply to all of these communication methods? The answer lies in the APEX_MAIL PL/SQL API apex_mail.prepare_template. Read on to find out why.

The goal of templating in the context of notifications is to separate the content of the  notification from the format and layout of the notification. This allows you to alter the template without having to change any code (most of the time). All of the notification methods I mentioned above can benefit from templating.
 
Let’s take email as an example. Let’s say we have an email we want to send to a customer when they place an order. In the email you want to provide information related to the product they purchased, how it will be shipped, and when they can expect it to arrive. You could build a PL/SQL function that generates the complete HTML document and then use that for the content of your email. This would mean, however, that when the marketing department needs to change the layout of the email, you have to change that function, regression test and deploy code. Being able to just change a template has obvious advantages.
 
As we move forward, I will use the example of the New Order notification and create an APEX email template which can be used for SMS, APEX_MAIL and Mailgun.

​Since APEX 18.1, under Shared Components, you will see an option ‘Email Templates’. Click that option then click ‘Create Email Template >’ to create a new template. 

On the right-hand side, you have the option to start with a ‘Sample Template’. Clicking one of the samples will pre-populate the template with the sample. This is a great way to see how templates work.

Placeholder Variables
The template works using boilerplate text (and HTML) and placeholder variables. These must be enclosed in a #, must be uppercase and must have no spaces. In the email subject above, you can see an example #ORDER_NUMBER#. Placeholders are replaced at run time by apex_mail.send and apex_mail.prepare_template (more on that later).
 
HTML Header, Body and Footer

In this section you provide the boilerplate text, HTML and placeholder variables that you need to format the data elements in your notification. Although the HTML you enter here impacts the format of your notification (e.g. bold text, links, tables etc.), it does not drive the overall structure of the email. This is driven by the ‘HTML Template’ field in the ‘Advanced’ section.

You can load a default Template by clicking the ‘Load Default HTML’ button.  The APEX team has provided a pretty nice-looking template that works well with browsers and email clients (see below for a screen shot). Of course, you can change this and even copy and paste templates from open source providers like Zurb.
 
Plain Text
Finally, there is a section for Plain Text. There are still some email clients out there that only support plain text, so it is good practice to provide a Plain Text as well as an HTML formatted email body. This section also comes in handy for SMS templates.

I have a template now but how do I know exactly how it’s going to look? This introduces the first use case for apex_mail.prepare_template. Create a simple PL/SQL block like the following and run it.

​Note: p_application_id refers to the APEX Application that the template was created in.
Note: The placeholders in the JSON passed in p_placeholder are also substituted in the subject and the Text Body.
 
The API will substitute all of the place holders in the template ‘NEW_ORDER_NOTIFICATION’ with values in the placeholder JSON. Save the results from the dbms_output into a file with a .html extension and open it using your browser. You can now iterate until you have the template looking just how you want it. Of course, it wouldn’t take much additional effort to create an APEX page to show a preview of the template.

​As well as prepare_template, APEX 18.1 brings a new ‘send’ function which handles the call to prepare_template as well as sending the actual email.

​How is this useful for other notification methods like Mailgun and Twillio? Well, just because it says APEX Email Templates on the box does not mean that is all it is good for.
 
Mailgun
Just like APEX_MAIL.SEND, the Mailgun API looks for three main parameters: subject, text (body) and html (body). We can get all of these values from our APEX Email Template using the apex_mail.prepare_template. We then use the results from this API call to call the Mailgun API to send the actual email.

​Twillio
The Twillio Messages API also expects a message body to send an SMS, but as you may expect we would not want to send HTML in the body. For SMS templates we need to focus on the Plain Text Format portion of the template. You also do need to provide values for subject and HTML body, but it can just be dummy text.

​The call to the prepare_template API is identical to the one above; we just need to pass different placeholders and we only want to consume p_text from the response.

​All you need to do then is send the content of p_text using the Twillio API, and Voila!

​Multi-language is also covered. If you have multi-language enabled for your app, when you seed an publish your APEX application, a language translated version of the template is also generated. Once you provide translations for the text, the template can be generated in the users session language.

​APEX Email Templates are a great feature, I think there is still room for improvement though and here are my suggestions for the APEX Dev Team:

• Provide capabilities to store and retrieve templates by language.
• Create an API to create and update templates. That way, developers can create a template building page for end users to manage the templates.
• Create an ‘apex_’ view on the templates table WWV_FLOW_EMAIL_TEMPLATES.

​APEX Email Templates, like many other APEX features have been well thought out and provide real value to developers (and their end users). They can also be used for much more than just email templates so don’t let my examples limit you.

​APEX Social Sign-In has opened up a whole new world of possibilities for authenticating users into APEX. Whilst it is a catchy name, I propose the name ‘Social Sign-In’ is selling these new authentication capabilities short. I believe ‘Social Sign-In’ actually has far wider reaching implications for both Enterprise and B2C APEX applications.

For sure, APEX Social Sign-In allows you to authenticate users using Google and Facebook and that is great. Many enterprises, however, are using dedicated cloud-based identity management providers such as Okta and Auth0 to authenticate their employees. In addition, B2C web sites and mobile Apps also use these products to handle identity management for their customers. These products provide a host of identity management features such as Single Sign-On, Lifecycle Management, User Management, Multi-factor Authentication to name a few. Being able to use products like these with APEX just by entering a few configurations in a setup page (rather than having to write hundreds of lines of code) is a game changer. It also raises the profile (and credibility) of APEX in an enterprise and consumer setting.
 
Level set on what is federated identity management
Instead of me taking up space in this post, I came across the following article which is a great primer on federated identity management aimed at developers. https://hackernoon.com/federated-identities-a-developers-primer-655a160d66cb

So, why do I even need a third part identity provider? As with most things ‘Cloud’, the answer is security and convenience. Let’s take a look at each of these justifications in a little more detail.

Security
My job is to develop secure, scalable web applications that provide real business value. I am not an expert in cryptography or how you should best prevent user accounts from being compromised. Reputable companies that do nothing else but build identity management solutions, on which their reputation depends, will do a better job than me. Also, in this day and age, you do not want to be responsible for the safe keeping of your user’s credentials. There are more than enough documented nightmare scenarios out there to convince us of that.
 
Convenience
Let’s say my IT department demands that all users start using two-factor authentication. If I had built my own authentication solution, I am now on the hook for building two-factor authentication into my application. While that sounds like a fun side project, it is certainly not a cheap one. Again, we are back to can I implement this more securely than an expert? Using products like Okta and Auth0, it is simply a matter of enabling the feature (and paying for it). Products like these also take care of forgotten passwords, user on-boarding and many other tedious aspects of providing identity management for your users.

So, what did we have to do before Social Login was available? I was rudely reminded of this recently when I was asked to build a custom authentication scheme (in APEX 4) to allow users of an internet-facing B2B APEX application to login via Okta. I had to hand code every URL re-direct, every web service call and don’t get me started on how I had to implement the callback to APEX after authentication into Okta. Don’t get me wrong, the fact that this was even possible in APEX 4 is a testament to the flexibility of the APEX Authentication Scheme. There was, however, clearly room for improvement.

All this changed with the introduction of APEX Social Sign-In. For a basic authentication scenario, all you need to do on the APEX side is create a set of Web Credentials and fill out 4 fields in an Authentication scheme. Zero code required!
 
In a bid to convince the same APEX 4 customer to upgrade to APEX 18.2, I created a demo showing them how easily we could authenticate Okta users using Social Sign-In. For the remainder of this post, I will focus on what configurations were required to complete this demo and authenticate Okta users into APEX.

​Let’s start with the obligatory diagram to show what is going on when you authenticate an Okta user into APEX.

1. The user accesses a page in the APEX application. If the user already has a valid APEX session, then they will be allowed to access the page. If they do not, then the APEX authentication scheme will direct the user to Okta.
2. If the user already has a valid Okta session, then they will be immediately re-directed back to APEX, otherwise they will be directed to an Okta login page.
3. The user will enter their Okta username and password.
4. Assuming login is successful, Okta will re-direct the user back to APEX.
5. When Okta calls the ‘Callback URL’, it provides a Java Web Token (JWT) which includes the following information:
   1. The ‘state’, which is a value APEX passed to Okta at the beginning of the flow. APEX will verify that the ‘state’ returned in the JWT matches the one it created at the beginning.
   2. The user name of the Okta user.
   3. An authorization code which can be used to use to get a token to call additional Okta web services.
6. Once logged in, we can call web services in Okta to get additional information about the user e.g. what groups they belong to, their full name, address etc.
7. At this point, APEX will direct the user to the home page of the APEX App.

 
There, aren’t you glad you didn’t have to code any of that (well at least up until step 6)! 

​Before we get into the APEX configurations, we need to create an Okta account and configure our application in Okta. Okta has a free developer account (https://developer.okta.com/signup/) which allows you to try Okta out.
 
As previously mentioned, Okta has a whole bunch of features which I won’t get into in this post. Instead I will review the Okta configurations needed for the Demo APEX App to login using OpenID Connect (OIDC). Note: The example below was created using our corporate Okta account, but this should also work using an Okta developer account.
 
Application Definition
You need to define each application you want to authenticate in Okta. This is much the same as you would for Google or Office365 authentication. Start by Adding an application in Okta, be sure to select Platform = ‘Web’ and Sign on method = ‘OpenID Connect’.

​The following screen shots show the already configured application followed by descriptions of what values to provide.

​At this stage, we are essentially just picking the Application type and saying we want to use the ‘Authorization Code’ grant type OAuth flow.

This is the interesting part:

• Login redirect URIs
  • This is the APEX URL that Okta will re-direct to when your user has successfully logged into Okta. apex_authentication.callback is a special URL that accepts a JWT from the identity provider and authenticates the user into APEX.
• Logout redirect URIs
  • This is the URL that Okta will direct your user to when they logout.
• Login initiated by
  • Here you can decide if only your App can initiate login or if login can be initiated by Okta. We want ‘App Only’.
• Initiate login URI
  • This is not applicable when Login initiated by is ‘App Only’.

​Okta will generate client credentials for each Application you create. We will use these when creating our APEX ‘Web Credentials’ below.

​In the above section, we are identifying that we want to use OpenID Connect as our authentication method.

​Finally, in the above section, we can determine which Okta users (and or Groups) should have access to our Application.

​With our Okta configurations complete, we can now configure our APEX Authentication Scheme.
 
Web Credentials (these come from Okta)
Start by creating a set of ‘Web Credentials’. Here you will provide the Client ID and Client Secret provided by Okta above.

• Credential Store
  • This is the credential store we defined previously.
• Authentication Provider
  • I chose ‘OpenID Connect Provider’ because a) it is supported by Okta and b) it involves the least configuration. It essentially self discovers all of the information it needs to authenticate against the provider from a JSON document which is publicly accessible.
• Discovery URL
  • This is the discovery URL which APEX uses to find out everything it needs to know to authenticate against the provider. Okta provides this information via a JSON document. The JSON document includes all of the web service end-points (/token, /userinfo, /logout etc.), supported scopes etc.
• Scope
  • The list of scopes determine what pieces of additional information about the user you are allowed to fetch after login to Okta. This information can be accessed by calling the Okta /userinfo web service. In this example, I can get openid information, email address, user profile information and the groups a user belongs to.
• Username Attribute
  • This is the attribute returned from Okta that APEX uses to set the APEX username (:APP_USER) of the logged in user.

And, that is it, the APEX configuration is complete!
​

Patching for APEX 18.2​
If you are running APEX 18.2, be sure to apply the PSE bundle patch for APEX 18.2 ‘Patch 28727865: PSE BUNDLE FOR APEX 18.2 (PSES ON TOP OF 18.2.0.00.12)’. This fixes a bug when using ‘OpenID Connect Provider’ as the ‘Authentication Provider’ in your authentication scheme.

Firewalls, Wallets and Proxies
If you are working with APEX on-premise you have to consider how APEX is going to call out to the identity provider and how the identity provider is going to be able to callback into APEX. For the call out to happen, you have to either install the appropriate certificates from the identity provider in a wallet on your database server or create a proxy to facilitate this. You may also have to create ACLs to even allow network traffic to leave your database. For the identity provider to make the callback, your APEX environment must be accessible to the internet.

In this post, I have tried to illustrate how easy it is to configure APEX Social Sign-In to authenticate APEX users with products like Okta. Okta is one of many cloud identity management providers that you can use to for handling identity management for your APEX users. With APEX Social Sign-In there are less and less reasons to store passwords in your database. 

Hopefully I have convinced you that its scope reaches far beyond Twitter and Facebook. So, what name should we use instead of 'APEX Social Sign-In'? My vote goes for 'Super simple mechanism for logging users into APEX using just about any consumer or enterprise identity provider you care to mention with zero code'. Something tells me, however, this won't fly with the marketing folks!

​I have been working with Oracle e-Business Suite (EBS) since version 9.4 (that’s character mode!). Although EBS has come a long way since then, even the newer releases are starting to look long in the tooth. In this post I will explore a number of use cases where Oracle APEX was used to bring the joy back to ERP without spending a whole lot of money.

​Although many companies are moving their ERP to the cloud, many cannot because cloud ERPs offerings do not yet provide all of the features, they need to run their business. This leaves companies running on-premise ERP systems like EBS version 12.1.3 in limbo. Do they try and upgrade to version 12.2 for an incremental improvement in UX or do they wait until key cloud features are available and then move to the cloud? If they wait, how do they explain to their users that the technical acrobatics required to run Java from a browser these days is worth the effort? The user base for such companies are in full revolt and they won’t stand for it any more. This is especially challenging for companies that have introduced edge application such as HR in Workday. Users now know what is possible and want more of it.

So, how can an IT department provide a significant improvement in UX to EBS users for zero additional software cost? Oracle APEX is a no cost option of the Oracle database. APEX provides you with all the tools you need to build beautiful, scalable apps in a single, extensible platform, which runs as a part of Oracle Database. In this case it will run in the same database as EBS, providing zero latency data access.
 
What you will need

• An application server (or VM) to run Tomcat and ORDS (e.g. 25GB Disk 4GB Memory, 1 CPU)
• Install the latest version of APEX on the EBS Oracle Database
• Install Tomcat and ORDS on the Tomcat/ORDS server

Note: There is no additional cost for any of the software mentioned above.
 
I am not advocating re-writing EBS in APEX, far from it. What I am advocating is taking a few key processes that have high visibility and high impact to your organization and using APEX to provide a modern easy to use interface.

I have found that using APEX to extend EBS makes it easier to introduce other technologies that can also transform the way users interact with EBS. For example:

• Voice interfaces to EBS with Alexa.
• Utilizing SMS to communicate with your employees (and process responses).
• Introducing PaaS products like Exadata Express to extend EBS outside of your firewall.
• Leveraging AWS S3 for document storage.
  
• Provide custom mobile interfaces for users to interact with EBS.

​In all likelihood, your organization has an annual review and performance management process. If you do then it is also likely that most people in your organization participate, making it a highly visible process. Oracle EBS has a performance management module that is fully functional and integrates well with Oracle Human Resources. The User Experience, however, is not something you can be proud of. In addition, you are probably spending a significant amount of time managing issues related to this poor UX.
 
Last year JMJ developed an APEX application to replace the employee facing side of EBS performance management. This application acted as a skin on the underlying Oracle performance management module, utilizing standard Oracle APIs to create and update records in the EBS data model.

1. Employees logged in directly to the APEX App, using their EBS credentials. The App had a URL that was easy to remember and was not associated with EBS. The UX for the app was completely unlike EBS, in fact it more closely resembled a consumer application.
2. On the back end, the HR department used the standard EBS functionality for tasks such as moving appraisals to compensation workbench.

 
The overall impact was dramatic. People actually liked using the application, not only did this make employees feel good but it increased participation in the process.

My second example involves taking a critical business process and building a custom application to manage that process in a way that would not be possible with standard functionality. To some, this may sound like heresy. In fact, for the 18 years I worked for Oracle Consulting extending EBS and ERP Cloud, my mantra was always don’t customize unless you have to. The key here is the word ‘have to’. If you can save a million dollars a year (or make an additional million dollars a year) by building a product that costs 250 thousand dollars a year to maintain and upgrade, then you have to do it.
 
JMJ Cloud recently built an APEX application that managed the receipt and processing of material at over 40 manufacturing plants. In doing this, we built a whole new UI for plant staff to greatly simplify their interactions with EBS. Behind the scenes, however, were able to use significant pieces of EBS functionality to avoid having to re-invent the wheel.

1. Plant users’ gain access via either a native iOS mobile application or an APEX App. These users perform plant operations such as receiving material, creating sales orders, logging production etc.
2. Back office and corporate staff log directly into EBS to perform back office processing. e.g. pricing and booking orders, creating invoices etc.

 
Simplified overview of the business process:

• Material delivered by customer for processing:
  • User logs into APEX and created a new job.
  • The APEX UI for creating the job pulls customer information directly from EBS. When a job is created, an EBS Sales Order header is also created.
  • During the receiving process order lines are added to the EBS Sales Order via an APEX page. The receiver enters just 3 fields per order line in the APEX application making data entry simpler and faster.
• As material is processed production data is posted via the APEX App, to the associated sales order lines in EBS.
• Once the sales order is priced and booked, invoicing and collections is handled from standard EBS.

 
The APEX application in conjunction with a native iOS app that speaks to EBS using Oracle REST Data Services (ORDS), means the majority of users at the plant do not have to be concerned with EBS at all. In an environment with a high turnover of staff who have limited technical skills, having an easy to use and simplified UI is critical.

As I mentioned earlier, Oracle EBS is one of the most feature rich ERP platforms out there. This complexity can be both a blessing and a curse. A single Oracle module can take months of effort to implement and you may end up using less than 25% of the full functionality of that module. The problem is you are paying for 100% of the functionality. If you could build the pieces of the module that you really need and then integrate that with other aspects of EBS you could end up saving money and providing a more modern user experience at the same time.
 
One example of this is a Capital Expenses Tracking system which JMJ Cloud recently built for an EBS customer. This was a relatively simple 8-page (4 table) application that allows users to enter details of a Capital Expenditure request and then submit the request for approval. Having the new App build on the EBS database, allows us to leverage EBS for much of the heavy lifting.
For example:

• Authenticate users using Oracle EBS credentials
• Use EBS view, value sets and lookups as the source for List of Values to reduce dual maintenance and increase consistency. (e.g. List of GL account segments, List of GL periods)
• Utilize Oracle Workflow to handle notifications and approvals of submissions
• Provide list of Capital Project budgets (from Oracle Projects in EBS) to associate a CAPEX request with

​Oracle EBS is one of the most (if not the most) feature rich ERP application on the market. Often times, these features have come at the expense of UX and in 2018, the UI is showing its age more than ever. By using APEX to replace the UX of key processes in EBS, you can bring the joy back to ERP for your users. Applications that bring users joy are known to have higher adoption rates and bring more smiles. Using APEX to modernize your existing EBS implementation can buy the time you need for Cloud offerings to match the functionality that you need to run your business.