1. PDS- Procurement Data Standard
SPS Spotlight Series
October 2014
This guide will provide additional information for PDS.

2. This information was originally created for The SPS Spotlight Series project, which ran from November 2013 through November Updates to the original content may be incorporated to ensure accuracy. If you have any questions about this information, please contact the SPS Help Desk at

3. Overview Introduction to PDS Definitions Architecture Deployment
Supplementary PDS Configuration
Configuring PDS to Route Documents via TN (optional)
webMethods server log
Examples of PDS Validation errors
FAQs

4. Introduction to PDS What is the Procurement Data Standard (PDS)?
A DoD-wide system-independent procurement data standard.
Carries all contract data in a single format for distribution from contract writing systems.
Captures FAR and DFARS rules for contract type, line item structure, etc.
Validation capability at GEX / DLA Transaction Services enforces rules before sending to EDA.
EDA converts awards in PDS XML format into physical contract representation.
What does PDS mean to the SPS User?
Need for greater attention to quality of data in contracts.
Ability, in EDA, to see conformed copy.
Ability to measure, trace, and diagnose contract quality problems.
For more information, see the PDS Home Page.

5. Definitions PDS Event Subscriptions
The PD² Adapter’s outbound transactions are event based.
As an action is taken within the PD² database, the substance of the action is converted into an event for the PD² Adapter’s consumption.
Event subscriptions allow an SA to configure which events the PD² Adapter should process.
Extraction Parameters
Extraction parameters are a sub-component of event subscriptions.
They allow an SA to specify which XML sections are produced for a specific event subscription.
The flexibility provided by extraction parameters is useful for sites that create complex documents with large numbers of included clauses and multiple large attachments, but do not need that information passed on to integration partners. Many production sites, remove extraction parameters to improve performance by reducing the amount of data sent to integrations.
These are common phrases used with PDS. Examples of the PDS Event Subscriptions will be shown later in this presentation.

6. What’s happening to the SPS Data

7. SPS/PDS Architecture SPS DB PD2 Adapter wMs Message Broker PDS IC
PDS XML Files
PDS IC
wMs Server Log

8. SPS/PDS Architecture (continued)
PDS Integration Component (IC)
Contains the PDS package
Applies selection criteria; Issues status message if document is ignored
Maps data from SPS XML structure to the PDS XML structure
Performs Validation
Validates PDS XML against PDS Business Rules
Validates PDS XML against PDS Schema
All status and validation messages recorded only in webMethods Server Log
PDS XML is written to file system
PDS information is written to the webMethods server log. Example of info:
~PDSPROCESSOR -- [XXXXXX-13-P-8108] Building PDS XML
~PDSPROCESSOR -- [XXXXXX-13-P-8108] PDS XML document complete
~PDSPROCESSOR -- [XXXXXX-13-P-8108] Applying PDS Business Rules against PDS XML. 8

9. Deployment Installation A single webMethods Package (PDS)
Event Subscriptions
SQL script provided to identify common subscriptions that could be used
SQL script provided to update common subscriptions with “id” extraction parameter
SQL script provided to insert new custom PDS subscriptions
Properties
Batch file provided to add PDS specific properties to AMSCommonServices’ common properties file
Documentation
Installation Guide
Operations Guide
PDS is applied using a single webMethods package and installed on the Integration Server website. The Event Subscriptions are updated using SQL scripts that are provided with the PDS package. The properties of PDS are stored in the AMSCommonProperties.prop file found in the <IS>/AMSCommonServices/config directory.

10. Supplementary PDS Configuration.
In prior releases of the PDS Extract Utility, sites experienced issues with the Broker Server's storage files filling up. Due to this issue, a supplementary configuration path is now included with the PDS Extract Utility Release 1 and greater. The goal of the supplementary configuration is to significantly reduce the size of each message published to the message Broker. This is accomplished by not including the complete XML document in the message. The new message will consist only of procurement document metadata. The metadata will be flexible and allow the Integration Component (IC) to determine if the document should be processed by PDS. If it should, the PDS IC will request the already produced PD² Adapter XML document from a data store and continue with the PDS translation.
The Supplemental configuration consists of the following:
Installing of the CACISpsIntegCommon package.
Deleting All Legacy PDS Specific Events
Adding Metadata PDS Specific Events
Configuring new Events (TN Sender, TN Receiver, etc.)

11. Baseline PDS Event Subscription Table
This screen shows the baseline PDS events stored in the Event Subscription table. You’ll notice the service_name value of pds.pub.publishForPds. You can view the entire table by running the Event Subscription Diagnostic script in Script-Aid.

12. PDS Event Subscription Table with Supplemental PDS Configurations Applied
These are the results of running the Event Subscription table script after applying the update to the service_name column. This update is part of the Extraction Operations Guides. These new events will publish metadata about a procurement document to the message broker. These events should be used when the amount of data being published to the message broker is a concern.

13. Verification of Versions
FY13 PDS Release 1 package has version 2.3 and Build 41 values as the baseline PDS package.

14. Verification of Versions (continued)
Here is the latest version of PDS, version 4.1

15. Supplementary PDS Configuration
With the release of PDS 4.0, the CACISpsIntegCommon package also gets updated. The updated package has Version 1.0 Build 6.

16. Supplementary PDS Configuration (continued)
Here is the latest version of the CACISpsIntegCommon package that comes with PDS version 4.1

17. Configuring PDS to Route Documents via TN
In releases prior to PDS v3.4, all PDS documents were written to the file system. It was then the responsibility of the SA to get the translated documents from the file system to GEX and any additional third parties. As of PDS v3.4, it is now possible to automatically route the PDS documents to trading partners.
Creation of a new TN Partner with unique DUNS (ex: PDSXML)
The tn_receiver value in the PDS events must be updated with the new DUNS value (tn_receiver = PDSXML).
AMSCommonProperties.prop file must be updated with this DUNS value.
Allows faster processing of the final PDS transmission, to lessen lag time between when the contract is signed and when PDS posts to EDA (Note: this can impact the EDA Scorecard results.)
Note: When making this decision, it is first important to contact your DLA Transaction Services or GEX POC to coordinate the change in transmission methods.

18. Configuring PDS to Route Documents via TN (continued)
In the AMSCommonProperties.prop file the value of the caci.pds.outputMethod property is set to “TN”.
The value of the caci.pds.externalPartnerRouteList is set to the DUNS ID value of the TN Partner Profile(s) that should receive the PDS document.

19. Configuring PDS to Route Documents via TN - PDS TN Partner Profile
Create the appropriate TN Partner Profile(s). Refer to the PD² Adapter v3.1 Functional User’s Guide for additional information.

20. Configuring PDS to Route Documents via TN – Results in MWS Transactions
In previous releases of PDS, no records showed in Transactions for PDS awards/award modifications. Now with the ability to send the XML files directly to GEX, PDS awards/award modifications will appear in Transactions in MWS.

21. webMethods Server Log
:19:09 EST [ISP C] ~PDSPROCESSOR -- [INITIALIZATION] Document ignored because caci.pds.triggerCondition is pds and document type is PD2_Award
Means that a documents was not processed by the PDS IC.
Could be that the document is not a valid doc type for PDS to process.
:35:45 EST [ISP C] ~PDSPROCESSOR -- [XXXXXX-14-G ] Building PDS XML
:35:53 EST [ISP C] ~PDSPROCESSOR -- [XXXXXX-14-G ] PDS XML document complete
:35:53 EST [ISP C] ~PDSPROCESSOR -- [XXXXXX-14-G ] Validating PDS XML against PDS Schema
:35:53 EST [ISP C] ~PDSPROCESSOR -- [XXXXXX-14-G ] PDS XML passed validation

22. Examples of PDS Validation Errors
PDS_V_F_23: <UnitOfMeasure> is required when <Quantity> is provided.
Occurs when a unit of measure is not placed on a line item.
PDS_F_F_18: The value '.00' is not a valid entry for <ObligatedAmount>. It must be greater than zero.
Occurs if an obligated amount of zero is left on an NSP line item.
PDS_F_W_54: The value 'No Charge' should not be used for <UnitPriceBasis>. It was disallowed per DFARS PGI (b).
A common mistake when creating Not Separately Priced line items is to use the cost constraint No Charge. However, No Charge is not allowable in this circumstance.
PDS_G_F_02: <ClauseFullText> was provided as an empty tag. It must be populated or removed.
The Extraction Parameters for PDS data elements are “id, wli, lidff”. If other parameters are used, the error may occur.
Information on all PDS Validation errors can be found in the PDS Compliance Tips Guide for SPS Users on KB ID