​Since APEX 18.1, there has been a new way to call OAuth2 Client Credentials secured web services using APEX_WEB_SERVICE. This new method alleviates the need for developers to store OAuth2 credentials, manage token expiration and also has potential performance benefits. In this post I will describe the new approach and its benefits.

In the OAuth2 client credentials flow you must first call a token web service, passing a client ID and client secret. If these credentials are valid, the token service will then pass back a token. The token can then be used to call certain secured web services covered by the token. The token returned by an OAuth2 client credentials service looks something like the below.

I must confess that I can get stuck in my ways. It often takes a weekend and a few hours buried in the APEX API guide for me to get caught up with the latest and greatest. Case in point, I have been using APEX_WEB_SERVICE for several years and most of my code to call web services secured by Ouath2 Client Credentials looks like this:

1. Fetch token service URL, Client ID and Client Secret from a custom table.
2. Call the OAuth token service to get token using APEX_WEB_SERVICE.
3. Optionally store the token for use again (within its expiration window).
4. Call the main web service using APEX_WEB_SERVICE, passing the token.
5. Repeat as many times as the user calls the web service.

 
Don’t get me wrong, this is still much more convenient than using UTL_HTTP. As a developer, however, I am still having to manage the following:

1. Storing the token end point and the client credentials (most likely not very securely).
   
2. Deciding when the token expires and fetching another token (more likely not bothering to do this and just getting a new token every time I call the main web service).

Of course, there are drawback to this.
 
Storing the Credentials
​I have to build an APEX page to store the token URL and credentials and also some APIs to set and get these values. I then have to build APIs to manage token expiration and decide when to get a new token. Finally, I have to maintain this code and nurse it through upgrades etc. All this was fun the first time but I would much rather have APEX handle this for me so I can focus on delivering business logic.
 
Securing the Credentials
This approach also introduces the obvious security concern which is that I may not be encrypting the credentials when I store them.
 
Performance
Unless you build code to store the expiration time for the token, you are most likely going to call the token service every time you call the main web service. While token services are usually pretty light weight, you are incurring an extra round trip from your database to the endpoint every time you call the main web service. This can add up to a second to every web service call which is noticeable to your end users.

Ever since the APEX development team introduced APEX 18.1 you could sense a shift toward making it easier for developers to talk to the outside world using APEX. This all hinges around the APEX_EXEC package and the drive toward making every APEX component equally as happy sourcing it’s data from a web service as it is from a SQL statement on the local database.
 
Since APEX 18.1 we can make calls to APEX_WEB_SERVICE without having to deal with first calling the associated token service or having to manage token expiration. This is made possible with the addition of 2 parameters p_credential_static_id and p_token_url. These parameters allow you to pass a reference to a set of ‘Web Credentials’ and the token URL to APEX_WEB_SERVICE and it will handle the REST (pun intended).
 
APEX_EXEC For all use cases that fit, I strongly encourage you to look into APEX_EXEC, instead of APEX_WEB_SERVICE. APEX_EXEC takes even more of the load off the developer and has a number of other advantages which I don’t have time to get into in this post. Carsten Czarski wrote a great overview in this post.

​As always, examples speak a thousand words. Before we can reference a set of Web Credentials in our code, we need to define them in APEX. Web Credentials are stored at the Workspace level. Once logged into your APEX Workspace, navigate to App Builder > Workspace Utilities > All Workspace Utilities > Web Credentials.
 
In addition to creating and editing Web Credentials in the APEX UI, you can also set them programmatically using the APEX_CREDENTIAL API (available since APEX 18.2). This API has a number of uses, one of which is to help when migrating new credentials to TEST and PROD instances.

​Note: When you edit Web Credentials APEX does not show you the client secret. It is there, you just can’t see them (for security reasons).

I now want to look back on the three drawbacks from the old five steps approach and see how the two extra parameters above have helped me. The main benefit of course is that we now have just two steps instead of the 5 steps in the original approach:

1. Call the main web service using APEX_WEB_SERVICE, passing Web Credentials Static ID and Token Web Service URL.
2. Repeat as many times as the user calls the web service (APEX handles fetching new tokens etc.).

 
Storing the Credentials
The OAuth2 Client Credentials can now be stored natively in APEX using ‘Web Credentials’. APEX provides a UI to manage these credentials and APIs to set these credentials programmatically.
 
Securing the Credentials
Using Web Credentials, even the Workspace Administrator is not able to view the client secret for a given client. In addition, although there are APIs to set the credentials there are none to get credentials. The only way to use them is via APEX APIs.
 
Performance
​When you pass values for p_credential_static_id and p_token_url you are essentially handing over management of the OAuth2 token to APEX. It will store the expiration for the token, and it will only get a new token when it needs to.
 
All this leaves you as a developer to focus on calling the main web service and parsing the results.

​The APEX development team continues to make it easier for APEX developers to work with REST based web services. This makes it easier and easier for developers to use cloud-based services like SMS, Address Verification, Machine Learning, Object Storage etc. etc. Having easy access to these cloud services allows developers to provide game changing features in their APEX apps.
 
Enhancement Request: It would be great if instead of having to pass p_token_url, we could pass the static id of the remote server plus a suffix for the token service end point. This would prevent us from having to store the URL of the token service in a custom table. Remote Servers are defined under ‘Remote Servers’ in the Workspace Utilities area (right above Web Credentials).

​As you may be aware, Exadata Express is coming to the end of its life. If you like us have found this platform both useful and affordable, then you will be wanting to know what’s next? Where in the cloud can I deploy my RAD (REST, APEX, Database) stack now? In this post I will explore an alternative which we have implemented here at JMJ Cloud.

​We have been using Exadata Express and JMJ Cloud for more than 2 years. During that time, we helped five of our clients implement Exadata Express. Use cases ranged from custom cloud point solutions to ERP Cloud PaaS extensions. I have also blogged about this platform on a number of occasions. Exadata Express offered a highly functional PaaS solution for as little as $175 a month. We (and our customers) were very happy with it. In fact, I thought this product was a sign that Oracle had finally turned the corner to becoming a major cloud player. It provided a very low barrier to entry with more feature rich alternatives ready and waiting when your business grew into them. This is essentially how AWS became so successful. One day you start with half a dozen EC2 servers for a couple of hundred dollars a month and a few years later you are spending a million dollars a month (think Netflix). Oracle on the other hand typically starts by charging a lot and then work their way up from there.

A month or so ago, our Salesperson emailed us… Here is where I need to pause for a small rant. Why on earth, if you are selling automated cloud solutions should I ever have to deal with a Salesperson? I want a server; I know what size server I want, and I know how much I want to pay for it. From my perspective, having a Salesperson in the middle of this is expensive from Oracle’s point of view and extremely frustrating from my point of view. OK, back to the story… Our Salesperson reached out and said we could not renew our Exadata Express contract and oh, by the way, you have a month to get off the platform. After a little discussion (i.e. an hour of my time on the phone) we converted that 1 month into 3 months. We bought ourselves some runway, but we still needed another platform. Enter the Salesperson (again). After another one hour of my time he proceeded to explain the wonders of the Autonomous Database Cloud Service. Don’t get me wrong, this service shows a lot of promise and it is going to be great for our larger customers. At more than $1,200 per month, however, it is not going to fly for us or our smaller customers wanting to run the RAD stack in the cloud. It is nearly 7 times more expensive than Exadata Express. If you wanted to use Autonomous Database with APEX for a Cloud ERP extension and you need a DEV, TEST and PROD instance that is $3,600+ per month instead of $600 / month.
 
To add insult to injury, there is not even a button push migration path from Exadata Express to Autonomous Cloud. This means that even if you have the money to pay for Autonomous Cloud, you are going to have to fork more money to migrate.

I would love nothing more than to say I whole heartedly recommend folks move to the Autonomous Database Cloud Service but that is not where I am going. The answer to our problem was in a service we have dabbled with before which is Amazon’s RDS (relational database service) service along with an EC2 (elastic compute) server running ORDS. I have never really been completely happy recommending this approach for the RAD (REST, APEX, Database) stack before, two things have changed to make this a much more appealing approach.

• You can now perform a full ORDS install on an RDS instance. This is thanks to new functionality in ORDS 19.1 which allows you to run the install as a user other than SYS. This is especially important now that REST services are no longer available in APEX alone.
• AWS have started making the latest version of ORDS available on RDS much sooner than they used to. For example, as of right now, September 2019, you can run ORDS 19.2 and APEX 19.1 on RDS, whereas Exadata Express is running ORDS 3 (ouch) and APEX 18.2.

​The diagram below shows the architecture we are using at JMJ cloud.

Here is a cost breakdown for the above architecture.

There is no perfect solution and there are certainly some things you should consider when moving to AWS.

• Although the database is almost fully managed by AWS, you are on your own with regard to the ORDS server. You need to standup an EC2 server and install ORDS, Tomcat, setup your load balancer etc. This means it is not as hands off as Autonomous Database Cloud Service.
• At time of writing, there is no way to install APEX PSE Bundle Patches to an RDS instance. Depending on the bug, this could be a big deal.
• For license included versions of the Oracle Database, Standard Edition 2 is way more affordable than Enterprise Edition. If you have specific use cases that require Enterprise Edition features, then keep an eye on your costs.
• Although AWS takes care of patching the DB server, you will be responsible for patching the EC2 server and upgrading Java, Tomcat and ORDS.

​I am not saying RDS is a magic bullet that allows you to achieve the hands-off capabilities of the Autonomous Database Cloud Service at a fraction of the cost. If you have the budget and you want absolutely nothing to do with the underlying architecture, then Autonomous Database Cloud Service is for you. If you want lower level access to the database (and / or ORDS) but want to be absolutely sure the database itself is being backed up and patched for you then it offers a great alternative. If you throw in easy access to other AWS services, this soon becomes a very compelling solution.
 
After all, for developers, the health and welfare of the database is really the scariest part of running your own RAD stack. If AWS is essentially taking care of this for you, the rest is reasonably straight forward.

​Full disclosure, I have absolutely no experience in trying to convince my boss to try APEX or ORDS. I do, however, have experience in basking in the glow of clients who have reaped the benefits of implementing mission critical systems using these two no-cost options of the Oracle database.
 
TL;DR; If you are a boss, try out APEX and ORDS today. If you already have an Oracle database, it costs you nothing extra and the upsides for you and your business are tremendous.

​If you are a developer looking to convince your boss to adopt APEX and ORDS, then this post is for you. My goal is to arm you with the material you need to make a compelling case for adopting APEX and ORDS. I have broken the post into several major talking points. At the start of each talking point, I have a headline statement (for bosses with short attention spans). I then go on to explain my reasoning in a little more detail (for bosses that need some evidence).

​Data Centric - APEX, because of its architecture, is very data centric. Both the code and the data exist in the same database enabling zero data access latency. This architecture did no come about by accident; there are good reasons why your code should be right next to your data. I have been using APEX for a while now, but I love this new term ‘zero data latency’. Of course, this has been true since the days of HTMLDB. But in this world of super complex, mega frameworks that are so abstracted from the data they need a map to find it, it is very relevant today.
 
Stateless – Much of the scalability of APEX comes from its stateless nature. The API calls to the Oracle APEX engine use the standard Oracle database connection pool. This means that once an API call is processed and the response is sent back to the browser, the connection is returned to the database connection pool and can be used by any other request. The database sessions are only active when performing a request, otherwise, the they are inactive and do not consume any database resources. This allows APEX to handle tens of thousands of users simultaneously.

APEX is very stable, easy to upgrade and new features are coming thick and fast.
 
You may think stability and innovation don’t belong in the same sentence. When you are talking about APEX, however, they really do. I have never undertaken a large JavaScript framework project. I can imagine, however, that as a boss it is a little un-nerving heading into a multi-year project with half a dozen technologies, many of which may not exist by the time the project is over. APEX has been around for 15+ years and there is no sign of it going anywhere. You may think, “So what, Windows has been around for longer and it is still awful.”. APEX is different. The pace of new (and useful) features over the past 2-3 years (especially in the areas of UI, Single Sign On and integration capabilities) has been fantastic. BTW, there is no sign of that pace letting up. With multiple releases a year you get the option of up taking these improvements at regular intervals.
 
Hold on a minute, that doesn’t sound very stable. What I haven’t mentioned is that the APEX development team is world famous for providing upgrades that do not break your existing Apps. One of the ways they achieve this is by allowing apps to run in previous versions with ‘Compatibility Mode’. This means that in most cases, you can do the upgrade and then switch on new functionality in individual apps, as and when you need it. There are stories every month of APEX users who have upgraded from APEX 3 (released in 2007) to the current version without anything breaking. Can you imagine doing that with any other development framework?

Your users will love using APEX Applications!
 
If you had experience of APEX from version 4 (or before), boy are you in for a treat. Applications built with APEX look as good as any other framework and are quite frankly a joy to use. We are long past the dystopian days of automaton workers using systems they are forced to use. When people use Enterprise systems these days they expect more. While you may feel like dark mode is a fad, Apple is about to release it across all of the Operating Systems. Believe me, your Enterprise users will be using dark mode soon enough. Wouldn’t it be great if your development platform could make dark mode happen at the flick of a switch? APEX has your back. Dark mode is already available in APEX Builder and will be coming soon as an end user theme style. It goes much further than that too. APEX’s Universal Theme delivers UI components that would otherwise consume hundreds of hours of custom development. For a peak at what is available, check out the Universal Theme demo App https://apex.oracle.com/ut
 
Finally, with accessibility concerns finally being taken seriously, it is good to know that the APEX team has baked accessibility checks right into the product. They even have accessibility tested themes available. Check out this video for more details on Accessibility in APEX.

​APEX and ORDS provide you everything you need to host and consume REST based web services to meet all of your integration needs.
 
Oracle REST Data Services (ORDS) has two roles in an APEX world. One is to service APEX pages to end users and the other is to host REST based web services. The ability to host REST based web services based on SQL and PL/SQL is extremely powerful. It allows you to provide external systems secure access to the data in your Oracle database. This can be useful for integrations and even for hosting web services to be consumed by native mobile applications. See our post on ORDS for details.
 
APEX comes with a number of features to facilitate consumption of any REST based web services. For example, Web Source Modules provide a wizard-based approach to configuring components that allow you to create reports and forms directly on web services. This extends the reach of APEX outside the database and prevents un-necessary syncing of data to and from other systems. 

With APEX Social Sign-In you can use just about any OAuth identity provider to authenticate your users.

Authentication can be a complex proposition. If you store usernames and passwords yourself you really need to know what you are doing. The last thing you want is for your user account data to be compromised. It is generally far safer to outsource this task to a trustworthy identity provider such as Okta or Auth0. You could also outsource this task to platforms your users already use such as Office 365, Google and even Facebook. 

​By providing the ability to create custom authentication schemes, APEX has always provided flexibility in authenticating users. Custom authentication schemes allow you to create code that could use just about anything to authenticate a user. Since APEX Social Sign-In was introduced in APEX 18.1, APEX authentication has reached a whole new level. You can now setup declarative authorization schemes for OAuth-capable identity providers and APEX handles calling the necessary web services to authenticate your user. Taking Okta for example. Okta can now be your source of truth for handling all authentication in your company. All of your other systems (Email, ERP and your APEX Apps) can then use Okta to authenticate your users. See our post on APEX Social Sign-In for more details.

​APEX provides many useful features and utilities out of the box, that would otherwise require numerous third-party libraries.
 
To name a few:

• Out of the Box Authorization
• Multi-Language and globalization features
• Sending Emails
• Email Templates
• Extensible plugin framework with hundreds of available plugins
• Building and parsing JSON
• Excel and CSV parsing
• Zipping and Unzipping files
• JWT Handling
• String manipulation utilities
• and many more…

 
The benefit of having these utilities bundled with APEX are that fixes and enhancements are handled by Oracle and released with each new version of APEX. In contrast, having these types of utilities spread out amongst a number of providers means you get fixes when they feel like. It also means that as those providers drop by the wayside you are left having to merge new libraries into your applications.

​APEX applications can be hosted in the cloud just as easily as on-premise.
 
The APEX architecture lends itself well to running in the cloud and there are numerous options for hosting APEX in the cloud.
 
PaaS - There are turn key PaaS solutions (e.g. Exadata Express from Oracle) that host the entire APEX and ORDS architecture at a very reasonable price. All you need is a credit card and a browser to get started. See our post on using APEX to extend Oracle ERP Cloud.
 
IaaS - You can also install APEX and ORDS yourself on infrastructure from just about any cloud provider. This allows you complete flexibility to size the environment as you wish, but you will need to perform much of the maintenance (backups, upgrades etc.) yourself.

​APEX is building on its high productivity heritage to establish itself as a legitimate contender in the Low Code space.
 
APEX has always been known for allowing developers to build useful, scalable applications in a very short period of time. Over the past year and a half, more and more features have been added to establish APEX as a top contender in the low code pace. These features include wizard-based development of web service integrations and pre-built components that can be added to existing applications or used to build brand new applications. APEX is already at the stage where you can build fully functional applications starting from the upload of an Excel spreadsheet. These kinds of features are allowing APEX to break out of the IT department and into the business. It is here where (handled the right way), citizen developers can become productive with APEX with just a small amount of oversight from IT. 

​Many of our customers run Oracle e-Business Suite and have a number of PL/SQL developers on staff. How to leverage this talent and still provide your users with applications they will love using? An experienced PL/SQL developer can be up and running on APEX in a matter of days. Five years of Oracle database, SQL and PL/SQL experience gives you about 70% of the skills to be a high performing APEX developer. Sprinkle in a little JavaScript, CSS and web services experience and you are 100% of the way there.

​APEX and ORDS are no cost options of the Oracle Database.  If you own an Oracle database license you own APEX and ORDS.
 
I purposely left this item to last because in my opinion, APEX and ORDS stand on their own against any enterprise-ready development platform. Having said that, if you own an Oracle database license you really should be using APEX and ORDS because it isn’t going to cost you a penny extra. In addition to the no extra cost for the software, you will also need very little additional hardware.  A VM with 4GB of RAM and 15GB disk is more than enough to host ORDS, which is the only other component you need.

It’s very hard to write a pithy conclusion to summarize everything I have said in this post. There are also, no doubt, a number of important APEX benefits that I have not included. If you read this post and you are a developer keen to bring APEX and ORDS into your organization, I encourage you to use some of this material to make a case. If you are a boss and you are looking to adopt a development platform that will deliver real value to your business, then I urge you to visit the following links to learn more about what APEX and ORDS can offer your organization:

• APEX Shortcuts
• APEX Office Hour Videos
• APEX Learning