We strongly recommend taking advantage of our BriteAPIs for standard implementations. BriteCore offers RESTful APIs that conform to OpenAPI specifications and a fully decoupled UI, enabling strong support for integration.
BriteCore’s APIs offer more than 1,000 API endpoints out of the box and more than 75 plug-and-play integrated vendor solutions. The API Gateway sits in front of our backend services to provide a single URL for RESTful programmatic communication with our services. It handles concurrent API calls, traffic management, authorization, access control, monitoring, and version management.
Code contribution considerations
In some cases, particularly for nonstandard uses of BriteCore, you may want to modify the underlying source code. BriteCore operates in a Community model, where contributed code is merged into our master branch for all customers to use.
If after evaluating our APIs you still require access to the source code, keep the following guidance in mind:
- Follow the predevelopment process and obtain approval before you begin any work.
- To contribute to BriteCore’s master branch, the functionality must be generic enough to be useful to the entire BriteCore community.
- You’re responsible for coding and debugging your development environment. Our support teams can answer specific questions about BriteCore, but it’s assumed you have the necessary skills and resources to deliver quality code that conforms to our standards.
- You will have the best development experience using MacOS.
Predevelopment approval process
Before you start any development follow the following steps.
Step 1: Sign a Contribution and Source Code Access Agreement
The first step is to gain access to our source code by working with our partnerships team to obtain and sign a copy of the Contributions and Source Code Access Agreement. Once this is signed, the BriteCore team can request Github access to the BriteCore repositories in Github. Please note that a monthly fee may apply for Github seats for BriteCore to cover its development costs.
Note: An agreement is required only for ongoing development, not one-off contributions.
Step 2: Get set up as a BriteCore Developer
After signing the agreement, you will obtain access to Github.
Make sure to review the following:
- Solution Architecture design and review process
- Partner pull request process flow
- BriteCore’s quality assurance process
Step 3: Pre-approval process: Submit a written summary of the proposed changes
Submit a brief, written summary of your proposed changes to the Strategic Alliances and Partnerships team. The benefit of submitting these changes is twofold:
- It allows for the review of the technical approach and eliminates the possibility of duplicate or unnecessary functionality.
- It prepares the development teams for an inbound code submission to be tested and fosters timely acceptance.
The Product, Solution Architecture, and Strategic Alliances and Partnership teams will review the request.
Your written summary should include the following details as applicable:
Describe the proposed solution to achieve the success criteria outlined in the story.
Include a summary of an overall technical approach to achieve the success criteria.
Discuss any changes that will be made to the database schema and propose naming for any new tables and columns.
If this change spans more than one repository (for example, a frontend/backend change), list all repositories that will be affected.
Document the interface of any APIs that will be changed or added as part of this change.
Proof of concept (optional)
Occasionally it is easier to show than tell when describing a software solution. In this case, you can include code snippets and even a small proof of concept related to the change. However, it’s important that the proof of concept is treated as such and isn’t expected as finished work.
Describe the benefits of the proposed solution.
Describe any potential pitfalls with the proposed solution. Include any assumptions made that led to the proposed solution.
List any new configurations available for clients. Include deployment configuration, environment variable configuration, and runtime configuration.
Step 4: Submit the code and help QA/address changes
At this point, you’re ready to develop and submit the code using our pull request process.