cancel
Showing results for 
Search instead for 
Did you mean: 

Mapping problem: IDOC -> XI -> File

Former Member
0 Kudos

Hi,

in my scenario (Z-IDOC - XI - File) I have problems with the mapping:

Z-IDOC :

ZFIBUCH1

_IDOC

___Begin

___EDI_DC40

___Z1L061 (0..999999999)

_____Z1L062 (0..999999999)

example

L061 18000 DE 0101 23236318 050605 EUR

__L062 18000 XXX XXX

__L062 18000 XX1 CCC3

__….

L061 87000 DE 0101 050605 EUR

__L062 87000 XXX XXX

__L062 87000 XX1 XAA4

__ …

the result should look like this :

L061 18000 DE 0101 23236318 050605 EUR

L062 18000 XXX XXX

L062 18000 XX1 CCC3

L061 87000 DE 0101 050605 EUR

L062 87000 XXX XXX

L062 87000 XX1 XAA4

I tried the following (target)-data types in the mapping but nothing did’nt work very well :

MT_ZIFUCH_FILE

__ row

_____L061

_______L062

or

MT_ZIFUCH_FILE

__ row

_____L061

_____L062

or

MT_ZIFUCH_FILE

_____L061

_____L062

Do I need here a BPM? Or should I use XSLT-Mapping??

Or knows somebody a easyer way?

Regards

Christoph

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Christoph,

I feel since your target structure is not a flat one the fixed lenght will give problem.

In case of hierarchical structure L62 is a child of L61 hence the lenght of L61 should include the lenghts of L62 fields also.

But the content conversion that you have given does not seem to take this into consideration.

If you have flat structure at the target the fixed lenght scenario would surely work fine.

<b>About the Row element :</b>

The Row element is a recordset name which has L61 & L62 as the recordset structures.Hence you only need to give the recordset structures during the content conversion.

I feel if you take a flat target things shoud work fine for your scenario.

When the file does not get created in your case you can check in the runtime workbench to see if the file adapter is in error.

Regards,

Sulakshana

Former Member
0 Kudos

Hi Sulakshana,

Thanks for your sugesstion.

I changed my message type back to this layout:

MT_ZIFUCH_FILE

__ row ( 0..unbounded)

_____L061 (0..1)

_____L062 ( 0..unbounded)

Now it works.

Regards

Christoph

Former Member
0 Kudos

Hi,

As per my understanding to have a flat file struture you would require a flat structure at the target side.One similar to the second structure mentioned by you.

DT_Target

|_Header

|______L61.....segment (child of header)

|______L62.....segment (child of header)

Using the mapping we convert the idoc structure to flat structure and then use content conversion like this :

Recordset structure : L61,L62

L61.fieldSeparator = ,(for you this value should be space)

L62.fieldSeparator = ,

I have not been able to convert the Target hierarchial structure to a flat file via content conversion.

when i tried I got the values as

L61,1800,...EUR,L62,8700,......

Hope this helps,

Regards,

Sulakshana

Former Member
0 Kudos

Hi Sulakshana,

with "fieldSeparator" the scenario will work.

I guess my problem is to work with fixed lengths.

If my recordset structure looks like that: L061,L062

The file-adapter will create a empty file.

If I add "row,L061,L062" in the recordset structure, the file-adapter create nothing???????

Regards

Christoph

Former Member
0 Kudos

Hi Christoph,

1.If you want to create a flat file per input idoc then you do not require to use BPM but if you want to collect multiple input files into a single file then you need to use BPM.

2.You do need to use XSLT.

In our project when we used Message mapping we used to get the file something like this.

A00......

L61......

L61....

L62......

L62......

All the similar segments used to get clubed.Hence we are currently using xslt mapping for such a scenario.It works fine.

Regards,

Sulakshana

Former Member
0 Kudos

Hi Sulakshana ,

but I need exactly this target format

L061

L062

L062

L062...

L061

L062

L062

The format ist similar with header/item strucutre

Regards

Christoph

Former Member
0 Kudos

Hello Sulakshna,

Can you please mail me the XSLT program for me to be able to use for my scenario.

It is exactly same as what Christopher shared but with a minor changes.

Thanks in advance and the same shall be highly apprecaited.

Srini.

E-mail: srinivasvk9211@yahoo.com