Part 10 of 12 in the Oracle EPM Cloud REST API series.
Business rules are one common target for automation. Getting data into Planning in the first place, actuals from a source system, a budget file from a business unit, is another, and it uses the exact same jobs resource covered in parts eight and nine.
The request
{
"jobType": "IMPORT_DATA",
"jobName": "ImportDataJob",
"parameters": {
"sourceType": "Planning",
"importFileName": "myImportfile123.zip",
"delimiter": "comma",
"dateFormat": "MM-DD-YYYY"
}
}
Sent to the same endpoint as a business rule, as a POST to .../applications/Vision/jobs, with the same headers covered in part seven.
The parameters explained
sourceType tells Oracle where the data is coming from. Planning is the typical value for a file already staged for the Planning data load process. Essbase is also supported as a source, and when it is used, a cube parameter becomes required alongside it.
importFileName points to the file itself, in ZIP, CSV, or plain text format, which needs to already be uploaded to the application's inbox before this call runs. Automating that upload step is a separate call to build into any full pipeline, ahead of the import job itself.
delimiter and dateFormat tell Oracle how to parse the file's contents once it starts reading, matching whatever format the source system actually produced.
Same pattern, different payload
Notice what did not change from the business rule example two posts back: the endpoint, the headers, the overall submit-then-poll shape. Only the jobType and parameters are different. That response comes back with the same jobID, the same status field using the same negative one through four scale, and the same polling approach from part nine applies without modification.
This is the real payoff of learning the jobs resource once, properly. A script built to submit a job and poll it to completion does not care whether that job happens to be a rule or a data import. Swap the payload, reuse the polling logic, and a whole new category of manual work becomes scriptable.
Where this fits in a real pipeline
In practice, importing data is rarely the only step. A typical automated close night might upload a file, run this import job, then chain directly into a business rule that consolidates the newly loaded numbers, all from the same script, each step waiting on the previous job's completion before firing the next request. That chaining is exactly what parts eight and nine built the pieces for.
Next in the series: the other job type that gets a post of its own, refreshing a cube, which usually follows right after a metadata change.