SAP Ariba Extractor is a solution designed to download from the SAP Ariba APIs. It is developed in Python 3.10 and, by default, it extracts the data in CSV format. The output files are intended to be used to feed the SAP Ariba P2P Connector.
The SAP Ariba Extractor has the functionality to extract transactional information and master data. This is done by using four different SAP Ariba APIs, which contain Endpoints for specific purposes.
P2P APIs present in the SAP Ariba Extractor:
Sourcing APIs present in the SAP Ariba Extractor:
For more information about the APIs mentioned please refer to API_references.
The following chart contains the list of P2P tables that are extracted by default, their information type, the API used to retrieve them and also, the specific endpoint called:
P2P Document | Table | Info Type | API | Endpoint |
---|---|---|---|---|
Purchase requisition | Requisition_Header | Transactional | Operational Reporting for Procurement API | This table could be extracted synchronously or asynchronously. If extracted synchronously uses GET /viewTemplates/{viewTemplateName}. If extracted asynchronously uses POST /jobs. Inside the body of the call, the template and filters are passed. This call retrieves a Job ID, and then, the job status is asked using the GET /jobs/{jobId}. When the status is 'completed', the information is extracted using the GET /jobs/{jobId}/files/{fileId}. For this table the filters passed are updatedDateFrom and updatedDateTo. The Template Name is: Requisition_SAP_updatedRange_v2. |
Purchase requisition | Requisition_LineItems | Transactional | Operational Reporting for Procurement API | Same logic above. Template Name: Requisition_SAP_updatedRange_v2 |
Purchase requisition | Requisition_ApprovalRecords | Transactional | Operational Reporting for Procurement API | Same logic above. Template Name: Requisition_SAP_updatedRange_v2 |
Purchase requisition | Requisition_History | Transactional/Historical | Document Approval API | The endpoint used is GET {{runtime_url}}/{requisitions|invoices|userprofiles}?realm={realm}&$count={true|false}&$filter=uniqueName eq '{uniqueName}'&$skip={offset}&$top={maxRecords} and the requisitions option is used. Later those are filtered by uniqueName using the requisition ID as parameter. |
Purchase order | Order_Header | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Names: DirectOrder_SAP_updatedRange; CopyOrder_SAP_updatedRange; ERPOrder_SAP_updatedRange |
Purchase order | Order_LineItems | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Names: DirectOrder_SAP_updatedRange; CopyOrder_SAP_updatedRange; ERPOrder_SAP_updatedRange |
Purchase order | Order_SplitAccountings | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Names: DirectOrder_SAP_updatedRange; CopyOrder_SAP_updatedRange; ERPOrder_SAP_updatedRange |
Goods Receipt | Receipt_Header | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Receipt_SAP_updatedRange |
Goods Receipt | Receipt_LineItems | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Receipt_SAP_updatedRange |
Goods Receipt | Receipt_ApprovalRequests | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Receipt_SAP_updatedRange |
Invoice | Invoice_Header | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Invoice_SAP_updatedRange_v2 |
Invoice | Invoice_LineItems | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Invoice_SAP_updatedRange_v2 |
Invoice | Invoice_ApprovalRequests | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Invoice_SAP_updatedRange_v2 |
Invoice | Invoice_ApprovalRecords | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: Invoice_SAP_updatedRange_v2 |
Invoice Reconciliation | InvoiceReconciliation_Header | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: InvoiceReconciliation_SAP_updatedRange |
Invoice Reconciliation | InvoiceReconciliation_Payments | Transactional | Operational Reporting for Procurement API | Same logic as Purchase requisition tables. Template Name: InvoiceReconciliation_SAP_updatedRange |
N/A | companycodes | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: companycodes |
N/A | countries | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: countries |
N/A | paymentterms | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: paymentterms |
N/A | purchasegroups | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: purchasegroups |
N/A | suppliers | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: suppliers |
N/A | uoms | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: uoms |
N/A | users | Master Data | Master Data API Retrieval for Procurement | GET /entities/{EntityName}. Entity Name: users |
N/A | Vendor_List | Master Data | Supplier Data API with Pagination | POST /vendorDataRequests |
Please note:
The Purchase order methods: Direct order, ERP Order from SAP and Carbon copy (CC) Direct order, are the only ones that can be used without requiring modifications to the code. If clients are using custom order methods, an extra development may be needed.
For more details concerning order methods, refer to: https://help.sap.com/docs/ARIBA_PROCUREMENT/99a529968234413b9efaf4f6581a32ea/6c2ecf21c1da1014a9aeb364ee9a651d.html
The following chart contains the list of Sourcing tables that are extracted by default, their information type, the API used to retrieve them and also, the specific endpoint called:
Sourcing Document | Table | Info Type | API | Endpoint |
---|---|---|---|---|
Sourcing Project | Sourcing_projects | Transactional | Operational Reporting for Sourcing API | This table could be extracted synchronously or asynchronously. If extracted synchronously uses GET /views/{viewTemplateName}. If extracted asynchronously uses the POST /jobs. Inside the body of the call, the template and filters are passed. This call retrieves a Job ID, and then, the job status is asked using the GET /jobs/{jobId}. When the status is 'completed', the information is extracted using the GET /jobs/{jobId}/files/{fileId}. For this table the filters passed are createdDateFrom and createdDateTo. The Template Name is: SourcingProjectSourcingSystemView. |
Sourcing Project | Sourcing_project_details | Transactional | Operational Reporting for Sourcing API | This table could be extracted synchronously or asynchronously with the same logic above. |
Sourcing Project | Sourcing_projects | Transactional | Sourcing Project | Sourcing_projects |
Sourcing Project | Sourcing_project_events | Transactional | Sourcing Project Management API | This table is extracted synchronously using the GET /projects/{projectId}. The call uses the list of sourcing project IDs retrieved by the Operational Reporting for Sourcing API as {projectId} to bring their events associated. |
Sourcing Project | Sourcing_projects_history | Transactional/Historical | Sourcing Project Management API | This table is extracted synchronously using the GET /projects/{projectId}/historyRecords. The call uses the list of sourcing project IDs retrieved by the Operational Reporting for Sourcing API as {projectId} to bring their historical information associated. |
N/A | Currency_conversion_rates | Master Data | Master Data API Retrieval for Sourcing | GET /entities/{EntityName}. Entity Name: currencyconversionrate. |
In order to run the extractor the following tools and credentials are required:
Tools
Credentials
The list of items below are defined in the set up of each API and can be found in the Manage section inside the Ariba Developer Portal.
Relevant Considerations:
The items listed above need to be specified per API and can be found in the Ariba Developer Portal. Specifically, to choose the correct Realm, please go to the Manage section and look for the API to be configured. Click on it, and list of information related to the API will be displayed, the 'Realm(s) used by this Application' item is the one which states the realms enabled for the API. To use the P2P APIs, the one displayed as 'BUYER' realm should be chosen, and to use the Sourcing APIs, the one displayed as 'SOURCING' realm should be chosen.
Please note that the link mentioned is the main page to enter the Ariba Developer Portal and, by default, it will access to the US (United States) data center associated, if available. If the need is there, please select the data center desired before filling your access information. Entering to the correct data center will provide the user the correct URLS to configure the Extractor connection to the APIs.
Step | Description |
---|---|
1 | Run the following command in Integrated Terminal, to install the necessary dependencies: pip install -r requirements.txt |
2 | Inside the project, open the user_settings.yaml file |
3 | Set the realm, URLs based on server location, the Client_ID, Application_key and OAuth_Secret values accordingly for each API |
The extractor can be used with Command-line interface (CLI). To run the extractor, use the following command:
python main.py --model-name Z
(e.g. 'Z' as company_codes will extract the companycodes table)
Furthermore the extractor can be run with the optional filter --date-from X --date-to Y
.
Where X
and Y
are dates in the format: YYYY-MM-DD
Alternatively you can run multiple models by passing on --allp2p
or --allsourcing
. Which will download all models from P2P or sourcing. If no option is passed the extractor will not run.
The chart below lists the models that can be extracted, their business process associated to run the extractor with (P2P/Sourcing) and also if the model mandatory requires the date filter.
Model Name | Business Process | Mandatory Date-filter |
---|---|---|
company_codes | P2P | N |
copy_order_updated_range_async | P2P | Y |
countries | P2P | N |
currency_conversion_rate | Sourcing | N |
direct_order_updated_range_async | P2P | Y |
erp_order_updated_range_async | P2P | Y |
invoice_reconciliation_updated_range_async | P2P | Y |
invoice_updated_range_async | P2P | Y |
payment_terms | P2P | N |
purchase_groups | P2P | N |
purchase_orgs | P2P | N |
receipt_updated_range_async | P2P | Y |
requisition_updated_range_async | P2P | Y |
requisition_updated_range_with_history_async | P2P | Y |
counted_requisition_updated_range_with_history | P2P | Y |
counted_receipt_updated_range | P2P | Y |
counted_invoice_updated_range | P2P | Y |
counted_invoice_reconciliation_updated_range | P2P | Y |
counted_direct_order_updated_range | P2P | Y |
counted_erp_order_updated_range | P2P | Y |
counted_copy_order_updated_range | P2P | Y |
sourcing_projects_sync | Sourcing | Y |
sourcing_project_details_sync | Sourcing | Y |
sourcing_project_events_sync | Sourcing | Y |
sourcing_projects_history_sync | Sourcing | Y |
sourcing_project_events_async | Sourcing | Y |
sourcing_project_details_async | Sourcing | Y |
sourcing_project_history_async | Sourcing | Y |
sourcing_projects_async | Sourcing | Y |
suppliers | P2P | N |
uoms | P2P | N |
users | P2P | N |
vendor_lists | P2P | N |
If no date is provided the extractor will download only the models that don't require a date filter (e.g.: company_codes
)
The csv files will be automatically stored inside the 'output' folder of the extractor, in a subfolder named after the date and time when the extraction was performed.
Last but not least, the following python flag command can be run for help: python main.py --help
.
Note: As some models only support the creation date as a filter, it may occur that the delta extractions bring only new records. The models mentioned are listed in the README file
Deltas Execution
The --delta
option can be passed on to download a few models that support this option. It requires a previous successful run. This will ensure that a last update date is added for a specific model. This date will be used as DATE_FROM when running the extractor. And DATE_TO date will be the current GMT date and time.
P2P Delta Extraction
All view templates that are downloaded from Operational Reporting for Procurement API can be extracted with the --delta
option.
Sourcing Delta Extraction
Only the next models can be extracted with the --delta
option:
sourcing_project_events_sync
sourcing_project_details_sync
sourcing_projects_sync
All other sourcing models don't support delta extraction due to the APIs don't support filtering by updated date, only creation date. Currency conversion rate can't be filter by any date.
The SAP Ariba Purchase-to-Pay (P2P) Extractor contains two YAML files, intended to be used for different purposes:
user_settings.yaml: this file should be used by the end user to complete the proper configurations and options that must be populated for the Extractor to run:
prod
)True
, or renamed if set to False
.developer_settings.yaml: this file should be used by developers when the need is there to add new APIs, Models or Template Methods. For each model the developer needs to fill the next fields:
The Template Methods are useful to download data from APIs that have a common structure. The following template methods are currently available in the Extractor:
The Base is a general template method intended to be used as a general base to create more asynchronous APIs template methods. It contains GET and POST methods available but also it allows the user to add another ones (e.g. PATCH).
The ZippedFile template method allows to download the models from the Operational Reporting for Procurement - Jobs Submission API. The following chart shows how this method works:
The Base is a general template method intended to be used as a general base to create more synchronous APIs template methods. It contains GET and POST methods available but also it allows the user to add another ones (e.g. PATCH).
The Counted template method is used for APIs that have a count endpoint. This method will paginate through the results according to the number of elements returned by the count endpoint. It requires that the endpoint count is specified in the API configuration.
The Count Before template method is used for APIs that have a count endpoint and the option to use sync or async endpoints. This method will call the /count endpoint, and based on the amount of records that it returns, it will use the sync or async endpoints. The async method will be used if the amount if greater than 10_000 records, otherwise it will use the sync one.
The List Detail template method is used for endpoints that can be accessed using an ID and also have another endpoint where we can see a list of these IDs. This method will iterate through the list of IDs, retrieve the details for each ID, and return the aggregated results.
The Listed template method is used to bring the Sourcing projects information derived from an ID list. This method is not independent, it will only work when the need to call by ID list is there. This method will download the required information.
The Paginated by Count template method is used for APIs that gives paginated information, but we cannot ask in advance how many elements will be retrieved (like the counted method). So for each call we will receive the values as well as the total amount of elements.
The Paginated by nextToken template method is used for endpoints whose next page is generated by a token called 'nextToken'. Which is an integer saying how many values we should use as 'skip' to retrieve next page. This method retrieves the data in batches defined by 'top' param, then iteratively fetching the next page of data using the token returned by the previous request. This approach avoids retrieving duplicate data in overlapping batches.
The Paginated by Token template method is used for endpoints whose next page is generated by a token. This method retrieves the data in batches by specifying the initial token, then iteratively fetching the next page of data using the token returned by the previous request. This approach avoids retrieving duplicate data in overlapping batches.
Step | Description |
---|---|
1 | Inside the 'tables' folder, select the python file of the API to which the new field corresponds to |
2 | Add the name of the new field in the list of fields of the table it belongs to |
3 | Inside the 'models' folder , select the python file of the API to which the new field corresponds to |
4 | If the updated model is created inside a view_parser, go to the 'view_parsers' folder , select the python file of the API to edit the parser of the desired viewTemplate and make sure to add that field. |
5 | Add the name of the new field in the list of fields of the table it belongs to. |
Note: to delete a field, inside the 'tables' folder, select the python file of the API and then the table that has the field that needs to be removed.
To add a new template method, it is necessary to create a new subclass of the BaseTemplateMethod abstract class and implement the 'download_data' method. The 'download_data' method should extract the data from the API and stores it with an output handler. The output handler is responsible for writing the data to a file in the specified format.
Map the template method in the settings.py file with a unique name. That name should be used in the developer_settings.yaml file.
Step | Description |
---|---|
1 | Add the configuration in the file developer_settings.yaml |
2 | Add the corresponding ***_api_key , ***_client_id , and ***_secret variables in the user_settings.yaml file. |
3 | If a new model is needed, this can be added in the 'models' folder |
4 | Create a new table in the 'tables' folder if needed. The table must have fields that are included in the model |
5 | Add the new model in the entrypoint.py file, under the LIST_MODELS variable |
6 | Add the new model in the settings.py file, under the MODELS_MAPPING variable. Also add in the same file the new table in the TABLES_MAPPING variable |
The Ariba APIs can be synchronous or asynchronous. Each of the APIs used for the extraction process are either one of the former.
They are defined as follows:
Asynchronous APIs: These type of APIs generate a job that runs in Ariba and create a report that, when finished, it needs to be downloaded. The maximum number of records returned per page is 10,000, or 10 files containing 1000 records per file. Files created in response to asynchronous requests expire after 48 hours. Requested output is batched into ZIP files containing 1000 records per file, and these files can be downloaded one at a time.
Synchronous APIs: These APIs do not generate a report that later on needs to be downloaded. Instead, the same call done to the APIs returns the extracted information. The requested output is batched and paginated, and results are returned one page at a time in JSON format. The maximum number of records returned is 10,000. The maximum number of records per page is 40.
Note: specific setups were created to increase the amount of records that can be extracted using multiple pages to extract them.
The data is extracted with the SAP Ariba Extractor using the following APIs:
Allows to obtain approval, denial, and comments on requisitions and invoices generated in an SAP Ariba Buying and Invoicing solution.
For more details please refer to: https://help.sap.com/docs/ARIBA_APIS/f9cd5fe02da34e5a9c0ddd8161ee04d1/4611dab7ea77404eb7eeb1ab76110fc9.html
Stores master data loaded from external systems in the master data service.
For more details please refer to: https://help.sap.com/docs/ARIBA_APIS/b62431d654644850ab1ca6ba6a4c532e/cbeb2ad3aa8642068035e7157744b97f.html?locale=en-US
For more details please refer to: https://help.sap.com/docs/ariba-apis/master-data-retrieval-api-for-sourcing/master-data-retrieval-api-for-sourcing
Enables to retrieve header, line item, and other details for transactions (such as purchase requisitions, purchase orders, receipts, invoices, and invoice reconciliations) through REST API calls.
For more details please refer to: https://help.sap.com/docs/ARIBA_APIS/42cb9e6fb65a4fa7b03f5e0ec7d406f9/f111d2662f204beea9e12c9924a05a60.html
For more details please refer to: https://help.sap.com/docs/ariba-apis/operational-reporting-api-for-strategic-sourcing/operational-reporting-api-for-strategic-sourcing
For more details please refer to: https://help.sap.com/docs/ariba-apis/sourcing-project-management-api/sourcing-project-management-api
Enables to access supplier data on a read-only basis for integration to a third-party tool; for example, to get a list of all suppliers with registered, qualified, or preferred status for a specific category, region, and business unit.
For more details please refer to: https://help.sap.com/viewer/60ec8b8bb9344dbe8dcf15e2a1edc85b
This section contains relevant considerations about the extractor design.
The Script content:
1. cli_handler: first folder and contains the entrypoint file for the extractor to start working.
2. documentation: this folder contains the extractor specifics and the images associated to it.
3. extractor: contains the extractor internal settings as models mapping, tables mapping, methods mapping, parser mapping and the output handler mapping.
4. logger: contains all the logger configuration, e.g. the storage destination of the logger file that the extractor provides as output.
5. models: this folder is split by API and contains all the fields to be extracted and formatting of them.
6. output handler: is the module to handle the creation of csv files. The extractor allows that the output type could be modified (e.g. replacing csv for txt).
7. request_handler: contains files that will manage the requests for a correct connection to the API (e.g. authentication: new token requests)
8. tables: this folder is split by API and contains all the tables that will be extracted, based on the models already defined.
9. template_methods: this folder contains the template methods which allows to connect to the APIs. The extractor offers by default synchronous and asynchronous methods.
10. utils: this folder contains a series of files that provides the main setups for file handling, object parsing and rate limits.
11. view parsers: contains specific parsers for each table and field that will be extracted.
12. main.py
13. release_notes.md: document with extractor version specifics.
14. requirements.txt: lists the requirements that are needed for the extractor to work.
15. user_settings.yaml: contains a series of extractor settings that the user should define to run the extractor.
16. developer_settings.yaml: contains a series of extractor configurations that, if needed, the developer could modify (e.g. to add a new API).
The Delta extractions
The chart below lists of tables that allows delta extractions, their business process, their API associated and a brief explanation of the logic used in the Extractor to retrieve them.
Table | Business Process | API | Logic |
---|---|---|---|
Order_Header | P2P | Operational Reporting for Procurement | The Extractor needs a previous successful run to be able to work with deltas. Each successful run will add an entry in last_run.json file. This entry has the last update time of the run. If the option delta in the CLI file is enabled, the Extractor download the model from the last updated item until today. The models associated to this table that allows delta extractions are: copy_order_updated_range_async, copy_order_updated_range_sync, direct_order_updated_range_async, direct_order_updated_range_sync, erp_order_updated_range_async, erp_order_updated_range_sync |
Order_LineItems | P2P | Operational Reporting for Procurement | Same logic above. |
Order_SplitAccountings | P2P | Operational Reporting for Procurement | Same logic above. |
Requisition_Header | P2P | Operational Reporting for Procurement | Same logic above. The models associated to this table that allows delta extractions are: requisition_updated_range_with_history_async, requisition_updated_range_with_history_sync |
Requisition_ApprovalRecords | P2P | Operational Reporting for Procurement | Same logic above. |
Requisition_LineItems | P2P | Operational Reporting for Procurement | Same logic above. |
Requisition_History | P2P | Document Approval API | Same logic above. |
InvoiceReconciliation_Header | P2P | Operational Reporting for Procurement | Same logic above. The models associated to this table that allows delta extractions are: invoice_updated_range_async, invoice_updated_range_sync. |
InvoiceReconciliation_Payments | P2P | Operational Reporting for Procurement | Same logic above. |
Invoice_Header | P2P | Operational Reporting for Procurement | Same logic above. |
Invoice_LineItems | P2P | Operational Reporting for Procurement | Same logic above. |
Invoice_ApprovalRecords | P2P | Operational Reporting for Procurement | Same logic above. |
Invoice_ApprovalRequests | P2P | Operational Reporting for Procurement | Same logic above. |
Receipt_Header | P2P | Operational Reporting for Procurement | Same logic above. The models associated to this table that allows delta extractions are: receipt_updated_range_async, receipt_updated_range_sync |
Receipt_ApprovalRequests | P2P | Operational Reporting for Procurement | Same logic above. |
Receipt_LineItems | P2P | Operational Reporting for Procurement | Same logic above. |
Vendor_List | P2P | Supplier Data API with Pagination | Same logic above. The model associated to this table that allows delta extractions is: vendor_list |
Sourcing_projects | Sourcing | Operational Reporting for Sourcing | Same logic as above. The models associated to this table that allows delta extractions are: sourcing_projects_sync. |
Sourcing_project_details | Sourcing | Operational Reporting for Sourcing | Same logic as above. The models associated to this table that allows delta extractions are: sourcing_project_details_sync. |
Sourcing_project_events | Sourcing | Sourcing Project Management API | Same logic as above. The models associated to this table that allows delta extractions are: sourcing_project_events_sync. |
The extractor has to deal with limitations that SAP Ariba sets to their APIs. It limits the amount of records that can be extracted per each call and it also limits the amount of calls per time. These limits are defined per API Key (API and its credentials associated).
The below is the detail of limits SAP Ariba sets by API:
Operational Reporting for Procurement API
Inside this API there are different limits. In the SAP Ariba P2P Extractor the following can be found:
API call | Limit |
---|---|
Operational Reporting for Procurement - View Management API | Rate Limit (Requests): 1/second, 10/minute, 100/hour, 500/day |
Operational Reporting for Procurement - Job Submission API | Rate Limit (Requests): 1/second, 2/minute, 8/hour, 40/day |
Operational Reporting for Procurement - Job Results API | Rate Limit (Requests): 4/second, 20/minute, 200/hour, 1000/day |
Operational Reporting for Sourcing API
Inside this API there are different limits. In the SAP Ariba P2P Extractor the following can be found:
API call | Limit |
---|---|
Operational Reporting for Sourcing - Synchronous API | Rate Limit (Requests): 1/second, 3/minute, 50/hour, 300/day |
Operational Reporting for Sourcing - Job Submission API | Rate Limit (Requests): 1/second, 2/minute, 8/hour, 150/day |
Operational Reporting for Sourcing - Job Results API | Rate Limit (Requests): 2/second, 20/minute, 200/hour, 1000/day |
Document Approval API
Rate Limit (Requests): 300/second, 800/minute, 35000/hour
Master Data API Retrieval for Procurement
Rate Limit (Requests): 10/second, 40/minute, 200/hour, 1000/day
Master Data API Retrieval for Sourcing
Rate Limit (Requests): 10/second, 40/minute, 200/hour, 1000/day
Sourcing Project Management API
Rate Limit (Requests): 5/second, 30/minute, 3500/hour
Supplier Data API with Pagination
Rate Limit (Requests): 3/second, 150/minute, 4500/hour, 25000/day
For more limit details, please refer to the Ariba Developer Portal > Discover section.
SAP Ariba allows the deletion of certain documents in specific cases, although this is not a common action (e.g. a Purchase requisition could be deleted if it is on its first status in the process which is 'Composing' or it has not been approved yet; a Sourcing Project could only be deleted if a specific parameter is enabled in the system, etc). SAP Ariba APIs will not retrieve the deleted record. To remove the deleted record, it is required to do a full extraction, drop the table from the database and upload the updated table. The other way to remove the deleted record, is to manually remove the record from the table in the database.
Update dates for delta extractions
In some cases, SAP Ariba perfom updates to records (e.g. after 30 days, a Purchase requisition in 'Composing' status, is automatically withdrawn by the system, which user is aribasystem). This could be the reason why more records than expected are retrieved when a delta extraction is done.
Status_code: 400 - output: {'error' : 'The API key passed in the request is not valid.'}
Sourcing Projects Versioning: When certain attributes of a sourcing project get changed, Ariba updates the version of the original project and also creates a new record in the sourcing project table to store all the original values before they were changed. This new Project_id will not have any History details and therefore its ID will not bring any values when running the extraction for the history information. There is no possible way to filter those cases out before running the extractor. But all these errors can be ignored as they are not going to cause any issues for the Connector.
Sourcing Project Management API with mandatory user parameter: This API will only retrieve the Sourcing Project Events and the Sourcing Project Details that were created by the user specified in the user_settings.yaml file. Any sourcing project ID passed to this API that does not belong to the user specified will retrieve an error that the Extractor is prepared to ignored and continue with the extraction.
Error Handling and Feedback
The SAP Ariba Purchase-to-Pay (P2P) Extractor is designed to tackle the most common API problems.
The following chart contains the APIs used in the Extractor by default, the errors it is prepared to solve by itself and a brief summary of how it is done and the message the user will see in the log while the solving is done:
API | Error and Description | Extractor Solution | Log Message |
---|---|---|---|
All APIs | Token expired (401) | The extractor requests another token automatically | "Refreshing tokens..." |
All APIs | 400, 402, 403, 404, 500 | The extractor will return the message. This error message changes by Endpoint, even though the code is the same. | Error code and message that SAP Ariba provides. E.g. for Operational Reporting for Procurement API - Endpoint: POST /jobs, the error 403 message would be: "Unauthorized/API key not found: Token Expired/ API Key not found'. |
Operational Reporting for Procurement API | 400 - quotaExceeded | When we call a sync endpoint to retrieve a view from Operational Reporting for Procurement API, and the amount of elements that match the filters is bigger than certain value (could be 10000 but is not consistent). It responds with a 'Quota Exceeded' error. Meaning that we should use the async alternative. | "QUOTA EXCEEDED: The number of matched records for specified criteria exceeds the allowed limits. Please use the 'async' alternative or change the filter criteria." |
All APIS | 429 - Request limits reached | The extractor contains a retry logic to calculate the waiting time and retry automatically | "Requests per {second/minute/hour/day} reached. Waiting {seconds_to_wait} seconds until next {minute/hour/day}" |
Sourcing Project Management API | 403 - 10109 | The extractor will ignore the Sourcing Project that does not belong to the user specified. | "User isn't authorized to view/edit the project. |
Sourcing Project Management API | 400 - 11013 | The extractor will ignore the Sourcing Project that doesn't exists. | "Trying to get project history that doesn't exists." |
Sourcing Project Management API | 400 - 11003 | The id of the project corresponds to a Template Project and can't be downloaded. | "The specified full Project Id is same as Template Id." |
Sourcing Project Management API | 401 - 10001 | The specified user doesn't exists. | "The specified user cannot be found." |
All APIs | Service unavailable (503) | The server cannot be reached. | "503 ERROR: Service unavailable." |
"
Notes:
The access to the complete list of errors by API Endpoint could be found in the Manage section inside the Ariba Developer Portal.
SAP Ariba provides the general complete list of Errors that the APIs could retrieve if a submitted API query fails, their HTTP Code; Error Code; Error Message, and Additional Information associated (if available), grouped by API.
For more errors and details please refer to:
Operational Reporting API for Procurement: https://help.sap.com/doc/053c2365029b4616a47c9c0e1b809f12/cloud/en-US/c402cec669eb455ea9979ad55c91914b.pdf
Operational Reporting for Sourcing: https://help.sap.com/docs/ariba-apis/operational-reporting-api-for-strategic-sourcing/error-messages-returned-by-reporting-apis?q=errors
Document Approval API: https://help.sap.com/docs/ariba-apis/document-approval-api/error-message-returned-by-document-approval-api
Master Data Retrieval API for Procurement: https://help.sap.com/doc/99394f55f7114e56ade523f8cb34fa94/cloud/en-US/MasterDataRetrievalAPI_Procurement.pdf
Master Data Retrieval API for Sourcing: https://help.sap.com/docs/ariba-apis/master-data-retrieval-api-for-sourcing/error-messages-returned-by-master-data-retrieval-api-for-sourcing?q=error
Sourcing Project Management API: https://help.sap.com/docs/ariba-apis/sourcing-project-management-api/error-messages-returned-by-sourcing-project-management-api?q=errors
Supplier Data API with Pagination: https://help.sap.com/doc/63527aca54584ec19ae53a5b28d4b8f1/cloud/en-US/6e56c0b1fd1c49eb8e87befeae6c4ff2.pdf