Closed GoogleCodeExporter closed 8 years ago
Hi henk-jan,
Testing this... slightly strange results.
If my script just has
return {'type':'out_as_inn','alt':'EMAIL'} # convert this mapped idoc to an email
Then result is 1 file in, 2 files out. But the second translation is missing
all it's data.
If my script has
out.ta_info['statust'] = DONE # discard this idoc
return {'type':'out_as_inn','alt':'EMAIL'} # convert this mapped idoc to an email
Then result is ok, 1 file out (the second translation) and all the data is ok.
However I cannot view the "intermediate" format anywhere in view details. This
is not totally a problem but would be nice to be able to see it.
If I wanted both outputs (I don't in this case but someone might) then this
does not work properly. I have attached a couple of screenshots.
Original comment by mjg1964
on 11 May 2012 at 1:17
Attachments:
With my existing routescript method it looks like this. I can view the
intermediate format.
Original comment by mjg1964
on 11 May 2012 at 1:22
Attachments:
hi Mike,
see plugin for setup that tests this.
Original comment by hjebb...@gmail.com
on 11 May 2012 at 1:36
I can't see a plugin for this, where do I find it?
Original comment by mjg1964
on 11 May 2012 at 11:25
hi mike,
I attached in the previous mail (which I also send to
mike.griffin@clipsal.com.au
Original comment by hjebb...@gmail.com
on 11 May 2012 at 11:37
hi Mike,
have you been able to test this?
Original comment by hjebb...@gmail.com
on 15 May 2012 at 5:50
Hi henk-jan. I have just been testing this some more. Your plugin works ok, but
your alt mapping just does inn2out. Mine is idoc to html-template, my inn.get
do not get any data from the input! will do more testing...
Original comment by mjg1964
on 16 May 2012 at 7:43
hai Mike,
my plugin is my test for the type of translation, it is somewaht more complex
what it does:
- translate order to fixed
- translate order to aperak (alt-translation)
- translate aperak to aperak
so: 1 incoming order generates:
- one fixed order
- 2 aperaks
(sorry, should have made mentioned this earlier)
Original comment by hjebb...@gmail.com
on 16 May 2012 at 7:48
yes, I understand your plugin and got it to work ok. The part that interests me
is the last step.
I want to:
- translate edifact to idoc order
if (some conditions):
- translate the idoc to html-template (alt-translation)
- discard the idoc
Since yours works, I need to find out why mine doesn't. In my alt mapping
script, inn.root.display shows the idoc data but inn.get's do not retrieve any
data. However using my original routescript method this mapping does work ok.
Original comment by mjg1964
on 16 May 2012 at 8:39
A clue! I tried an inn2out translation with the idoc, it fails (note the
trailing spaces).
MessageError: Grammar
"D:\python27\lib\site-packages\bots\bots.usersys\grammars\idoc.ORDERS05" has
(root)record "EDI_DC40"; found "EDI_DC40 ".
Original comment by mjg1964
on 16 May 2012 at 11:16
So I have to do my inn.get like this! (spaces replaced by dots for clarity)
inn.get({'BOTSID':'EDI_DC40...'},{'BOTSID':'E1EDK01.......................'},{'B
OTSID':'E1EDK02.......................','QUALF':'001','BELNR':None})
Original comment by mjg1964
on 16 May 2012 at 11:44
hi Mike,
I am not sure what you found out.
is this working for you?
Original comment by hjebb...@gmail.com
on 17 May 2012 at 3:01
Hi henk-jan,
It does not work "correctly" for idoc (and probably fixed) editypes, because
the tomessage from first translation contains all the padding spaces according
to the field lengths. So when that tomessage is used as inn for the next
translation (transform.py line 125), all the get's must specify the correct
number of padding spaces otherwise they return None. This is different to a
normal mapping which of course does not require this.
eg. in the 'out_as_inn' mapping:
inn.get({'BOTSID':'EDI_DC40'},{'BOTSID':'E1EDK01'} does not work
inn.get({'BOTSID':'EDI_DC40...'},,{'BOTSID':'E1EDK01.......................'}
works
Original comment by mjg1964
on 17 May 2012 at 10:31
I guess this is because the BOTSID field is longer than the actual identifier,
bots writes the original outgoing file, and during writing the fields lengts
are adjusted.
any suggestions on how to solve this?
can think of:
1. monkey-patch it: if fixed (idoc is a subclass of fixed I think) than run
over tree and get rid of spaces
2. write a copy of the tree; mmmmh, copying is quite slow.....
Original comment by hjebb...@gmail.com
on 17 May 2012 at 10:52
I did try a couple of things to fix it, but I don't know much about this part
of the code. Removing the spaces with a function in transform.py probably the
easiest way.
Original comment by mjg1964
on 17 May 2012 at 11:47
and it is not only BOTSID, the same issue applies to all fields used in inn.get
Original comment by mjg1964
on 17 May 2012 at 11:54
yes, I think so.
all fields are formatted as for output.
probably empty fields are added, to.
Original comment by hjebb...@gmail.com
on 18 May 2012 at 12:04
wouldn't be to hard:
def stripnode(node):
if node.record is not None:
node.record['BOTSID'] = node.record['BOTSID'].strip()
for child in node.children:
stripnode(child)
Original comment by hjebb...@gmail.com
on 18 May 2012 at 12:09
Thabks! I got it working but will do a little more testing.
transform.py at line 125
inn = tomessage
stripnode(inn.root)
At line 153 added this function (added another loop)
def stripnode(node):
if node.record is not None:
for field in node.record:
node.record[field] = node.record[field].strip()
for child in node.children:
stripnode(child)
Original comment by mjg1964
on 18 May 2012 at 3:05
Changed this so stripnode is only done for fixed formats.
inn = tomessage
if isinstance(inn,outmessage.fixed):
stripnode(inn.root)
This now works perfectly for me. The only thing missing, but not really
important; if I discard the intermediate format idoc (out.ta_info['statust'] =
DONE) then I can't go back and view it later in bots monitor.
Original comment by mjg1964
on 18 May 2012 at 4:58
Attachments:
ok, will add this.
....looking at this again, looks like stripnode() is a method in class Node.
Original comment by hjebb...@gmail.com
on 18 May 2012 at 11:28
Original comment by hjebb...@gmail.com
on 10 Sep 2013 at 12:45
Original issue reported on code.google.com by
hjebb...@gmail.com
on 10 May 2012 at 5:39