I have created a job which loads data from legacy data source (an excel file) to SAP Idoc through a Data Services Job.
The data passes through without any error at DS end, which confirms that parameters like partner number, message type, segment name, data types etc are all correct.
However, the Idoc data doesn’t pass through at SAP side giving error for every idoc record as “No Parameters found for function module”. This is all so new for a DS person and SAP counterparts claim it being a DS problem.
Any sequence of steps to be performed at SAP+DS end, before we start loading the idoc data in SAP, specially for Z Idocs ?
I have attached snapshots of the error. Also, attaching snapshot of the zidoc structure for you all to understand the problem.
The most obvious case would be that the nesting levels do not match, e.g. you wanted to create an IDOC with one row in the EDI_DC40 schema but because of a change you did it is creating more rows now. This can happen easily if one does not pay attention. It can’t be that schema because then we could not deliver the IDOC at all but maybe something similar happened in the data structure.
Reading your error message on the SAP side I would guess that one sub-structure is not populated at all meaning zero rows for that.
Hence we can attack the issue from either side
Right before the loader you add an XML template object for testing. Then you load the data that fails and check the XML structure if it looks correct or not.
I assume in SAP you know why the IDOC is not being processed, and then we would have a pointer on where to check the dataflow.
Remember, in the nested schema model (short: NRDM), it depends which level is made current in the query and then different FROM and WHERE clauses are shown. And those two control how many rows go into the schema. Example:
Query
+COL1
+SCHEMA1
++COL2
If the from clause of the Query root level has TABLE1 and no where clause, that means you will have TABLE1 many rows. If SCHEMA1 is made current and would show TABLE1 as from clause as well, it would mean for each Query-row this schema has again TABLE1 many rows.
And if SCHEMA1 has a where clause that is not true, e.g. KUNNR=‘0000000000’ then SCHEMA1 has no rows at all (and when the IDOC starts to get booked the corresponding function module might say, sorry, I have no data in this table parameter. That’s my theory for your case.
As per the information shared by you, I checked the FROM and WHERE clauses of 2 segments (EDI_DC40 is control having 1 control data row and Z1DAT_CUST_HIER is actaul data with 1722 rows) possible for this IDOC Structure. I am attaching snapshots of both for your reference.
There is no WHERE Clause
The Number of rows required is equal to the Z1DAT_CUST_HIER Segment.
The other segment is a control segment (EDI_DC40) and hence information will be a single row repeating same values for all records of 2nd segment.
Please confirm what I have done is correct here.
Also, I am attaching output of XML file sample, which seems correct.
If you feel above configurations are correct, we can move on to SAP side. This being a critical test for DS to show its capabilities in Data Migration, I am eager to resolve the issue asap. Thanks a lot for the guidance.
So your goal is to create 1722 IDOCs, each containing one Z1DAT_CUST_HIER record? Shouldn’t be the other way around, one IDOC with the entire data? Hence swapping the from clauses?
No, it has to be 1722 distinct Idoc records. It’s just like plain data with no hierarchy.
Are the FROM clauses fine Werner?
I guess they are, because I have followed the implementation methods as done for Material and Customer Load idocs which have been running successfully.
Another point to bring to your notice is that the idoc is a customized created idoc, not a standard one. Is there are chance of missing some step by SAP team in creating idoc ready for DS to populate data.
They are now trying the LSMW methods and not going thru DS
If the IDOC is syntactically incorrect it would not be accepted by SAP on the input. As it is, it is now stored inside the IDOC input queue and when processed you get the error. Either because the IDOC is logically wrong structured or the booking process fails.
What I would like to get next is a screenshot of an IDOC they manually created inside SAP and was successfully processed and a comparison with the data a failed IDOC contains.
SAP Transaction /nwe19 is used to build an IDOC. But do not ask them to test it, ask them to come to your table and proof it to you their code is correct. And then deduct 1 week of consulting budget because a) your delay, b) them not testing, c) changing the entire architecture because of their incompetency.
PS: Yes, from clauses look okay then. And quite frankly, there is not much you can have done wrong. I thought the IDOC is very complex so was looking at a structural problem inside DS. But now I am pretty sure they never tested the code with the same data you used when sending the IDOC.
Apologies for delay, the issue got sidelined because of many others in the pipeline
Here is the screenshot attached as requested by you - left one being idoc data before processed through DS - right one being correctly processed manually by SAP end.
I could not find any difference in the two, leaving all of us in dilemma.
(BOB member since 2006-08-02)
(BOB member since 2004-12-17)
(BOB member since 2006-08-02)
