Introduction 

Digital Sales Workplace (DSW) is a solution that serves as a tool or a workplace for the salespersons
to manage their sales activities for example managing leads, preparing offers, and scheduling appointments with prospective customer. The aim is to turn more inquiries into confirmed orders. DSW is a holistic automotive retail solution designed to help automotive businesses easily embrace a digital strategy covering the entire sales processes. Its key benefits are to maximize sales team efficiency, boost customer satisfaction and workflow driven utilizing cutting-edge technology. 

Business Context 

In the scope of VSS, DSW serves as front-end tool of the vehicle sales process. It is mainly used by the salesperson to manage sales activities and interaction with prospective customers. With DSW, the salesperson can work on a single platform or user interface (UI) without the need to access multiple backend system or to contact different department to get information or status updates. This resolves the issues that the salesperson is commonly facing for example problem with measuring efficiency or an inconsistent customer facing approach. DSW provides the salesperson with a standardized and unified approach to manage sales activities and on the other hand reduces the administration effort of the salesperson in trying to close the deal with the customers. 

In DSW, the salesperson can choose to create a lead via a configurator or directly from a list of published vehicles (inventory). An initial offer can be prepared for the customer with typical automotive pricing structure which includes the functionality to add discount by percentage or absolute amount, add upselling additional items or upselling additional packages, capture financing or leasing information, capture down payment information and assign sales campaign. Pricing simulation function offers the ability to verify the latest pricing condition and ensures the price displayed in the offer is according to the price maintained in VSS. Saving the sales offer in DSW triggers the creation of sales quotation in VSS.   

Once the customer is satisfied with the offer, the salesperson can convert the sales offer to a sales order in DSW
where eventually, the creation of sales order will be triggered in VSS. The subsequent process
or sequence of event on the sales order for example vehicle assignment, goods movement, order split, and invoicing are then traditionally handled in VSS . Status update of the vehicle and the sales order occurs on real-time basis between VSS and DSW. 

Solution Overview 

...

Integration Component Overview  

...

Order Processing.

Solution Overview 

...

Component Overview  

...

The above diagram describes the component overview of the VSS-DSW integrationsolution. This component delivers different type of interfaces (inbound, outbound, or bi-directional) for different integration objects (for example business partners, vehicle, and sales order). 

DSW application can be integrated with other application or solution via the One Dealer Integration Layer
or commonly known as ODIL Neuro. ODIL deliver standardized API that offers inbound and outbound integration with DSW. It is a set of services implemented in MS Azure focusing on security, configuration, and data transfer. It supports not only exchanging business transaction for various means, but also the user access authentication, user/data mapping, and single sign-on options are embedded in the framework.
The API are constructed for different direction depending on the integration objects. 

Depending on the system architecture of the project implementation, ODIL can communicate with VSS
via the SAP Cloud integration. However, in any case, a direct connection to VSS is also possible. 

...

1. VSS has the REST Client as a component to generating generate 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 DSWthe incoming application. 

Integration point 

VSS-DSW Component Communication 

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

...

Framework configuration, setting, programs  

This section describes the settings required for the VSS-DSW integration. You are required to go through these settings before you execute the application. 

Configuration of HTTP services 

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.  

...