Download the complete service offering docx format of interchange_service_definition.doc


1. Description of Service

Interchange is the Commonwealth's secure, efficient, cost effective and flexible service for supporting the exchange of data between agencies of the Commonwealth and their business partners.

Interchange Features:

• Supports standard file transfer protocols including SFTP, MQ/FTE, FTP/ES
• Clients are available for several operating systems, including Windows, Linux, and AIX
• Easy to use web-based interface for transferring ad-hoc files:
• File transfer status monitoring web based interface for system file transfers:
• Automated email notifications for transfer success or failure.

Interchange supports several forms of file transfer including: 


1. System-to-System(S2S)

System-to-System supports automated (batch) file transfers between two or more systems. This service manages retries for files that cannot be delivered. This Interchange offering works by placing a file in an agreed upon folder on the sender’s machine that will get delivered to the destination machine in an agreed upon folder.  This is an automated process. It is called System-to-System because the intent is that "people" are not required in the process and jobs typically run and get triggered on a scheduled basis.

A System-to-System file transfer can be implemented using:

  • MQ/FTE Agent - IBM’s WebSphere MQ File Transfer Edition (FTE). This agent can only be installed within MAGNet.
  • SFTP over Port 22. This flexible solution is available to agencies and their business partners, regardless of location.
  • FTP/ES over Port 21. Limited to MassIT Mainframe connections.
  • Any combination of the above provided the requirements for each are met.


System-to-System file transfers require software to be installed on an agency’s server:

  • IBM MQ/FTE Agent (for MQ/FTE transfers)
    • An FTE agent is a Java process that runs on a machine and performs file transfers to and from other agents. In order to transfer files to or from a machine using FTE, you must have an agent running on that machine. Every agent connects to a WebSphere MQ queue manager and uses MQ to communicate with other agents.
  • Interchange Agent (for MQ/FTE and SFTP transfers)
    • An Interchange Agent is a small Java application that acts as a file folder watch, and triggers a call to start the transfer process to another endpoint.
  • MassIT also offers a managed file transfer server that users can connect to using any SFTP client (like Filezilla, WinSCP, etc.) to upload/download files.  Users are responsible for initiation of a file transfer if using this SFTP client option as opposed to an Interchange Agent which offers automation.


2. Person-to-Person(P2P)

Person-to-Person is a web-based system that allows the transfer of files up to 200 MB between two individuals. This is the simplest form of file transfer and doesn't require any additional software at either end of a transfer. This solution is called Person-to-Person since it is designed for more ad-hoc style "one-time" or "occasional" transfers from one person to another.

Interchange P2P File Transfer web site:

  • A Commonwealth employee can self-register for an account (‘Register User’ link on
  • Non-state users can be invited by state employees to use this system. A file transfer via Interchange system from a state employee to a non-state user will initiate an account creation for a non-state user.
  • In order for a file transfer to be successful, either a sender or a recipient needs to have an email address ending in ‘’ domain. 
  • An email notification is sent to user’s email address each time there is a new file in the system for a user to be downloaded.


3. System-to-Person(S2P)

A System-to-Person is a component that allows a file to be dropped in an agreed upon system folder and then an email is sent to a person to notify them that they have a file ready for download.  A recipient of a file uses a web-based interface ( to download a file to their local machine.  Sending messages is an automated process.  Picking up the files is a manual process.


4. Person-to-System(P2S)

A Person-to-System is a component that allows a person to upload a file using a web-based interface ( and the file gets delivered to an agreed upon system folder. Sending the files is a manual process. Delivery of the files to the intended system is an automated process.


Options for external business partners who need to exchange files with a state agency within Commonwealth

  • Any SFTP client (WinSCP, FileZilla) to connect to MassIT’s SFTP Server
    • External users are responsible for initiation of a file transfer when using SFTP clients.
    • External users will be provided with a username, a password and access to a folder(s) in order to upload/download files to/from MassIT’s SFTP Server.
  • MassIT’s Interchange Agent software
    • In order for an external user to use MassIT’s software, a license agreement needs to be signed between MassIT, an agency and an external business partner.
    • Specific firewall ports need to be opened between MassIT’s network and an external user’s network.
  • External business partner’s own SFTP Server
    • MassIT will need to be provided with an SFTP account from an external business partner to upload/download files.  Further, MassIT cannot get files from this SFTP server, only put files there.  The customer may put files on an MassIT SFTP server in order to return files to the intended recipient. 

XML Gateway

The XML Gateways within the Commonwealth are IBM DataPower XI-50 and XB-60, DMZ-ready appliances that provide agencies with the ability to allow for:

  • Secure transfer of XML data into and out of MAGNet,
  • Transformation between disparate message formats including binary, IBM MQ, and XML
  • Message routing
  • Security of SOA messages

The appliances themselves are managed through a command line or a web-GUI interface by the Integration Services team to ensure stability, reliability, security and scalability of deployed services in conjunction with the Security Office who provides perimeter security through the general maintenance of firewalls and other security infrastructure.

There are different patterns of using Data Power services within the Commonwealth, as well as among business partners and citizen facing applications. All deployment patterns are supported by using specific XML Gateway Services (e.g. WS-Proxy, Multi-protocol Gateway, Web Application Firewall, etc). Each of the built-in XML Gateway Services has unique features and capabilities that make their use applicable in certain contexts.

Web Service Proxies enhance the abilities of the XML Firewalls by adding support for WSDL validation.

Multi-protocol Gateways support protocols other than SOAP – such as MQ, FTP, SMTP, etc - and can be useful in the processing of straight HTTP-based protocols, for instance.

Web Application Firewalls support session variables which can be useful in contexts where cookies or other session information needs to be preserved as part of a long-lived transaction.

The XML Gateways have been deployed at two different tiers: the Enterprise and Partner/Secretariat levels.

XML Gateway Tiers

Enterprise Gateway(s):

  • All service requests originating from the Internet will first be processed by the Enterprise XML Gateways which will enforce broad security and enterprise policies (e.g. XDoS attack prevention, virus detection, XML parsing constraints, etc.).
  • In addition to the "default" and "routing" domains, the XML Gateways have been partitioned into separate ‘Community Domains’ (egg. EOHHS, Enterprise)
  • The Enterprise XML Gateway will forward any message attachments to an ICAP -compliant (Internet Content Adaptation Protocol) Enterprise Virus Scanning Server maintained by MassIT
  • Internet Clients invoke services through the Enterprise XML Gateways - e.g. Based on the message URI (HHS/*), the request is routed to the appropriate Community Domain (EOHHS).
  • All SOAP/HTTP(S) XML traffic destined for Secretariat XML Gateways must first be processed by the Enterprise XML Gateways in order to enforce Enterprise Security and other policies.

Secretariat Gateway(s):

  • The Secretariat Gateways accept traffic relayed from the Enterprise XML Gateways, Secretariat Partner Gateways, or allowed hosts within the EHS Virtual Gateway environments.
  • Additional policies can be enforced within the Secretariat Gateways, such as AAA policies.
  • Web services are deployed to the Secretariat gateways behind Multi-Protocol Gateways.
    In the routing Domain, requests are relayed from the routing Service Multi-Protocol Gateway to web services (Web Service Proxies) in the EHS domain based on a setRoutingRulesXSLT.xsl style sheet.

Partner Gateway(s):

  • Partner Gateways accept traffic from a dedicated connection in the Business Partner DMZ in MITC.
  • All web service requests entering the Business Partner DMZ will first be processed by the Partner XML Gateways which will enforce broad security and enterprise policies (e.g. XDoS attack prevention, virus detection, XML parsing constraints, etc.).
  • In addition to the default and routing domains, the Partner XML Gateways include a separate application domain (egg. EOHHS)
  • The Partner XML Gateway will forward any message attachments to an ICAP -compliant (Internet Content Adaptation Protocol) Enterprise Virus Scanning Server maintained by MassIT
  • Clients invoke services through the Partner XML Gateways - e.g. https://<<hostname>>/HHS/FileTransferService Based on the message URI (HHS/*), the request is routed to the appropriate Application Domain (EOHHS).
  • All SOAP/HTTP(S) XML traffic originating from the dedicated Partner link and destined for Secretariat XML Gateways must first be processed by the Partner XML Gateways to ensure enforcement of Enterprise Security and other policies.


Support services include:



2. Service Targets and Metrics


Service RequirementDescription



Service availability hours are 24x7excluding planned maintenance and unplanned outages.

• Interchange maintenance (to add new requests) is performed weekly on Tuesdays from 1pm to 4pm (except holidays).
• Interchange software upgrades are performed quarterly.
• DataPower firmware upgrades are performed quarterly.
• Any non-standard or ad-hoc maintenance windows are scheduled in advance.

All changes to production environment  are part of the MassIT change control process and customers are notified via email.

Incident Management*MassIT Service Management Office has standard processes to manage incidents, requests, or changes.

Outages or urgent issues should be reported by phone to receive the quickest response 1-866-888-2808.



Staff will respond to service requests between 9:00 am - 5:00 pm excluding holidays. Emergency requests must be opened as incidents to ensure they are acted on immediately out of normal business hours.






File Transfer StatusFile transfer status displayed in Interchange Monitoring Tool within 2 minutes.Interchange Monitoring Tool




Interchange Availability 95%Interchange service is available to customers 24x7x365, except maintenance windows scheduled in advance.Tivoli Monitoring Service

*Incidents, requests, or changes that are outside the scope of the defined service description or normal service hours will be direct charged to the customer.


3. Service Reporting

We offer an Interchange Status and Reporting tool that allows Interchange customers to monitor and track their data transfers using a web-based interface:


4. Service Requests

COMiT Service Request*


Lead Time- Business Days

Request New XML Gateway Service

Request a new service deployment into the XML Gateway.

15 Days

Request Modification of  XML Gateway Service

Request a service change within the XML Gateway.

15 Days

Request Deletion of  XML Gateway Service

Request a service deletion within the XML Gateway.

1 Days

Request New Interchange Service

Request a new service within Interchange. Interchange allows the Commonwealth’s diverse applications to exchange files with each other regardless of technologies.  Interchange manages the connections to computer systems to communicate in the same manner without knowing what platform is on the other end.

25 Days

Request Interchange Service Modification

Request a change within Interchange including:

- Reset password for an existing account.

- Modify/Rename directory structure for an existing service.

- Add/Delete account for an existing service.

- Reinstall Software.

15 Days

Request Interchange Information

Request information about Interchange.

7-15 Days

Request New XML Gateway Service

Request a new service deployment into the XML Gateway.

15 Days

*For new service requests only. To manage existing requests, please log into COMiT.

5. Customer Responsibilities

The customer will identify any firmware upgrades and configuration modifications and coordinate activities for moving/changing code through the Change Management process. The customer will provide XML schemas and WSDLs for new service deployments, recommend configuration changes to optimize utilization and coordinate benchmarking activities as required.

For your convenience, you may also view a detailed list of customer responsibilities.


6. Chargeback Rate Information

For more information on Chargeback, including an overview of the program as well as current and previous fiscal year rates, please visit our Chargeback Services webpage.



Updated September 03, 2015
Reviewed September 03, 2015
Published August 14, 2009
Created March 25, 2009: Information provided by the Enterprise Policy & Architecture Team