FP1 - Mapping Output key field to S_COR_ID_VALUE

[Former Member]

Again, using the Data Modeling tool and creating our mapping, I noticed when we map the key Output field to S_COR_ID_VALUE for the Query Operation, this field gets assigned as the key field, but it shows as a blank field on the output. In other words it appears as though using the tool it can only be used for key assignment but will not show the value in the SP List.

If this isnt a bug, that would mean that we would then need to create a duplicate field in the output structure. one to map as a key field and the other for display....does this seem correct?

In our example in the link.....field PRPS is not showing any value in the list as its getting assigned to S_COR_ID_VALUE.

http://s1112.photobucket.com/albums/k490/rory535/SAP/?action=view&current=mapping.jpg

Thanks.

[Former Member · Accepted solution]

Hi Rory,

we also experience this behaviour; effectively via the GW handling the original value of your key-field is extended with GW routing information. This is a problem in case your key-field represents a value that you yourself need in the application. 2 situations in which this is applicable:

1) The key-field represents a functional meaning, and is also to be displayed in the SharePoint UI. E.g Order Nr.

2) You need the key-field to filter into related information. Eg; from Customer (with Customer ID as key field) to the Purchase Orders for this customer (queried via Customer ID as input / filter param)

We see this behaviour as a current functional bug in the GW modeling tools (note: if you handcraft the GenIL, GSDO mappers, starting out with modelling your service interface in ESR, you can prevent this; but that is not an attractive appraoch compared to the GW modelling appraoch).

In our opinion, the GW modelling should create a separate C_CORR_ID_VALUE field and fill it with the SCL key value based on the key-field you designate in the GW model, plus the backend routing information; and output the original key value in its own field. We submitted this as functional bug / GW Request for Change via OSS message to SAP.

For now, we indeed apply the workaround to maintain ourselves the original key value by storing / copying it in a second additional field. The consequence is to have a custom RFC for each Query RFC for which we need to maintain the original key value.

Best regards, William.

[Former Member · Accepted solution]

Thanks William, was what I was thinking.