Best Practices for Building an Adapter

Follow these best practices and recommendations while building adapters using the Rapid Adapter Builder.

Best practice	More information
Start small and iterate	You don't need to build everything all at one time. Remember this guidance during the following phases of your work: Prioritizing requirements The first version of your adapter doesn't have to address every use case for every user. Instead, you can tackle a few use cases for a few users. Then, release new capabilities in future releases. Developing the adapter Regardless of the number of APIs that your adapter will support in a given release, Oracle recommends creating a Postman collection with just one API. Identify a fine-grained business process, such as surfacing the status of the purchase order or an expense report to a client application. This method helps you identify the API that needs to be exposed in the adapter. Generate the adapter definition document based on Postman collection that you build for testing the API. Customize the adapter definition document as needed for the API and test it. After you're satisfied with the capabilities and feel confident working in the adapter definition document, you can easily add another API. Oracle recommends adding APIs one at a time, testing them, and updating as needed. This approach offers many benefits. For example, you can better track your time, deliver more frequent releases (if needed), respond to changing requirements more quickly, and test in isolation. Additionally, you won't be overwhelmed by needing to review and test a dozen or more APIs at one time.
Test as you go	In addition to starting small and iterating, Oracle recommends testing as you go. For instance, after specifying the requirements for a single API, test the adapter before you add the next API. The level of testing is up to you. You might focus only on functional testing and save all other testing for after you've added all the required features to the adapter for the release; or you might opt for more extensive testing. After you confirm that the adapter is functioning as designed, create another Postman collection with the new API that the adapter supports, add the Postman collection to the adapter definition document. No need to worry: Your adapter definition document maintains all the customizations that you've completed, even if you add more APIs to it. Next, continue the updating, pushing, and testing cycles. You can repeat these steps as needed until your adapter meets all requirements. See Add Functionality to an Adapter Definition Document.
Maintain backward compatibility	Oracle adapters are built to be backward compatible. Oracle recommends building your adapters the same way.
Use semantic versioning	With semantic versioning, you increment the version number of an adapter in a meaningful way. Semantic versioning helps people understand the types of changes that you include in each new version of an adapter. See Rules for the Semantic Version Check. Note: Currently, the Rapid Adapter Builder doesn't allow a major version change that breaks backward compatibility.
Remember the output when designing the input	All the requirements that you include in your adapter definition document appear on just a handful of pages in a wizard in Oracle Integration. More complexity in your adapter definition document results in a more complex user experience for integration developers. Keep this restriction in mind when designing your adapter. Build an adapter that is exactly as complex as it needs to be, and no more.
Support your users	Create documentation that helps integration developers work with your adapter. See Publish the Adapter Documentation.