Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. VSS has the REST Client as a component to generating the connection to DSW.  

  2. Distribution controller defines when a particular integration object needs to be processed (immediate, time interval, etc). 

  3. Data access controller performs the relevant activities on the integration objects depending on the request coming from the interface for example read, write, update, etc. 

  4. REST Server responds to the initiated call from DSW.  

Integration point 

The following describes the integration point in scope VSS-DSW integration:

...

Framework configuration, setting, programs  

...

The connection between VSS and external system are basic setting required for integration. Integration requires two directions of communication. First are the parameters which ensure incoming request are going to be served. This part is based on the HTTP server and the activated services with TSL security layer. 

Access to the systems is based on the RFC-User which serve all access needed. This technical user should have authorization for the functional operation specific authorisation to access integration services itself. The user does not need to have any dialog access.  

The RFC-User name is default set to RFCUSER and delivered in predefined services. However, name is no way restricted and can be provided according to customer naming convention. The user, password, language, and client settings must be maintained during implementation on the transaction SICF in the path /default_host/dbe/vss/odl/api/ in the tab LOGON DATA.  

 Additional authorisation for access is based on the register of external technical users. All provided services require to receive in the header data authorization token. The token is generated for 24 hours and can be received from special service ../vss/odl/api/dms/token where the registered users can get the token by means of parameters like username and password (transaction /DBE/ODL_TECH_USER enable maintenance of the technical users). 

Introducing the standard implementation require only a few parameters in the area Customer specific settings which are in principle cover the IDoc as means of trace and asynchronous processing. 

Configuration of HTTP client 

In order to perform operation on the services which enable access to the OneDealer server manual customizing is required in Transaction SM59

It is needed here to setup the following incoming connections (type G “HTTP Connection to External Server”) with parameter Security options -> SSL Certificate with value default SSL Client: 

1. BDE_ODL_AZURE_TOKEN 

  • HOST: login.microsoftonline.com 

  • Path prefix: <microsoft_user_prefix> /oauth2/v2.0/token (<Microsoft_user_prefix> is common setup of the OneDealer) 

 2. BDE_ODL_AZURE_SESSION 

  • HOST: <server_host>.azurewebsites.net (<server_host> host of OneDealer access point) 

  • Path prefix: /api/session/create 

  3. BDE_ODL_DATA_ACCESS 

  • HOST: <server_host>.azurewebsites.net (<server_host> host of OneDealer access point) 

  • Path prefix: /api/integrations/odil/dms 

Additional application parameters for authorisation and routing are to be maintained in the transaction /DBE/ODL_ROUTING – ODIL Routing (default required key is ODL). The parameters are based on the setup of the OneDealer environment (besides the destinations which need to be set up as follow: 

...

The following is the area menu for the master data and transactions to monitor the integration processes with DSW. The report /DBE/IFM enable to monitor created and processed IDocs for in case of asynchronous processing and the trace IDocs in case of troubleshooting. 

The trace of the processing can be activated and deactivated with the transaction /DBE/ARS_TRACE_CHANGE.  

IDoc’s settings 

In order to trace the communication and process asynchronous calls, appropriate message types were created. 

General settings 

Trace IDocs types which are mentioned in the point 5.3.2 are delivered as the integration suite.  

However, to enable the processing of all kinds of IDocs, logical system partner (transaction WE20) must be manually maintained on every client and server which is planned to be used for integration. The settings below illustrate proposed customizing with the logical partner DBEODLREST

...

The steps for the customization: 

...

Outbound Application: Assignment of Receiver to the destination BDE_ODL_DATA_ACCESS

...

Inbound Application: Determination of Sender 

...

IDocs for asynchronous inbound processing 

In case of processing of asynchronous inbound calls, the integration solution customizing settings for inbound process code (transaction WE42) are delivered (in the BC-Sets). The settings are shown in the screenshots below: 

...

This requires manual maintenance afterwards in the transaction for system partner maintenance WE20 by adding assignment of the processing codes to message types: 

...

with the following way: 

...

Organizational settings 

Proper assignment of the organizational units between the OneDealer and the VSS requires maintenance of appropriate mapping. For this goal, a customizing table /DBE/VS_S_ORG must be filled.  

Mapping of organizational units has been configured in VSS in the following path: Customizing for Logistics Execution, choose “Vehicle Sales and Service (VSS) à Vehicle Sales à Integration with VSS Order à Digital Sales Workplace (DSW) à Define Organizational Structure Mapping” 

...