In the initial Duet Enterprise implementation + configuration in Development/Test/Acceptance/Production landscape, SAP BASIS applied the customer directive to use environment-specific names for system aliasses. When we transported the first Gateway models from development environment to test, we however encountered that this is not a workable configuration. SAP Gateway does allow you to associate generated GSDO types with another runtime system alias (via transaction SPRO / Gateway / Generic Channel / Assign GSDO Group). However, afterwards it is then no longer possible to regenerate the Gateway models!
In the SAP implementation methodology of customer, it is prescribed that Gateway model specification is done only within development system, and via SAP transport mechanisme the generated Gateway models are propagated upto the production landscape. However, this principle does not apply for the transition between Build and Run landscapes. Within the Run environment, it must be possible to alter and regenerate a CTS+ imported Gateway DataModel. Afterwards changing the associated runtime system aliasses of GSDO types is thus not viable.
Practical Duet Enterprise recommendation is therefore to apply generic/environment-indepedent names for the system aliasses that are referred in Gateway DataModels. Within the specific landscapes, the system aliasses are then configured with environment specific RFC connections. Additional benefit of this approach is that implementation of Gateway Models throughout the SAP landscape is freed from the manual step to modify for all of the transported GSDO types the system alias.
Update (Oct 4th, 2012):
We experienced another issue with GSDO types of which the system alias is altered: The metadata of the Gateway / Duet Enterprise webservice generated via the BDC Publisher has become invalid. This effect is not direct visible: the service still functions, both through transaction SProxy as for invocation from SharePoint through Duet Enterprise. We noticed the effect when we tried to re-import the generated BDC Model into SharePoint BCS, and BCS validates the model by trying to access the WSDL metadata of the Duet Enterprise webservice. This returned an error from SAP Gateway system: No data for binding key "53414....". We next received the same error when accessing in browser the BDC Model property-value WcfMexDocumentUrl. The effect manifestated itself for all Business Scenarios that access a GSDO type of which the system alias had been altered. Problem is fixed by regenerating each of the involved Business Scenarios in the BDC Publisher. As result internal in Gateway system the WSDL metadata administration of the webservice is newly derived and administrated; the exported BDC Models then refer to a valid WcfMexDocumentUrl address and import in BCS succeeds.
We experienced another issue with GSDO types of which the system alias is altered: The metadata of the Gateway / Duet Enterprise webservice generated via the BDC Publisher has become invalid. This effect is not direct visible: the service still functions, both through transaction SProxy as for invocation from SharePoint through Duet Enterprise. We noticed the effect when we tried to re-import the generated BDC Model into SharePoint BCS, and BCS validates the model by trying to access the WSDL metadata of the Duet Enterprise webservice. This returned an error from SAP Gateway system: No data for binding key "53414....". We next received the same error when accessing in browser the BDC Model property-value WcfMexDocumentUrl. The effect manifestated itself for all Business Scenarios that access a GSDO type of which the system alias had been altered. Problem is fixed by regenerating each of the involved Business Scenarios in the BDC Publisher. As result internal in Gateway system the WSDL metadata administration of the webservice is newly derived and administrated; the exported BDC Models then refer to a valid WcfMexDocumentUrl address and import in BCS succeeds.
