Introduction
In my previous post, I opined that APEX was coming of age in the Cloud Era. Actually, I could go further than that and say APEX was born for the Cloud. APEX has been a Cloud based PaaS service before PaaS was a thing (think apex.oracle.com). It has a natural container in the Oracle Database and the development environment is purely web based. Essentially, all you need is a URL and you can get started. That's about as cloudy as you can get (yes I believe cloudy is now a thing).
Also consider how the APEX product has evolved to add a fantastic UI to it's existing data processing pedigree. There is no more powerful a data processing engine than the Oracle database. Couple that with a now aesthetically pleasing and functional UI and you have the complete web development package. Add to that, sophisticated web service hosting and consumption capabilities and the possibilities are seemingly endless.
All of this makes APEX is a natural choice for extending Oracle's Cloud ERP. A topic which I will expand on in this post. I will discuss four use cases where APEX and Cloud ERP could meet and dive into a use case for each.
Also consider how the APEX product has evolved to add a fantastic UI to it's existing data processing pedigree. There is no more powerful a data processing engine than the Oracle database. Couple that with a now aesthetically pleasing and functional UI and you have the complete web development package. Add to that, sophisticated web service hosting and consumption capabilities and the possibilities are seemingly endless.
All of this makes APEX is a natural choice for extending Oracle's Cloud ERP. A topic which I will expand on in this post. I will discuss four use cases where APEX and Cloud ERP could meet and dive into a use case for each.
Cloud ERP/APEX UI Mashup
This use case was the focus of my previous post Oracle Cloud ERP and APEX PaaS Mashup. In this use case, we are focused on supplementing ERP Cloud functionality with APEX UI components embedded within the Cloud ERP UI. This approach means the user never leaves the comfort of the Cloud ERP UI.
Convert a Salesforce Prospect to a Cloud ERP Customer
The example use case involves an APEX page being embedded in a tab within Cloud ERP. The embedded page allows a Cloud ERP user to search prospects (in real-time) from Salesforce, identify a specific prospect and click a button to convert the prospect to a Cloud ERP customer.
Behind the Scenes
When the user opens the APEX page in ERP Cloud, a Java Web Token (JWT) is generated by Cloud ERP and passed to APEX. APEX verifies the JWT, authenticates the user and returns a search page to be rendered in the Cloud ERP window. Once the user enters their search criteria, APEX calls a Salesforce REST service to fetch prospect data and displays it in a table on the embedded APEX page. When the users identifies a prospect and clicks convert, APEX calls a web service in Cloud ERP to create the customer and tag it with the ID of the Salesforce prospect. APEX will then call a REST service in Salesforce to mark the prospect as converted and update field with Cloud ERP Customer number.
The example use case involves an APEX page being embedded in a tab within Cloud ERP. The embedded page allows a Cloud ERP user to search prospects (in real-time) from Salesforce, identify a specific prospect and click a button to convert the prospect to a Cloud ERP customer.
Behind the Scenes
When the user opens the APEX page in ERP Cloud, a Java Web Token (JWT) is generated by Cloud ERP and passed to APEX. APEX verifies the JWT, authenticates the user and returns a search page to be rendered in the Cloud ERP window. Once the user enters their search criteria, APEX calls a Salesforce REST service to fetch prospect data and displays it in a table on the embedded APEX page. When the users identifies a prospect and clicks convert, APEX calls a web service in Cloud ERP to create the customer and tag it with the ID of the Salesforce prospect. APEX will then call a REST service in Salesforce to mark the prospect as converted and update field with Cloud ERP Customer number.
Standalone Cloud ERP Connected Apps
The second use case involves incorporating live and cached Cloud ERP data in a standalone APEX Application.
Consolidated Management Dashboard
In the use case example, an APEX dashboard is built which pulls financial summaries from Cloud ERP via calls to the BI Publisher web service. This data is incorporated (in real time) with data from an on premise treasury system and financial data from a subsidiary which is running SAP. APEX provides sophisticated charting capabilities to provide visualizations for the data to facilitate decision making.
Behind the Scenes
Users would authenticate into the APEX application using their Cloud ERP credentials. The challenge here is that there is currently no user authentication service available in Cloud ERP. You can work around this by making a call to any web service using the users Cloud ERP credentials. The response will determine if the username and password are correct and allow them into your APEX application. Once in the application, you would utilize the users credentials (for the duration of the session only) to call SOAP and REST based services in Cloud ERP to fetch data.
You can build custom BI Publisher (or OTBI) reports to provide pre-summarized data in XML format and call these reports using the BI Publisher web service to pull the data into APEX. That way, Cloud ERP does a lot of the heavy lifting and you are not pulling thousands of records across the network. You will want to consider caching certain data in the local (local to APEX anyway) database. This will significantly reduce latency in making multiple calls to the Cloud ERP web services. Lookups, currency conversions and additional data manipulation can be all performed in the APEX database.
In the use case example, an APEX dashboard is built which pulls financial summaries from Cloud ERP via calls to the BI Publisher web service. This data is incorporated (in real time) with data from an on premise treasury system and financial data from a subsidiary which is running SAP. APEX provides sophisticated charting capabilities to provide visualizations for the data to facilitate decision making.
Behind the Scenes
Users would authenticate into the APEX application using their Cloud ERP credentials. The challenge here is that there is currently no user authentication service available in Cloud ERP. You can work around this by making a call to any web service using the users Cloud ERP credentials. The response will determine if the username and password are correct and allow them into your APEX application. Once in the application, you would utilize the users credentials (for the duration of the session only) to call SOAP and REST based services in Cloud ERP to fetch data.
You can build custom BI Publisher (or OTBI) reports to provide pre-summarized data in XML format and call these reports using the BI Publisher web service to pull the data into APEX. That way, Cloud ERP does a lot of the heavy lifting and you are not pulling thousands of records across the network. You will want to consider caching certain data in the local (local to APEX anyway) database. This will significantly reduce latency in making multiple calls to the Cloud ERP web services. Lookups, currency conversions and additional data manipulation can be all performed in the APEX database.
Standalone Mobile APEX Apps
APEX utilizes a responsive theme which works great to automatically adjust the UI as you move from desktop to laptop to tablet. APEX also has excellent mobile capabilities when you need the simplicity of a purely mobile UI. This aligned with APEX's rapid application development capabilities allow you to build opportunistic mobile apps to empower your workforce.
An example use case could be to provide project managers a mobile UI using APEX that allows them to capture images of the worksite and upload them as attachments to a project in Cloud ERP.
I won't go into behind the scenes detail here, as aside from utilizing a mobile UI, the rest of the approach is the same as my previous example.
An example use case could be to provide project managers a mobile UI using APEX that allows them to capture images of the worksite and upload them as attachments to a project in Cloud ERP.
I won't go into behind the scenes detail here, as aside from utilizing a mobile UI, the rest of the approach is the same as my previous example.
Integration Platform
The final use case I want to cover is utilizing APEX (and ORDS) as a light weight integration platform. When used in conjunction with APEX and ORDS, the Oracle database has pretty much everything you need to integrate your cloud SaaS solutions. The database provides a scheduler for scheduled events, there are AQ tables for queue based integration patterns, PL/SQL for orchestration, mapping and transformation logic, local tables for data storage, APEX APIs for consuming REST and SOAP services and finally ORDS to host REST endpoints.
At this point, I can almost hear the sharp intakes of breath from the SOA purists. I would say, however, if you are advising your small to mid-size Cloud customer, can you honestly justify thousands of dollars a month for the all in solution when you could be spending as little as $175/month for Exadata Express? I am not advocating GE do it this way but it is fit for purpose for many customers.
Use Case: Employee Synchronization
An example use case is a customer who needs to sync employees between Workday and Cloud ERP. A scheduled database job in your APEX database runs and pulls employees added/changed in the past 5 minutes in WorkDay. I then performs transformations on the data and calls a REST service in ERP Cloud to propagate the change there.
Guess what, because we have APEX in our database, we can build automated email alerts when something goes wrong. We can also build a monitoring UI to keep track of what's going on.
At this point, I can almost hear the sharp intakes of breath from the SOA purists. I would say, however, if you are advising your small to mid-size Cloud customer, can you honestly justify thousands of dollars a month for the all in solution when you could be spending as little as $175/month for Exadata Express? I am not advocating GE do it this way but it is fit for purpose for many customers.
Use Case: Employee Synchronization
An example use case is a customer who needs to sync employees between Workday and Cloud ERP. A scheduled database job in your APEX database runs and pulls employees added/changed in the past 5 minutes in WorkDay. I then performs transformations on the data and calls a REST service in ERP Cloud to propagate the change there.
Guess what, because we have APEX in our database, we can build automated email alerts when something goes wrong. We can also build a monitoring UI to keep track of what's going on.
Random though on Cloud ERP REST Services
While not directly related to this blog, I do want to mention that at the time of writing this post, Oracle seem to be in the process of moving their Cloud ERP SOAP web services to REST. Currently, the Human Resources and Projects modules have good REST coverage. I am fervently hoping that Cloud ERP's trend toward REST continues as it will open the door for a lot of innovation (and greater adoption) of these valuable integration points.
A Note about Security
I would be remiss if I did not mention that you need to be extra careful with security. In all of these use cases, we have web applications exposed to the internet. APEX has excellent security capabilities and is actively monitored and patched by Oracle to keep up with today's security demands. You do, however, need to make sure you follow best practices when developing your APEX applications.
Licensing Considerations
Please do talk to your Oracle Salesrep regarding an potential licensing implications regarding the above.
Conclusion
To be honest, we are barely scratching the surface in terms of possibilities. I do hope you can see some of the potential for utilizing APEX as a PaaS platform for Cloud ERP.
RSS Feed