The objective of this article is to provide a quick explanation on the responses that APIs can provide when an import is submitted, in particular regarding the dump logs generated.This content is suitable for Model Builders comfortable with APIs.
We need to keep in mind what type of import we want to achieve. Indeed, the responses and the dumps will be different, depending on what you are trying to import; data in a module needs different indications than items in a list.
When importing data in a module, having the same code in the source will automatically aggregate data based on the code. When importing in a list, lines using the same code will be considered duplicates.
For the sake of clarity, we will use the following module as an example:
In that module, you have:
To update that module, we need to import data, as opposed to importing master data.
Let's use the following file:
If you perform the import, there won’t be any error:
Let's edit the month for one line with a spelling issue.
You will get an obvious error:
The log will be showing one line:
Conclusion: when importing data into a module, if an identifier is invalid, the line containing this error will be listed in the dump of that action.
There are 2 possibilities:
Let's try to import data into line items that are calculated. We will use the following file:
In that case, Current Alloc cannot be updated as it is the result of a calculation. The result will then be:
There will be no dump if you click on ‘Details.’
Let's try to import data into a parent. We'll choose 'Q2 FY17' as a parent of a time member.
Note: Current Alloc is a calculation and will ignore attempts.
We get the following response and no dump:
We are reproducing the same steps as above through API calls; Let’s import data in a module with the incorrect mapping (spelling error Nay 17).
所示,status is "Complete." (Line 18) as the import did go through.
Rejected lines through APIs will only be generated for the lines that have wrong identifiers (like Nay 17 instead of May 17).
‘Ignored’ lines won’t be mentioned for line Items calculated or consolidated in a hierarchy.
Let's try to update the list that contains our two elements—MSFTE and GOOGLA.
The main difference with the previous case is that we will be targeting master data (lists and properties). Therefore, we will have dumps that will be slightly different from the previous case.
Note: we will use the "Code Only" type of import.
If we use the following import file, no issue will come up:
And the API will send back that two elements were updated (even though no change occurred).
Let’s introduce some errors to see the behavior.
Let's add another line with an already-used code.
In that case, we will get a warning (not an error!) that indicated that a row has already been processed with that key.
Why a warning? Because the first occurrence of the code has been successfully processed and then, technically, the import did go through and made changes.
We will then get a dump file with the rejected lines:
Note that, unlike the module import, a new technical column, called ‘_ Status _’ is added to the dump. In that case, it is empty.
If we use the following file, we will generate a failure:
In the dump file, we will get the rejected lines:
Note that the ‘_ Status _’ column is not empty this time.
If we look at the API dump:
As you can see, the column ‘_ Status _’ contains an "E" as Error.
Let's add a duplicated line, similar to line 2.
In the API dump log, you will get an error lineANDa rejected line.
If we add another duplicated line:
You will get asecondrejected line:
We can consider that the 2nd rejected line is an "ignored" error.
In the case of import into a list, when an error line is repeated several times, in the dump log, you'll get a first line in error and the other similar lines will be rejected.
Conclusion
Dump file format depends on the type of imports they are targeting: line items or lists.
Into lists, an additional column will help to distinguish if the line is the first error occurrence. For the other similar errors, they will be considered as "ignored" but related to the same first occurrence error. This explains why they appear in the dump file: we can consider that they represent the "ignored" lines of errors.
Did you like this content? Do you have other cases you would want to see added here?
Let us know in the comments thread below.