Logo

  • Home
  • For First-time Visitors
    • About the Network
      • Who We Are
      • How It Works
      • What We Do
      • Why We Exist
      • History
      • Contacts
    • Getting Started
    • Network Grants
  • For Program Staff
    • Benefits
    • Find a Data Exchange
    • Network Grants
    • Data Exchange Status
    • Learn about Project Teams
  • For IT Staff
    • Getting Started Guide for IT Professionals
    • Download Node Software
    • Find Existing Data Exchanges
    • Knowledge Base and Technical Standards
    • Exchange Network Discovery Service
    • Learn about Project Teams
    • Learn about Available Shared Services

Sharing information for a cleaner environment

  • About
    • Who We Are
    • How It Works
    • What We Do
    • Why We Exist
    • Network Grants
    • Governance
    • Tribal EN Group (TXG)
    • Contacts
      • Exchange Network Help Desk
  • Data Exchanges
    • Air
    • Cross-Program
    • Health
    • Natural Resources
    • Waste
    • Water
  • Meetings
  • Partners
  • Knowledge Base
  • EN Alerts
Home › Knowledge Base › Developers Center › Web Service Development Rules and Resources

Web Service Development Rules and Resources

Recipients Parameter Guidance and Best Practices 

The ‘recipients’ parameter in the Node 2 Specification, is a feature designed to enable nodes to dynamically send messages to multiple parties without the need for pre-programmed business logic. The following guidelines and best practices will assist flow developers interested in using the ‘recipients’ parameter.

Technical Details

  • The Recipients parameter is a string that may be a Node URI or an email address.
  • If a submission request specifies a Node URI recipient, the processed package will be forwarded to the specified recipient using the submit method.
  • If a submission request specifies an email recipient, the processed package will be emailed to the specified recipient.
  • Optional for a receiving node to implement functionality to process ‘recipients.’
  • Required as an element in the request message (the value may be empty).
  • On any error processing for the recipient parameter, a node should return a SOAP fault indicating there was an error with recipients. In this instance, the originating node must resend the submission.

Security

  • The NAAS will provide authorization capabilities for ‘recipients.’ Node administrators will be able to define which users can make use of this function through standard NAAS policies.
  • Nodes forwarding submissions through the ‘recipients’ parameter will need to use their own NAAS credential to authenticate with the receiving node.
  • Specific security models and error conditions/messages should be defined on a flow by flow basis.

Best Practices

  • Nodes should only honor ‘recipient’ values from trusted partners who have been explicitly permitted to make use of this functionality.
  • Flow developers should seek to use ‘recipients’ only when it reduces complexity and improves functionality of a business process.
  • This feature is not intended to be a ‘forwarding’ mechanism for multiple nodes. Flows using recipients should seek to minimize the processing and transmission that any one node would experience in the process of honoring this parameter.
This entry was posted in Developers Center. Bookmark the permalink.
  • Home
  • About
  • Site Map
  • EN Alerts
  • Contacts

© 2025 E-Enterprise and Exchange Network Interoperability and Operations Team

Powered by Swapps