Partner Implementation

Each directed graph passes username, password and url when accessing an external service/REST API.

These usernames, passwords and urls can be distributed across many properties files that each directed graph using those services needs to load. Even if combined into a single file each graph will need to load and parse that file and then pass the username, password and url with each call.

Instead of having each graph pass this information the restapicallnode can accept a partner key. This partner key should be unchanging and is a unique key only the controller should be aware of (external systems don't need to know about this key).

Restapicallnode will load all of the partners from partner.json. A sample of this format can be found on the changeset https://gerrit.onap.org/r/c/ccsdk/sli/plugins/+/88032/7/restapi-call-node/provider/src/test/resources/partners.json Each partner will have a baseURL, username and password.  Username and password are required, URL Is optional. The caller can pass a suffix that is appended to the baseURL when the baseURL is present. This is so the caller never needs to load and parse partners.json, but can pass the minimal set of information (partner key + urlSuffix).

Generic Retry

Sometimes these are multiple instances of a service and the caller wants to retry a second, third, etc instance of that service when the first attempt has failed.

This scenario has come up a few times so rather than having the logic be specific to a certain use-case it should be generic. To keep this generic the caller just passes a CSV of URLs to try. The code will try each URL in order. Currently the number of attempts is 2 times the number of URLs sent. It will only send to the next URL if it failed during a sunny day scenario if the first URL succeeds no other URLs are attempted.

This retry mechanism is based on socket exceptions so it should only retry when a connection couldn't be established. It won't retry if a resource was missing when accessing a REST API for example.