SAP Ariba Vendor Sourcing

Process description

This app template was built for the SAP Ariba Sourcing process. This is an end-to-end process which usually starts with the creation of a sourcing project. Then, the standard project events are created and executed. These events comprise the basic steps needed for a sourcing project, such as:

Finally a contract is generated and the sourcing project is completed.

Please note that when creating a sourcing project in SAP Ariba, the user must select one Template for the project. These templates include predefined Phases and its Tasks, plus the Documents and Events that will be included in the project.

The following list shows the usual Activities that will be performed in an SAP Ariba sourcing project. All of them happen after the first activity which is Create sourcing project. These activities are also divided into several Phases as shown below:

Phase: Project Planning

  1. Assess category and opportunity
  2. Assign project team
  3. Kick-off project

Phase: Strategy Development

  1. Determine optimal sourcing strategy
  2. Conduct risk assessment
  3. Identify and publish estimated savings
  4. Finalize sourcing strategy
  5. Approve final sourcing strategy

Phase: Supplier Identification

  1. Determine suppliers to include

Phase: Execution and Award

  1. Draft contract
  2. Create RFI
  3. Publish and monitor RFI
  4. Evaluate RFI responses
  5. Create RFP
  6. Review RFP
  7. Publish and monitor RFP
  8. Evaluate RFP responses
  9. Create RFP scenarios and award suppliers
  10. Create auction
  11. Publish and monitor auction
  12. Evaluate auction results
  13. Negotiate and execute contract

Phase: Closeout

  1. Document savings for tracking and reporting
  2. Document lessons learned
  3. Update project state (to completed)

The graphic below briefly shows a standard template sourcing process in SAP Ariba:

Available tags & due dates

The following tags are available by default.

Tag Description
Sourcing projects with baseline spend changes Cases where the Baseline spend was either increased or decreased.
Sourcing projects with project reason changes Cases which include an activity where their Description indicates the sourcing project reason has changed.
Sourcing projects reopened Cases which include an activity where their Description indicates the sourcing project reason has been reopened.
Sourcing projects with more than one RFP Cases which contain more than one 'RFP' event.
Sourcing projects with more than one RFI Cases which contain more than one 'RFI' event.
Sourcing projects with more than one RFQ Cases which contain more than one RFQ event.
Sourcing projects without contract associated Cases which do not contain contracts.

The following due dates are available by default.

Due date Description
Sourcing project start due date Compares the date when the sourcing project should start (planned start date) with the date it actually started.
Sourcing project ended after planned due date This due date compares the date when the sourcing project should finish (planned end date) with the date it actually ended.


This app template uses SAP Ariba as source system. Extraction for the source system is done using a custom extractor, which extracts data from SAP Ariba in CSV format using Ariba APIs. Both full data sets and delta extraction are supported. The generated files can be loaded using CData Sync. Make sure you have a valid license for CData Sync and have installed CData Sync.

System configuration

This app template is built for SAP Ariba v.2301 or newer. SAP Ariba is a Software as a Service (SaaS) and it gets constant updates that are deployed quarterly, naming its versions with the last two digits of the year directly followed by the month of the release (i.e. January 2023 release: v.2301).

SAP Ariba Strategic Sourcing module is mandatory.

As mentioned before, this app template was built and tested to work with SAP Ariba v.2301. However, it was designed to work with tables that are the backbone of the sourcing process so it is probable that it will remain compatible with the next multiple iterations of the system. It is recommended to review the documentation of each new release to be aware of the changes that could happen in the tables.

Extraction tool configuration

An extractor is developed in Python that allows to extract data from SAP Ariba in CSV format using Ariba APIs. Note that due to limitations of the Ariba APIs regarding the number of requests and the number of records extracted per request, this extraction might take longer than expected.

For the extractor and its documentation, download the Follow the instructions in the documentation to install and configure the extractor. Execute the extractor for all sourcing models.

Setting up the source connection in CData Sync

Setting up the destination connection in CData Sync

To set up the destination connection, follow the steps as defined in Create a destination connection (Automation Cloud). Note: If you are using Automation Suite, make sure to select AUTOMATION SUITE as the DELIVERY option and select the correct version of Automation Suite you are using.

Creating the extraction job in CData Sync

To create the Job in CData make sure to follow the steps below.

Advanced job settings

In the Advanced tab in the Job Settings panel, define the following settings:

Setting up the data ingestion call

After the data has been successfully loaded, the Process Mining platform needs to start the data ingestion process. This is done by calling the End of Upload API. In order to set this up, follow the steps below:

Step Action
1 Go to the Events tab in the Job Settings panel of the job you are creating
2 Edit the Post-Job Event section to add the code displayed below after <!-- Code goes here -- >. Do not modify the api:info details that are shown by default.
3 Fill out the End of Upload API with the value provided.
4 In case you need a debugging log for this call, uncomment the two lines provided in the code below and provide a location for the log file.
5 Click on Save Changes.
<api:set attr="http.url" value="END_OF_UPLOAD_API"/> <!-- <api:set attr="http.verbosity" value="5"/> --> <!-- <api:set attr="http.logfile" value="D:/mydir/cdata_log.txt"/> --> <api:call op="httpPost" in="http"/>

Table Replication

Once the job is correctly setup, click on Add Custom Query under the Tasks tab and paste the following queries (each query needs to maintain the semicolon at the end). Make sure you save all changes.

REPLICATE [Sourcing_project_details] ([internalId] VARCHAR(255), [beginDate] VARCHAR(255), [endDate] VARCHAR(255), [plannedEndDate] VARCHAR(255), [plannedStartDate] VARCHAR(255), [templateProjectTitle] VARCHAR(255), PRIMARY KEY ([internalId]), [lastModified] DATETIME) SELECT * FROM [Sourcing_project_details]; REPLICATE [Sourcing_project_events] ([internalId] VARCHAR(255), [createDate] VARCHAR(255), [description] VARCHAR(255), [docType] VARCHAR(255), [iconType] VARCHAR(255), [owner] VARCHAR(255), [projectId] VARCHAR(255), [status] VARCHAR(255), [title] VARCHAR(255), [type] VARCHAR(255), PRIMARY KEY ([internalId]), [lastModified] DATETIME) SELECT * FROM [Sourcing_project_events]; REPLICATE [Sourcing_projects_history] ([InternalId] VARCHAR(255), [BaselineSpendAmount] VARCHAR(255), [BaselineSpendCurrency] VARCHAR(255), [ClientDescription] VARCHAR(255), [CommodityName] VARCHAR(255), [OwnerName] VARCHAR(255), [ParentDocumentInternalId] VARCHAR(255), [RegionDescription] VARCHAR(255), [Status] VARCHAR(255), [TimeCreated] VARCHAR(255), [Title] VARCHAR(255), PRIMARY KEY ([InternalId]), [lastModified] DATETIME) SELECT * FROM [Sourcing_projects_history]; REPLICATE [Currency_conversion_rates] SELECT * FROM [Currency_conversion_rates];

Configuring incremental extraction

The SAP Ariba extractor supports incremental extraction. With incremental extraction, only the data that has changed since the last extraction is extracted. This will reduce the amount of data that needs to be extracted and thus the extraction time.

The steps to configure incremental extraction are described below. You are advised to configure the incremental extraction as an additional extraction configuration, to make sure that you can also perform a full extraction as needed. See also section limitations.

Please note that when using Automation Cloud, you will need an additional staging database to store data and merge incremental data with the existing data. See Incremental extraction prerequisites in Automation Cloud for more information. This also implies that the CData Sync job for full extractions will need to be configured to use the staging database as destination.

Incremental extraction in the extractor

To configure incremental extraction in the extractor, you can use the --delta argument. This requires that a full extraction has been done before. You are also advised to use a different output location for incremental extracts. Please see the README file that is included with the extractor for more details on how to specify those arguments.

Incremental extraction in CData Sync

To configure incremental extraction in CData Sync, you will need to configure an additional job to merge the incremental extracted data into the existing dataset. You can use the same steps described above to setup a new job in CData Sync, but with the following changes:

Load data into the platform

When using Automation Cloud with a staging database, you will need an additional CData Sync job to load the data from the staging database into the Process Mining platform. Make sure the source connection is the staging database. To configure the destination connection, see Create a destination connection (Automation Cloud).

Input data

The following tables include the list of fields per input table, their description and data type to be used.

Input types

The following table provides an overview of the different field types and their default format settings.

Field type Description
boolean true, false, 1, 0
date yyyy-mm-dd
datetime yyyy-mm-dd hh:mm:ss
double Decimal separator: . (dot); thousand separator: none
integer Thousand separator: none
text N/A

Input tables & fields

The following tables are extracted from the source system:


Contains sourcing projects transactional information.

Field Type Description
InternalId text Unique identifier of the sourcing project
BaselineSpendAmount double Indicates the amount had to spend in the sourcing project
BaselineSpendCurrency text Indicates the currency of the baseline spend amount in the sourcing project
ClientDescription text Used to specify the department in the organization involved in the project
CommodityName text The commodity of the sourcing project, an organization might refer to commodities as categories (e.g. suppliers categorization)
OwnerName text The user who owns the sourcing project
ParentDocumentInternalId text Indicates the unique identifier of the predecessor document related to the sourcing project. (e.g. another sourcing project ID; a sourcing request ID)
RegionDescription text The geographic region belonging to the sourcing project
Status text Sourcing project state in the process
TimeCreated timestamp Timestamp on which the sourcing project was created
Title text User-friendly name of the sourcing project

Filtering: Sourcing_projects is the only table that has a date-time filter. This table will then provide the Sourcing_project_IDs that will be used as a filter for all the other transactional tables. Master data tables, as usual, are not being filtered.


Stores sourcing projects attributes information.

Field Type Description
internalId text Unique identifier of the sourcing project
beginDate timestamp Date when the project actually started
endDate timestamp Date when the project actually ended
plannedEndDate timestamp The date planned to end the project
plannedStartDate timestamp The date planned to start the sourcing project
templateProjectTitle text Predefined model that the sourcing project uses as a base to be created


Contains information of all sourcing project related documents such as RFPs, RFIs, RFQs and Contract workspaces.

Field Type Description
internalId text Unique identifier of the project documents, events and contracts
createDate timestamp Date on which the project document was created
description text Description of the project event
docType text General type name for the project documents (e.g. Event)
iconType text Actual type of project document (e.g. RFP)
owner text User who created the project document
projectId text Unique identifier of the sourcing project associated to the event
status text State of the project document in the process
title text User-friendly name of the project document
type text General categorization code of the project documents (e.g. RFx)


Stores historical information of the sourcing projects.

Field Type Description
id text Unique identifier of the activity
description text System description of the activity executed
details text Indicates the status of the activity (e.g. Completed, Canceled)
ProjectId text Sourcing project unique identifier related to the historical record
realUserName text Name of the user who performed the activity
timestamp timestamp Date on which the activity was executed
title text User-friendly name of the activity
type text System categorization of the activity (e.g. Task, Team, etc.)


Stores all currency conversion rates available in the system.

Field Type Description
FromCurrency text Currency code from which the conversion is done
TimeCreated timestamp Timestamp on which the record was created
ToCurrency text Currency code to which the conversion needs to be done
Rate double Exchange rate of the currency conversion

Configuring transformations

Seed files


This seed file is used to add automation-related properties to each activity, used for the automation potential dashboard. For more information, see Simulating Automation Potential.

Field Type Description
Activity Text Display name for the activity
Event_cost Double Cost associated with the activity
Event_processing_time Integer Processing time associated with the activity (in milliseconds)


This seed file is used to define properties for the due dates. For more information, see Due Dates.

Field Type Description
Due_date Text The name of the due date
Due_date_type Text The Due date type
Fixed_costs Boolean An indication whether costs are fixed or time based
Cost Double Fixed costs: The amount of costs. Variable costs: The amount of costs per Time and Time_type
Time Integer A number indicating the amount of time in case of time-based costs
Time_type Text Type of time period for cost calculations. This can be any of the following values: day, hour, minute, second or millisecond


This seed file has two purposes. The first one is to populate the activity attributes that cannot be obtained from any Ariba tables. The second purpose is to set a preferred activity name when the native name is not wanted.

Field Type Description
Native_activity_name text Primary key of the table. Name automatically given to the activity by the model. This field is the concatenation of the activity title, plus its status.
Activity_name text Name manually given by the analyst to the activity.
Activity_order integer Order on which the activity should happen in the process.
Activity_type text Categorization of the activity (e.g. Classification by Phase)
Automated_activity boolean Flag which indicates if the activity gets executed automatically or not. Valid values are 1, 0 or blank; the last 2 values mean FALSE.

Note on Activities variability: The app template comes with the Activity_configuration_raw seed file pre-populated for a standard project template. In SAP Ariba, activities change depending on the template used for the sourcing projects creation. These templates can be customized as much as the business wants; therefore, it will always require adjustments.

This file has an auxiliary model Activity_configuration_auxiliary that was created to help analyst setup the app template. This auxiliary model was created based on Events_base and the seed file Activity_configuration. Then, it groups all events by their Native_activity_name and lists all their attributes.

This auxiliary model will be useful for the following:


Field Type Description
Activity_status text Status for which an activity goes through in the process.

After an updated csv file is loaded into the Seeds folder, the analyst needs to run the following dbt codes to process the latest changes: dbt seed first and then dbt run. This should be done whenever a change is done to any of the seed files.

Dbt variables

Variable Type Description
display_currency text All monetary values will be converted to the selected display_currency.
use_document boolean When TRUE, all document-related activities will be generated in the app template. By default it is set to FALSE to reduce the amount of activities that are being generated. Too many activities could cloud the view of the Process mining analyst. However, it may be useful for particular clients.
use_phase boolean This variable is similar to the previous one. It gives the possibility to bring activities related to Phases. This variable may help deepening the analysis, and also could help giving certain sense of order to the process. It is set as FALSE by default to avoid the creation of too many activities.

Design specifications


Object Input Data
Sourcing_projects Currency_conversion_rates, Sourcing_project_events, Sourcing_projects, Sourcing_project_details.


The app template follows 2 approaches for creating activities:

Each approach follows a different logic in the app template.

Approach 1: activities that can be created from transactional tables.

This activity has a specific model where it was created and the name of the model derived from the activity name.


Object Native_activity_name Description
Sourcing Projects Create sourcing project Event of creation of the sourcing project. The date comes from the Sourcing_projects transactional table.

Approach 2: activities that can be created from historical table.

These activities have a specific model where they all were created. By default all of them are based on Ariba Tasks. And it can also add activities based in Phases and Documents.

Relevant considerations:

  1. The activities present in the app template are based on the standard predefined template in SAP Ariba for the sourcing process. However, it is not possible to known in advance which activities will be used across implementations.

  2. The most standard activities were set up in advance in the Activity_configuration_raw seed file mentioned in Seed files. For new activities, the analyst should add them following the steps described in that section.

  3. The Native_activity_name is automatically generated by the model concatenating Title (Task name) with Details (status: created, completed, approved, etc.). If this Native_activity_name does have an Activity_name set in the Seeds file, it will use the latter instead.

  4. As a guideline for naming Native_activity_names that have a status 'Completed' we suggest to name them avoiding their status. Therefore, whenever an activity is actually completed, its name refers to the Title only. This is done to increase clarity in the displaying name of the activities.

    Example 1:    
        Native_activity_name: 'Approval for Final Sourcing Strategy Completed'
        Activity_name: 'Approve final sourcing strategy'

    On the other hand, all other statuses remain in the activity name.

    Example 2:
        Native_activity_name: 'Approval for Final Sourcing Strategy Denied'
        Activity_name: 'Deny final sourcing strategy approval'
  5. The lack of setups for a particular activity will not break the model.


Below, there are examples of activities derived from the standard template, the object, the activity name assigned to them and their descriptions.

Object Native_activity_name Activity_name Description
Sourcing Projects Approval for Final Sourcing Strategy Approved Approve final sourcing strategy Final approval done to the sourcing project strategy
Sourcing Projects Evaluate RFI Responses Reviewed Review evaluation of RFI responses Review done to the evaluation of the RFI responses

Design details

Sourcing project versions:

In SAP Ariba, whenever some header attributes are changed to a Sourcing Project, the system automatically generates a new version of it, with the same Sourcing_project_ID. The system also keeps a copy of the older version by creating a new Sourcing_project_ID, which is not available in the front end of Ariba (it is only stored in the back end). That new Sourcing_project_ID will not have any historical information; it will only keep the original attributes of the project. However, SAP Ariba APIs can still pull these projects. Therefore, the APIs continue extracting the transactional record for the older versions of the same Sourcing project (this is unwanted). To avoid this issue of duplicating Sourcing projects due to versioning, an inner join was done in Sourcing_projects model. This inner join will bring only Sourcing projects with historical information associated.

Known limitations

Therefor you are advised to perform a full extraction from time to time to make sure that the data is up to date.