SAP BC-dev: decodeString-service problem for adv. developers

Question: In SAP Business Connector I do the following:

With the build-in services:
1) (ftp)get
2) bytesToString
3) decodeString
4) transformFlatToHierarchy

...I want to build an Idoc-hierarchy (records) from an Idoc-INVOIC01-flatfile.
I have 2 versions of INVOIC01-flat-file and I can only process 1 of them.
The first begins with: EDI_DC and E2EDK01 is going OK,
the second one starting with: EDI_DC40 and E1EDK01 transforms only the control-record and no segment-records, and has a string DOCTYP with a null value.
It seems like the decodeString-service cannot handle those 2 different versions and needs the DOCTYP-value. We are using R/3 46C and SAP BC 47.
Does anybody know if there is a workaround or how to handle this problem ?

Thanx in advance, Martin.

Answer:
Hi Martin,

We have the same kind of problem here, so let me know if it is solved.
I will too.

reg., P.

Answer:
Hi Martin,

I think you should split the flat file at every new EDI_DC or EDI_DC40 record in the Business Connector, and create two separate tables, one for each Idoc-type. Decode them separately as well.

It is not possible with that service to read in one Idoc-string that contains several Idoctypes.

Regards
Journey

Answer:
Hello Journey,

thank you for replying. I already process 2 seperate flat-files in 2 independant processes. It seems that the business connector can handle only 1 type (or version ?) of an INVOICE01-Idoc-flatfile.
Are these 2 different versions ?

Maybe it depends on our R/3-version or settings as the decodeString-service requires a SAP-server for inputparameter.


Thank you,
Martin.

Answer:
Hi Martin,

Yes these are 2 different versions.
Have you loaded both versions as .dtd to create an xml-schema in the BC?

Regards
Journey

Answer:
I forgot:

E2EDK01 indicates that it probably is an earlier version and you might not be able to get this dtd from your SAP system.

Check transaction WE31 for segment E1EDK01 and check which version of this segment looks like your E2EDK01 segment.
You might be able to get the right dtd from http://ifr.sap.com

Regards,
Journey

Answer:
I am sorry, I could have fitted this into 1 post

If you are indeed dealing with an earlier version of INVOIC01, you should also create this version in SAP because the Business Connector will check your SAP system for any Idoc-definition.
Probably you need to change the IDoc-name in your flatfile accordingly.

I think I got it all now!

Good luck
Journey

Answer:
Hi Journey,

I'm not involving any dtd's at all. Actually I wouldn't know where to insert them in the process. One of the idoc's is going well without dtd.

But I'm going to try to create my own Idoc according the earlier version with a different name, that might work !

thanks again, MArtin.

Answer:
Hi Martin,

If you have no dtd's that would mean that no additional mapping steps are required to fill the IDoc, and only a direct translation file->Idoc is necessary in your case.

Please bear in mind that it might be necessary to include them if you need particular mapping steps to map the *old INVOIC01* to the INVOIC01-layout of your SAP-system. In this case the BC needs to know the exact layout of the IDoc and its segments.


Good luck!

Regards
Journey

Answer:
Good morning Journey,

thanks for your time till now, but I do not know where to set the DTD-type within the built-in services:
-get
-bytesToString
-decodeString.

I assumed that the BC would ask the R/3-system about his INVOIC01-version. That would explain it that the BC only can handle 1 INVOIC01-version. I get your idea about different IDOC's - different DTD's, I just cannot find the place where to involve them or point to them.
Can you tell me ?

For now I'm going to try to create my own IDOC in R/3.

reganrds, Martin.

Answer:
Hi Martin,

Like I said, if your interface is just a conversion of a flat file to an IDoc you probably would not need any DTD in your Developer, and your interface would probably be OK as soon as your IDoc type is known in the SAP system.

However if you want to include additional mapping steps they come in view. I assume the result of one of your interface steps probably is a recordlist boundNode. If, for example, you'd want to change the value of the field matnr, it means the structure of the IDoc needs to be known to the Developer. You can create it in the Developer by loading a DTD. You can download a DTD from SAP (transaction WE60) or from http://ifr.sap.com. You should create a new Record in one of your packages/folders with reference to your downloaded dtd.
In your interfaces you now can create records or recordLists with reference to this Record.

Hope this helps.

Good luck
Journey

Answer:
Hi Journey,

I do understand your answer, I just can not find how to refer to the DTD in the BC.
I mean: which services do I call to transfer a local flat IDOC-file to a hierarchical structure according a DTD that I already have downloaded ?

This would be my final question,
thanx, Martin.

Answer:
..... I mean I create a record with DTD-reference, but how to invke this record after creating a bytes-object with ftp-get ?
there is no service like bytesToRecord !?!

Martin.

Answer:
Hi Martin,

I am sorry, I probably misunderstood you

The steps you were using in the first place are correct.

All you have to do after the Transform...-service is map the boundNode to a record in your flow that you created with reference to your dtd-record (in your package/folder-structure).

The first few steps are Idoc-type independent.

Regards
Journey

Answer:
Hello Journey,

this is where my problem first came up:
These steps are maybe idoc-type independant, but not idoc-version independant !!
Processing the way you describe goes OK for one idoc-version but fails for another idoc-version of INVOIC01.

Maybe I wasn't clear enough in the beginning....

reg., Martin.
Copyright ?2007 - 2008 www.jt77.com