WG01: Business Messages Work Group (BMWG)
The PIDX Business Messages Work Group (BMWG) establishes usage guidelines for approve Transaction, Routing and Packaging (TRP) protocols used in the transmission of PIDX standards between trading partners. Additionally, BMWG provides technical support with regard to XSD schema development and maintenance to the Standards and Guidelines (S&G) Committee and other Work Groups and Project Teams. Key deliverables include XML schema development and maintenance, maintenance of implementation guidelines, usage guidelines,analysis, and recommendation for adoption of new TRP protocols, and liaison with other groups with regard to emerging technologies relevant to PIDX.
SPT01a: Conversion to JSON/REST Pilot
The PIDX JSON/REST Pilot Standards Project Team is dedicated to exploring converting existing XML-based architecturebased on JSON messaging and RESTful APIs. JSON/REST is a standard that is used for mobile and modern application development, where more business transactions are occurring. The Standards Project Team begins its work by focusing on invoice submission and response messages.
CHAIR: Chris Lambert, Payload
SPT01c: RNIF PIP and GBAC Update
As the industry increases the use of digital integration of processes, new schemas start to become deployed, such as the ASN. The current PIDX documentation has not assigned PIPS and GBACs to these newly deployable document types. The purpose of this project is to update the list of PIPs and GlobalBusinessActionCode tables where they do not exist for new XML Documents. The current list of PIDX RNIF PIPs and GlobalBusinessActionCode lists only covers a subset of the PIDX XML business document schemas that PIDX has developed schemas for in its V1.62 package. This project is a short assignment project to complete the documentation required to allow PIDX members to deploy XML schemas using the RNIF transport and utilize pre-assigned PIPS and GBACs with their trading partners.
WG02: Business Processes Work Group (BPWG)
The PIDX Business Processes Work Group (BPWG) analyzes issues related to targeted documents and recommends solutions to address the most common buyer and supplier issues. BPWG facilitates new standards for ebusiness within the Oil and Gas by analyzing which aspects of Procure to Pay (P2P) and order fulfillment require business process guidelines. The Work Group also defines the process to document business process guidelines, solutions and business process guidelines, and determines whether current documents require modifications or additional documents are needed.
WG03: Catalog and Classification Work Group
The Catalog and Classification Work Group enables high-quality, standardized items and service descriptors to be used across the industry, reducing cost and risk associated with exchange of these terms. Drawing from expertise from all parts of the Oil and Gas industry, the Work Group developed and maintains the Petroleum Industry Data Dictionary (PIDD). This structured dictionary describes products and services – from upstream, downstream, operator, oilfield services, and suppliers – and it is open to all to access royalty free. The PIDX Catalog and Classification Work Group also maintains the Petroleum Industry Glossary, a collection of terms used throughout the Oil and Gas industry.
CHAIR: Mark Amberman, BP
SPT03a: Support for UOM Scheme
The purpose of this project team is to amend the current PriceSheet and transaction document schemas to allow an UOM scheme to be able to be referenced. The current schema definitions do not facilitate identifying the UOM scheme.
WG04: Downstream Work Group
The Downstream Work Group supports organizations participating in the petroleum downstream market sector and develops process and technology standards that facilitate seamless and efficient electronic business for downstream organizations. Additionally, the Work Group acts as custodian of codes for the Oil and Gas industry, its trading partners, and vendors.
CHAIR: Elena Mereanu, Transport4
VICE CHAIR: Roger Hurst, Global Value Web
SPT04b: Standards for the Exchange of Fuel Hauler, Vehicle and Driver Records
The PIDX Fuel Hauler Records Standards Project Team aims to promote efficiency for fuel haulers, which must certify their company, vehicles, and drivers for each terminal from which they lift. The establishment of standards for the capture, storage, and retrieval of these records not only eliminates inconsistency and duplication of efforts, but promotes innovation and possibility in developing future technologies, such as leveraging biometrics and implementing automation into terminal and driver interfaces.
SPT04c: Extending LoadingDeliveryReceipt to Add Further Detail for Barge Movements
The Petroleum Industry Data Exchange, Inc. (PIDX) and Leadership for Energy Automated Processing (LEAP) are working together to further digitize and automate the European barge oil trading market centered around Amsterdam/Rotterdam/Antwerp (ARA). The organizations are building upon a functional standard agreed via a LEAP committee formed in February 2018 and extending the existing PIDX standard LoadingDeliveryReceipt Version 5.02 to accommodate certain new requirements needed for ARA buyers, sellers, and terminal operators.
CHAIR: Thomas Kockish, BP
VICE CHAIR: Jens Thuns, Shell
Standards for the Exchange of Hauler, Vehicle, and Driver Records
Proposed Project Team Study Name:
- Standards for the exchange of fuel hauler, vehicle and driver records.
Executive Summary
- Currently, fuel haulers must certify their company, their vehicles and their drivers for each fuel terminal they lift from in a market, which, quite often, involves providing similar information multiple times, in different formats, to different parties.
- As there is no agreed structure for the record keeping, sharing of information between stakeholders is difficult and inefficient.
- In absence of standards for the exchange of these records, there is also much duplication of effort by fuel terminal operators to capture, store, maintain and retrieve these records at the local terminal level – within a network and across operators.
- The lack of standards is also a barrier to technical innovation, for instance leveraging biometrics for more robust terminal access control, or automating terminal and driver interfaces. Vendors currently have no guidelines for the development of technologies that would support these innovations.
- Several PIDX members have expressed interest in establishing common standards for terminal master data records in the past. As this is a vast undertaking, starting with fuel hauler, vehicle and driver records would be a substantial start.
- This project proposes to lay out standards for the capture, storage and retrieval of fuel hauler, vehicle and driver records for the purpose of exchanging records efficiently between stakeholders.
Anticipated Completion Date: December 31, 2019
If you are interested in joining the PIDX Standards Project Team for the Exchange of Hauler, Vehicle, and Driver Records, submit a signed participation form to administrative@pidx.org.
JSON/REST Project Team
Read more to learn about the JSON/REST Project Team. View the full Project Team Proposal Speficification Support here.
1. Proposed Project Team/Study Name
JSON+REST Pilot for converting PIDX XML standards
2. Executive Summary
PIDX would like to explorer converting its existing XML based messaging to a newer architecture based on JSON messaging and RESTful APIs. JSON/REST is a standard that is used for mobile and modern application development and the PIDX community has requested support for it as more business transactions occur on mobile and modern platforms.
The project team will focus on Invoice submission and Response messages so that the PIDX community can more quickly, and easily, understand how the feasibility of JSON/REST. Upon completion of the project we will evaluate the roadmap for migration of all standards.
3. Description
3.1 Purpose
The purpose of this project is convert existing PIDX messaging and standards to use a JSON messaging format and REST API architecture
3.2 Scope
The scope is limited to the Invoice submission and response process and messaging so that we can understand the technical challenges, risks, and potential solutions to the wider PIDX standards.
The scope will also include reviewing any existing PIDX users who have tried to use JSON and REST APIs on their own and to document their challenges, status, and current state.
3.3 Goal
3.3.1 Identify criteria for success of the deliverables / specification as deployed in industry.
- Convert existing Invoice and InvoiceResponse schemas to use a JSON messaging format
- Map REST API methods – GET, PUT, POST, DELETE – to Invoice submission and response business processes.
- Identify technical and business process gaps that may exist in a JSON/REST architecture that cannot be addressed
- Review any existing implementations that have done with JSON/REST based on PIDX standards. 3.3.2 Identify how the proposed deliverables / specification relates to existing or under development deliverables / specifications. Identify how these will relate to each other.
3.3.2 Identify how the proposed deliverables / specification relates to existing or under development deliverables / specifications. Identify how these will relate to each other.
| Existing Standards | New Standards/Deliverables |
| Invoice.xsd and InvoiceResponse.xsd | JSON specifications for Invoice and Response |
| Existing AS2 and RNIF Guidelines & Protocols | REST API specification for required RESTful methods |
3.3.3 Identify the integral sets of specifications that will be created or modified by the proposed work effort. (See 8.0 Initial Contributions)
Deliverables:
- JSON specifications for Invoice and Response
- REST API specification for required RESTful methods
- Lessons learned from process of converting architecture
- Findings for other members or partners that have executed, successfully or unsuccessfully, to JSON/REST
3.3.4 Identify the expected useful life of the proposed deliverables / specification, e.g. estimated retirement dates or circumstances.
The useful life of JSON and RESTful APIs will be determine based on risks and gaps identified in this project.
3.4.1 Identify how this work is specific to the energy industry and to the primary area of focus for PIDX. Identify other sources for aspects of the required solution that are not industry specific.
The usage of this new architecture pairs well with the movement towards more mobile friendly devices, such as tablets and smart phones, and also is a potential leadin to Blockchain platforms.
3.4.2 Identify the solutions that currently exist in the area of the proposal. Identify competing technologies/solutions.
Other solutions in this area include legacy solutions, such as fixed width and XML, and non-standard solutions that are unique to specific proprietary platforms. The goal of PIDX is to drive standards that call can use so we don’t believe the proprietary platforms are viable solutions.
3.4.3 Identify other organizations that are doing similar work. Identify what they are doing and why additional work is needed. Identify how the proposed work effort will coordinate with related work efforts.
We believe that there are some PIDX members already using JSON and REST APIs. One of the goals of this project is to investigate them further, capture lessons learns, and any best practices that have been developed.
3.4.4 Identify the industry organizations / groups who want this deliverable / specification.
We are currently working with Baker Hughes, a GE Company (BHGE), Cortex, and Oildex on this specification.
3.4.5 Identify all of the stakeholders of which you are aware.
BHGE, Cortex, Oildex
3.4.6 Identify the stakeholders who are willing to join the work effort. (See Sponsor & Participants)
BHGE and Cortex have confirmed that they are willing to sponsor this initiative within PIDX.
3.5 Proposal
The proposal includes migrating the Invoice and InvoiceResponse messaging over to JSON formats and then developing the RESTful APIs to receive these messages. The RESTful APIs should identify the mappings for GET/POST/PUT/DELETE operations and corresponding HTTP response codes for errors.
The goal of the project is to understand how current PIDX architecture would map, both technical and business process, and any gaps or challenges that are encountered.
The project team is also expected to canvas the PIDX community for existing usage of JSON/REST and capture lessons learned and best practices.
Benefits
Key Benefits include:
Understand risk of using JSON/REST in a business transaction environment
Enable new architecture footprint that is compatible with mobile standards and applications
Identify effort to convert standards so that a longer term roadmap could be established
Sponsor and Participants
PIDX member/company sponsoring development of these specifications/this project:
| Member | Company | E-Mail Address |
| Marc Battistello | BHGE | Marc.battistello@bhge.com |
| Chris Lambert | Cortex | clambert@cortex.net |
The following PIDX members/companies are participants in the development of these specifications:
| Member | Company | E-Mail Adddress |
| Marc Battistello | BHGE | Marc.battistello@bhge.com |
| Chris Lambert | Cortex | clambert@cortex.net |
| Lucian Pop | Cortex | lpop@cortex.net |
| Lynn Taylor | Oildex | lynn.taylor@oildex.com |
Deliverable Schedule
Anticipated Completion Date
February 28, 2019
Initial Contributions
| Document Name | Type of Document | Document Source |
| Invoice.xsd | Invoice PIDX Schema v1.61 | PIDX |
| InvoiceResponse.xsd | Invoice Response Schema v1.61 | PIDX |
| AS2 Usage Guideline | PIDX Guideline | PIDX |
| RNIF: Rosetta Net Implementation Framework | PIDX Guideline/Framework | PIDX |
Field Ticket Project
View the Field Ticket Response Schema Project Team Proposal (PTP)
CLICK HERE to view our Field Ticket Best Practices Guideline.
Purpose
The purpose of phase 1 of the Field Ticket Project is to document industry best practices for implementation of the field ticket process for operators and suppliers in the upstream oil and gas industry in order to increase adoption of the PIDX Field Ticket Standard.
Problem Statement
- Today our industry is faced with manual, paper-based and legacy processes
- Massive amounts of transactional volumes of supplier activity
- Unnecessary of the supplier driving to/from field offices
- Overpayment/coding errors (joint venture audit issues, adjustments)
- Lack of real-time knowledge of activities or expenditures
Sponsors
The PIDX Field Ticket Project is sponsored by ConocoPhillips.
Contact
For more information, email James Thompson at James.Thompson2@conocophillips.com
.
