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. 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 items or upselling 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 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
The above diagram describes the component overview of the VSS-DSW integration. 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.
The following explains on a high level, the component within VSS:
VSS has the REST Client as a component to generating the connection to DSW.
Distribution controller defines when a particular integration object needs to be processed (immediate, time interval, etc).
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.
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
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
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”