BEP Services (formerly BIS) ((formerly BGS)) User Guide - department-of-veterans-affairs/abd-vro GitHub Wiki

For a visual representation of how BIS fits into the VRO's broader architecture, see this mural.

From the BEP services team:

BEP hosts the BEP Services (formerly Benefits Integration Services (BIS)/ Benefits Gateway Services (BGS)), which are a collection of J2EE java and Tuxedo functionality providing information flow to and from the VBA Corporate Database (CRP) and client systems which consume, update and process CRP (CRP is the VBA Corporate Database) records. BEP services are used by 40+ systems for benefits related data and processing, including Veterans Benefits Management System (VBMS). Client based web interfaces leverage BEP technologies such as SSL/TLS (secure socket layer / transport layer security) encryption, signed certificate mutual authentication, and session-based timeouts for security. BEP Services integrate with the VA Identity and Access Management (IAM) system to provide single sign-on capability, and an integrated, unified authentication and security management framework.

Deciding to use BIS

You can check this document (VA network required) to understand if the BIS system can be helpful for fulfilling your technical needs.

Using the Service for Currently Approved Use Cases

To understand the expected request/response pattern of the VRO microservice for this API see the comments in abd-vro/svc-bgs-api/src/main_consumer.rb.

The BIS microservice follows the same RabbitMQ-based communication mechanism as VRO's other microservices. You can read more about this model here. A consumer of the microservice is required to use a RabbitMQ client of sorts to publish and receive messages.

Expanding the Integration with BIS

New use cases or expansions of existing use cases must be presented for approval with the BIS team to ensure that requests from different applications are attributed appropriately. Any application seeking to leverage VRO's integration with BIS (including members of the VRO team) must obtain new credentials from the BIS team. The VRO and EE teams may be able to assist or provide guidance on this process, but a brief outline is given below.

Be sure that the product manager of VRO is aware of any changes or new uses.

Once an expansion is agreed to by the VRO product manager, a ticket can be created to be routed to the BIS team by visiting the DOTS service desk website and searching for BGS (potentially will get updated to BIS). The BIS team asks that requests are made in a problem-oriented way so that they can help identify the proper subservices or endpoints that will best suit the use case you are trying to resolve. They ask that tickets are not framed as simply: "we want access to X service." Make sure the VRO product manager is kept up to date on the status of any requests.

Once any approvals are made by the BIS team, new credentials may need to be installed at the granularity of the consumer of the VRO BIS microservice. Futhermore, the BIS microservice may need to be updated to implement additional methods, preferably passing along inputs to the client implemented at https://github.com/department-of-veterans-affairs/bgs-ext. The VRO team should be able to help any partner teams with this step. For any new methods implemented, it may be helpful to document the expected request/response structure at the microservice level to help future engineers understand how to easily use the service methods.