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

This information was originally created for The SPS Spotlight Series project, which ran from November 2013 through November 2015. 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 sps.helpdesk@caci.com.

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

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. http://www.acq.osd.mil/dpap/pdi/eb/procurement_data_standard.html

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.

What’s happening to the SPS Data

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

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

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.

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.)

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.

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.

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

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

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.

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

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.

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.

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.

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.

webMethods Server Log 2014-02-28 06:19:09 EST [ISP.0090.0004C] ~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. 2014-02-28 12:35:45 EST [ISP.0090.0004C] ~PDSPROCESSOR -- [XXXXXX-14-G-0009- 0001] Building PDS XML 2014-02-28 12:35:53 EST [ISP.0090.0004C] ~PDSPROCESSOR -- [XXXXXX-14-G-0009- 0001] PDS XML document complete 2014-02-28 12:35:53 EST [ISP.0090.0004C] ~PDSPROCESSOR -- [XXXXXX-14-G-0009- 0001] Validating PDS XML against PDS Schema 2014-02-28 12:35:53 EST [ISP.0090.0004C] ~PDSPROCESSOR -- [XXXXXX-14-G-0009- 0001] PDS XML passed validation

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 204.7103(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 12493. https://spssite.caci.com/document_display.cfm?id=12493