Problem sending IDOC to R3 with wmPartnerMgrgatewaytransportALE%3cIMG SRC%3d%22httpwwwwmuserscom ...

Hello together,

we try to convert CSV-Files to UTILMD IDOCS.
Everything works fine, but last step the OutboundProcess make Problems.
I have a Structure in a recordlist ‘ISU_VDEW_UTILMD30D_CSV/ISU_VDEW_UTILMD30D_CSV/C_LINE_ITEM’.
For each C_LINE_ITEM, need to create an IDOC.
I loop over ISU_VDEW_UTILMD30D_CSV/ISU_VDEW_UTILMD30D_CSV/C_LINE_ITEM and map the
data in IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40.
With the first loop everthing is correct. The IDOC is send to the SAP-System.
Second and the following loops, IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40 are correctly filled, but no IDOC is send.
I also tried to use pub.sap.transport.ALEutboundProcess without success.

For better understanding, here a view on the flow.
loop over /ISU_VDEW_UTILMD30D_CSV/ISU_VDEW_UTILMD30D_CSV/C_LINE_ITEM

  • mapC_LINE_ITEMToIDOC
  • OutboundProcess

I have no idea, what´s going wrong.

Thanks in advance
sure

Hello,
Make sure that none of the common data(control record, header data, SAP Server) are dropped within the loop. Just try tracing and checking the values before the OutboundProcess.

HTH
BS

Hi,

with every loopstep the IDOC_CONTROL_REC_40, IDOC_DATA_REC_40 and the servername are correctly filled.
Is there possibly one value i need to drop?

Thanks in advance
sure

Hello,
I dont think so, you need to drop anything.

“OutboundProcess” must have the following inputs correct ?

  1. server under transportParams as a string (Server to be defined in the SAP servers in the server)
  2. Control Record as a record list
  3. Data record as a record list ( you must have converted the record list format into flat format using pub.sap.idoc:transformHierarchyToFlat)
  4. $action can be set to “1” which means to create an IDOC

or I guess you have used the wrong OutboundProcess service.

You can try “pub.sap.transport.ALEutboundProcess”

Hope this helps.
Bhavani Shankar

Hi BS,

thank you for your help!

I cecked points above.
-Server is defined and transportParams server is set.
-ControlRecord is a record list.
-record list is transformed to flat hirarchy.
-$action is set to 1.

The thing that suprise me, is that one IDOC is created at the first loopstep and at the next loopstep no IDOC is created, although all parameters were mentioned are correct.

Please help, i´m spinning round!

Thanks in advance
sure

Hi sure,
Alternative suggestion? Can you create a Routing rule for this? Instead of calling the outboundProcess directly, you can invoke the service created by the routing rule (available in the Default directory). By this you achieve the possibility of knowing the transaction details in the browser. (Each call of the above service is logged completely with full details)

I dont find anything wrong in the earlier set up, but just to trace the problem more, would suggest to go for the routing rule based transfer.

Let me know if you need more help…
BS

Completion!

At the second and third loopstep, there are some values in the pipeline
i dont know:
$runtime
$rfctime
$call

$runtime value at second loopstep is “782”
$rfctime value at second loopstep is “766”
$call value at second loopstep is “false”.
$call at third loopstep also “false”.

Is it maybe a runtime-problem?

TIA
sure

Did it work?

Well looks like the IDOC size is very big and the timeout specified for the RFC connection is less.

Just try with a smaller IDOC and check whether the loop works? !!

All the best
BS

Hi bash,

no it doesn´t work.
Maybe the $runtime- ,$rfctime-values are because the slow debugging.

I would gladly learn more about this and try out the alternative suggestion, but i dont know how to handle.

TIA
sure

Hi Sure,

Try dropping the “$tid” variable at the beginning of the flow service.

Hugo

Super, thanks a lot!
It works!

First i set the value of $tid with a blank.
It becomes visible in pipeline out.
Then i dropped $tid in the pipeline out, and delete the “set value”
in the outboundProcess.

Thank you very much hugo and bash for your great help!!!

:slight_smile:
sure