I noticed that the blog “Oracle HCM Cloud REST API how-to miniseries I” is getting popular and today I am going to continue on the topic related to REST APIs in the Oracle HCM Cloud.
I would like to share one important point related to the REST API calls. It’s a REST API framework version.
You may utilize new features or enhancements by specifying a framework version. Depending on the version, functionality for accessing business objects will be different.
Today I would like to talk about one crucial point in the Oracle Cloud Applications lifecycle. There are thousands of customers around the world that use Oracle HCM/ERP/EPM/CX Cloud Applications. A SAAS delivery model gives them many more benefits over the on-premise deployment but they also face some inconveniences. The main pain point is the quarterly updates. All customer PODs are updated at least 4 times a year and those are mandatory. You can’t skip or reschedule them.
Non-production environments: First Friday of your Quarterly Update month. The exception is the Middle East, where the update is applied on Thursday. Production environments: Third Friday of your Quarterly Update month. The exception is the Middle East, where the update is applied on Thursday. You can review the Oracle Applications Cloud – Standard Update Policy document here: https://support.oracle.com/epmos/main/downloadattachmentprocessor?attachid=1966109.1%3APOLICYSTND-MAR19&action=inline It means that customers have only 2 weeks’ time slot to test all the processes to make sure there are no issues after an update. This very time and resource-consuming process because the number of transactions to be tested may reach hundreds. It is a real challenge for IT support or shared service departments. But there is a solution that intended to extremely simplify testing of all UI transactions every quarter and it is based on test automation framework.
Let me briefly explain how it works:
Use Selenium IDE – to record a test script
Export to Python
Create a TestCase based on the generated python code adopting a Python unittest data driven framework