BAPI issue on WTX 8.1

[snehareddy]

We are upgrading from Mercator 6.7 to WTX 8.1.
We have two maps BAPI and BAPI return map.
BAPI map will make a BAPI call and BAPI return map will capture the output of BAPI and will update the error.
A typetree imported from type tree wizard is used by both the maps. The BAPI map uses the typetree in Outputcard and BAPI return map uses typetree in Input card.

When we have used SAP version 7.2 typetree in BAPI it has given FAIL FUNCTION ABORT message at BAPI map.

When we tried importing a typetree in SAP version 7.5 in both BAPI maps the BAPI map is working but the error code in BAPI return map is 8.
When we use SAP ver7.5 type tree in BAPI map and SAP ver 7.2 type tree in BAPI return map the error code in BAPI return map is 21

The return map typetree is expecting initiator of form -F~XXXXX~ZM00_BAPI_SVRS, but the output of the BAPI map is having
-F/XXXXX/ZM00_BAPI_SVRS, … as input for return map …

 

[PWarwick]

Hi,

The errors you are getting indicate that the data is in an unexpected format (you are no doubt aware of this already). If you enable tracing for the maps then you will obtain further information (perhaps you have done this as well?!).

From your other post (and please see my reply) it would appear that you can call the BAPI using the type tree as produced by the BAPI importer but the format of the response is unexpected.

I must confess that I am a little confused by your comments because you are implying that you are using two type trees (i.e. one for input and one for output). When I call a BAPI, I use a single type tree (produced by the BAPI importer) that provides the format for both input and output.

If you are using two type trees, then perhaps you might try modifying the response type tree (using the type designer) to amend the initiator (as implied by your other post). If you are using a single type tree then perhaps you might try modifying (again using the type designer) the "response portion" of that type tree. I wouldn't normally recommend modifying the type tree produced by the BAPI Importer, but if you are very sure (i.e. by using the RFC adapter trace) of what data is being sent back by the BAPI then it would make sense to perform the manual modifications to the type tree.

By all means, let me know if you need more help.

cheers.

 

[snehareddy]

Hello ,

Thanks for the response.
Seems like the earlier post was not clear , the issue we are facing is as follows:

We have a map which is used for a calling a BAPI present in R/3 from Middleware , the type tree used by the map to call BAPI and process the return code from the BAPI is same and is imported using IMPORT feature of Typedesigner in WTX 8.1.0.3.

We are observing the following issue:

When the Type Tree is imported using Type designer in WTX 8.1.0.3 , the structure of the Typetree is not XML based structure as in case of Type Tree imported in Datastage Tx version 6.7.

Due to this, map which process the return from the BAPI failing . The options used while importing the BAPI type tree ( both in 8.x and 6.x) are as follows :

1.Version of SAP that created this data is : 4.6x.

2.SAP operating system is : UNIX.

3.National language : Western

4. Data character set : Native.

5. Format : BAPI

Even after using the same options for importing in 6.x and 8.x the Type Trees generated in both the cases is different. Due to this, the map is failing to process the return from BAPI when we use the Type Tree imported in 8.x , the return code from the map is 8.

Please inform what could be reasons for same , do we need to change any options when the TypeTree is imported in WTX 8.x.

Thanks in advance.

Regards,
Sneha

 

[PWarwick]

Hi Sneha,

I have noticed that type trees generated by different versions of the product (even going from 8.1.0.2 to 8.1.0.3 for example in the case of SOAP based messages) are different. In general, don't get too worried about what type trees are being produced by different versions - they will be different (no matter what the vendor tries to tell you). Your task is to work with the current version that you are using.

As a warning for the future, we have rolled back to 8.1.0.2 (after unhappy experiences with 8.2 - the SAP BAPI support is flaky and 8.1.0.3 changed the type tree structure for WSDLs to such an extent that significant map rework would need to occur).

Yes, you are correct that the BAPI type tree produced by 8.1.0.x is not an XML based structure - but unless you are expecting your version 6.7 maps to work with this tree (and I believe that you shouldn't believe this to be the case i.e. you are likely to have to redevelop some of the maps) then you shouldn't really have to care about what 6.7 produced in the past.

If you are, however, migrating your 6.7 maps to 8.1.0.x then my advice is to modify your existing 6.7 maps to work with the new BAPI type tree. This is part of the price you pay for upgrading (which is hopefully offset by the advantages!?).

For the record, with 8.1.0.2 we have been happily calling BAPIs using the type trees that were created using the BAPI Importer within the 8.1.0.2 type designer. There are no options, other than the ones you specified, that I am aware of when creating the BAPI type tree.

If you continue to have problems once you migrate your code to make use of the new BAPI type tree then you will need to analyse the adapter trace to see where to turn to next (hopefully all will be OK).

Hope this helps.

cheers,
Paul

 

[snehareddy]

As suggested we are using the same typetree imported in 8.x to format the Bapicall and process the return.
However the observation is that BAPICALL is successful but the map which uses same typetree is not able to parse the data.The return from BAPI is having slashes
(-F/XXXXX/ZM00_BAPI_SVRS) where type tree is expecting tilt (-F~XXXXX~ZM00_BAPI_SVRS).
Suggest some character conversion functions to accommodate this in map?

 

[PWarwick]

Hi again Sneha,

I'd then use the type designer to modify the response portion of the type tree from '~' to '/' so that it reflects the actual data being returned.

cheers.