on 11-07-2013 7:12 AM
Scenario is: TDLINE is having 8388 repeated segments which we need to concatenate and finally pass to amendment node which is a string with no limitation. TDID is for condition checking.
We have written the UDF for concatenation.
When we are testing inside the graphical mapping test tab then the final output is having all 5 lacs 53 thousand characters by concatenating 8388 segment data.
But when doing end to end testing by posting an IDOC the final string is having : 65 thosand 878 characters in the output xml file.
note: using receiver file adapter to put the xml file to a desired FTP location.
Did delta cache refresh but we are not getting the xml file which has the full string.
Please help me whether I am missing something or not.
Hi Malini,
Use some comparison tools like notepad++, text-pad to determine the extra characters for the field received after end to end testing to MM one.
Based on extra characters you can get some direction to work on.
Also few characters are displayed as multiple characters like & as &
Regards,
Pranav
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Malini
For the end to end test message try to see the complete logs in NWA.
We have faced a situation in past where the map was generating an stackoverlow error which was visible in nwa trace but the message was successful in MONI.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
1. for your TDLINE, on which Context you are ? only the level1 or level2 of your IDoc.
you probably catched only entry of the 1st context.
2. you perhaps have one IDoc segment (item text?) for which you have NOT this TDLINE when TDID =xxx, and so you could have a bad behavior. Depending on your target field (item or header level ?), check if with option "keep SUPPRESS" of IF...ELSE, it's better.
3. Test your mapping with your XML payload found in SXMB_MONI.
4. Last check, does your UdF is defined with "all value of Context" or with "all values of Queue"?
regards.
Mickael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Mickael, Thanks for your inputs.
1. TDLINE is under the root context means the level 1 of the IDOC.
2. target filed is under the item not header. should I remove the UDF used: RemoveSuppress?
3. using IDOC xml downloaded from SXMB_MONI only.
4. my UDF is all value of queue.
Please give your input.
Thanks in advance.
Hi Malini,
here's a code I used several time ago... the mains difference is to working with ChangeContext.
public void ConcatArray(String[] value,ResultList result,Container container){
StringBuffer sb = new StringBuffer("");
for (int i=0; i<value.length; i++) {
if (!(value[i].equals("__cC_")) || (i==value.length-1)) {
sb.append(value[i]);
}
if (value[i].equals("__cC_") || i==value.length-1) {
result.addValue(sb.toString());
if (i!=value.length-1) {
result.addContextChange();
}
sb = new StringBuffer("");
}
}
UdF with "Queue" option.
result:
About KeepSupress, I think you have to keep it. but do some tests.
Mickael
Log file attached q10418390-1.txt
Log file attached q10418390-2.txt
Check the payload for entire content is there after mapping process. Believe the context changes are handled
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Malini,
did you test with the same payload in mapping also?
means dowload the payload from moni and test it in Mapping;
Regards
Gagan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
83 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.