Azure Data Factory V2: MDX Query on SAP BW exception Microsoft.DataTransfer.Common.Shared.HybridDeliveryException

Question

I am trying to fetch data from SAP BW system into Azure Data Lake using MDX Query in SAP BW connector. But I am getting exception message in Azure is following :

{
    "errorCode": "2200",
    "message": "Failure happened on 'Source' side. ErrorCode=UserErrorInvalidDataValue,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Column '[Measures].[SomeMeasure]' contains an invalid value '4.000-2'. Cannot convert '4.000-2' to type 'Decimal'.,Source=Microsoft.DataTransfer.Common,''Type=System.InvalidCastException,Message=Specified cast is not valid.,Source=Microsoft.DataTransfer.Common,'",
    "failureType": "UserError",
    "target": "Copy1"
}

From the error, I can understand there are some values in Measures which is not actually numeric value. Changing or correcting value in the SAP system is not in my scope. Is there any option in the Data Factory V2 for SAP BW connection so that I can define the data type of the Measure for input and/or output. or there is any fine-tuning in the MDX query so that I can fetch the data without any error?

This is my MDX Query :

SELECT 
{[Measures].[SomeMeasure]}  ON COLUMNS,
NON EMPTY
{ [0COMP_CODE].[LEVEL01].MEMBERS *
[0COSTELMNT].[LEVEL01].MEMBERS }
ON ROWS
FROM SomeQube
  WHERE {[0FISCPER].[K42015008]}

Answer 1

If you could skip that incorrect rows, you could set enableSkipIncompatibleRow in as true. Please reference this do c.

Answer 2

Your filter is incorrect. SAP 0FISCPER dimension is in YYYYMMM format. You need to enter WHERE {[0FISCPER].[2015008]}. I am almost certain the "K4" you entered there is your fiscal year variant, which you should not put there. Objects like this K4 are called compounding infoobject (which your fiscal year/period belongs to if you envision it as hierarchical parent/child structure). But in this specific case, you don't need to specify fiscal year variant. Just remove K4.

I highly advise against skipping "incorrect rows". My guidance to you is that you should always fail the job whenever exception happens and investigate the data quality issue. Do not ever put enterprise data integrity at risk. SAP data has to be 100% accurate, not 99.9999%.