@itentialopensource/adapter-meraki 0.8.0 → 0.8.3

package/AUTH.md

@@ -0,0 +1,39 @@
+## Authenticating Meraki Adapter 
+
+This document will go through the steps for authenticating the Meraki adapter with Basic Authentication. Properly configuring the properties for an adapter in IAP is critical for getting the adapter online. You can read more about adapter authentication <a href="https://www.itential.com/automation-platform/integrations/adapters-resources/authentication/" target="_blank">HERE</a>. 
+
+### Basic Authentication
+The Meraki adapter requires Basic Authentication. If you change authentication methods, you should change this section accordingly and merge it back into the adapter repository.
+
+STEPS  
+1. Ensure you have access to a Meraki server and that it is running
+2. Follow the steps in the README.md to import the adapter into IAP if you have not already done so
+3. Use the properties below for the ```properties.authentication``` field
+```json
+"authentication": {
+  "auth_method": "basic user_password",
+  "username": "<username>",
+  "password": "<password>",
+  "token": "",
+  "token_timeout": 1800000,
+  "token_cache": "local",
+  "invalid_token_error": 401,
+  "auth_field": "header.headers.Authorization",
+  "auth_field_format": "Basic {b64}{username}:{password}{/b64}",
+  "auth_logging": false,
+  "client_id": "",
+  "client_secret": "",
+  "grant_type": ""
+}
+```
+4. Restart the adapter. If your properties were set correctly, the adapter should go online. 
+
+### Troubleshooting
+- Make sure you copied over the correct username and password.
+- Turn on debug level logs for the adapter in IAP Admin Essentials.
+- Turn on auth_logging for the adapter in IAP Admin Essentials (adapter properties).
+- Investigate the logs - in particular:
+  - The FULL REQUEST log to make sure the proper headers are being sent with the request.
+  - The FULL BODY log to make sure the payload is accurate.
+  - The CALL RETURN log to see what the other system is telling us.
+- Remember when you are done to turn auth_logging off as you do not want to log credentials.

package/BROKER.md

@@ -0,0 +1,195 @@
+## Integrating Meraki Adapter with IAP Device Broker
+
+This document will go through the steps for integrating the Meraki adapter with IAP's Device Broker. IAP Device Broker integration allows for easier interation into several of IAPs applications (e.g. Configuration Manager). Properly configuring the properties for the adapter in IAP is critical for getting the device broker integration to work. Their is additional information in the configuration section of the adapter readme. This document will go through each of the calls that are utilized by the Device Broker.
+
+### getDevicesFiltered
+getDevicesFiltered(options, callback) → This call returns all of the devices within Meraki that match the provided filter.
+
+#### input
+
+options {object}: defines the options for the search. At current filter is the most important one. The filter can contain the device name (e.g. the options can be { filter: { name: [‘abc’,  ‘def’] }}. The adapter currently filters by doing a contains on the name(s) provided in the array and not an exact match. So deviceabc will be returned when this filter is applied. In many adapters, other options (start, limit, sort and order) are not implemented.
+
+#### output
+
+An Object containing the total number of matching devices and a list containing an array of the details for each device. For example, { total: 2, list: [ { name: ‘abc’, ostype: ‘type’, port: 80, ipaddress: ‘10.10.10.10’ }, { name: ‘def’, ostype: ‘type2’, port: 443, ipaddress: ‘10.10.10.15’ }] }
+
+The fields name and ostype are required by the broker and should be mapped through properties to data from the other system. In addition, ipaddress and port should also be mapped as it is utilized by some north bound IAP applications (e.g. Config Manager). There are other fields that can be set as well but consider these the minimal fields.
+
+Below is an example of how you may set up the properties for this call.
+
+```json
+"getDevicesFiltered": [
+  {
+    "path": "/{org}/get/devices",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "requestFields": {
+      "org": "555"
+    },
+    "responseFields": {
+      "name": "host",
+      "ostype": "os",
+      "ostypePrefix": "system-",
+      "ipaddress": "attributes.ipaddr",
+      "port": "443"
+    }
+  },
+  {
+    "path": "/{org}/get/devices",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "requestFields": {
+      "org": "777"
+    },
+    "responseFields": {
+      "name": "host",
+      "ostype": "os",
+      "ostypePrefix": "system-",
+      "ipaddress": "attributes.ipaddr",
+      "port": "443",
+      "myorg": "org"
+    }
+  }
+]
+```
+
+Notice with the path, there is a variable in it ({org}). This variable must be provided in the data available to the call. For getDevicesFiltered this means the requestFields as a static value. In other calls, it may also come from the result of the getDevicesFiltered call.
+
+Notice with the responseFields, it wants the IAP data key as the key and where it is supposed to find the data in the response as the value. You can use nested fields in the response object using standard object notation. You can also add static data as shown in the port field. Finally, you can append data to the response from the requestInformation using its key (e.g. org). The ostypePrefix is a special field that allows you to add static data to the ostype to help define the system you are getting the device from.
+
+Notice here that you can also have multiple calls that make up the results provided to the Device Broker. In this example we are making calls to two different organizations and returning the results from both. 
+
+### isAlive
+isAlive(deviceName, callback) → This call returns whether the device provided is operational.
+
+input
+
+deviceName {string}: the name of the device to get details of. The adapter will always call getDevicesFiltered first with this name in the filter in order to get any additional details it needs for this call (e.g. id).
+
+output
+
+A boolean value. This usually needs to be determined from a particular field in the data returned from the other system. This is where definind a status value and a status field is critical to properly configuring the call.
+
+Below is an example of how you may set up the properties for this call.
+
+```json
+"isAlive": [
+  {
+    "path": "/{org}/get/devices/{id}/status",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "statusValue": "online",
+    "requestFields": {
+      "org": "myorg",
+      "id": "name"
+    },
+    "responseFields": {
+      "status": "status"
+    }
+  }
+]
+```
+
+Notice with the requestFields, it will use the org and name that it got from the response of the getDevicesFiltered call to complete the path for the call.
+
+Notice with the responseFields, it use the status field that came back and test to see if the value is online since that is what you defined as the statusValue. If it is it will return true otherwise it will return false.
+
+You could have multiple calls here if needed but generally that will not be the case.
+
+### getConfig
+getConfig(deviceName, format, callback) → This call returns the configuration for the device. This can be a simple call or a complex/multiple calls to get all of the “configuration” desirable.
+
+input
+
+deviceName {string}: the name of the device to get details of. The adapter will always call getDevicesFiltered first with this name in the filter in order to get any additional details it needs for this call (e.g. id).
+
+format {string}: is an optional format you want provided back. Most adapters do not support formats by default and just return the “stringified” json object.
+
+output
+
+An object containing a response field which has the value of the stringified config (e.g. { response: ‘stringified configuration data’ }
+
+Below is an example of how you may set up the properties for this call.
+
+```json
+"getConfig": [
+  {
+    "path": "/{org}/get/devices/{id}/configPart1",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "requestFields": {
+      "org": "myorg",
+      "id": "name"
+    }
+    "responseFields": {}
+  },
+  {
+    "path": "/{org}/get/devices/configPart2",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "requestFields": {
+      "org": "myorg"
+    }
+    "responseFields": {}
+  }
+]
+```
+
+The example above shows multiple calls. With the handleFailure property set to ignore, if one of the calls fails, the adapter will still send the response with that configuration missing. If you want it to fail set the handleFailure property to fail.
+
+There is no limit on the number of calls you can make however understand that the adapter will make all of these calls prior to providing a response so there can be performance implications.
+
+### getDevice - may be deprecated
+getDevice(deviceName, callback) → This call returns details of the device provided. In many systems the getDevicesFiltered only returns summary information and so we also want a more detailed call to get device details.
+
+input
+
+deviceName {string}: the name of the device to get details of. The adapter will always call getDevicesFiltered first with this name in the filter in order to get any additional details it needs for this call (e.g. id).
+
+output
+
+An Object containing the details of the device. The object should contain at least the same information that was provided in the getDevicesFiltered call (e.g. the fields name, ostype, port and ipaddress should be mapped in the adapter properties to data from the other system) and may contain many more details about the device.
+
+Below is an example of how you may set up the properties for this call.
+
+```json
+"getDevice": [
+  {
+    "path": "/{org}/get/devices/{id}",
+    "method": "GET",
+    "query": {},
+    "body": {},
+    "headers": {},
+    "handleFailure": "ignore",
+    "requestFields": {
+      "org": "myorg",
+      "id": "name"
+    },
+    "responseFields": {
+      "name": "host",
+      "ostype": "os",
+      "ostypePrefix": "system-",
+      "ipaddress": "attributes.ipaddr",
+      "port": "443",
+      "myorg": "org"
+    }
+  }
+]
+```
+
+You could have multiple calls here if needed but generally that will not be the case.

package/CALLS.md

@@ -0,0 +1,169 @@
+## Using this Adapter
+
+The `adapter.js` file contains the calls the adapter makes available to the rest of the Itential Platform. The API detailed for these calls should be available through JSDOC. The following is a brief summary of the calls.
+
+### Generic Adapter Calls
+
+These are adapter methods that IAP or you might use. There are some other methods not shown here that might be used for internal adapter functionality.
+
+<table border="1" class="bordered-table">
+  <tr>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Method Signature</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Description</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Workflow?</span></th>
+  </tr>
+  <tr>
+    <td style="padding:15px">connect()</td>
+    <td style="padding:15px">This call is run when the Adapter is first loaded by he Itential Platform. It validates the properties have been provided correctly.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">healthCheck(callback)</td>
+    <td style="padding:15px">This call ensures that the adapter can communicate with Meraki. The actual call that is used is defined in the adapter properties and .system entities action.json file.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">refreshProperties(properties)</td>
+    <td style="padding:15px">This call provides the adapter the ability to accept property changes without having to restart the adapter.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">encryptProperty(property, technique, callback)</td>
+    <td style="padding:15px">This call will take the provided property and technique, and return the property encrypted with the technique. This allows the property to be used in the adapterProps section for the credential password so that the password does not have to be in clear text. The adapter will decrypt the property as needed for communications with Meraki.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapUpdateAdapterConfiguration(configFile, changes, entity, type, action, callback)</td>
+    <td style="padding:15px">This call provides the ability to update the adapter configuration from IAP - includes actions, schema, mockdata and other configurations.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapFindAdapterPath(apiPath, callback)</td>
+    <td style="padding:15px">This call provides the ability to see if a particular API path is supported by the adapter.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapSuspendAdapter(mode, callback)</td>
+    <td style="padding:15px">This call provides the ability to suspend the adapter and either have requests rejected or put into a queue to be processed after the adapter is resumed.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapUnsuspendAdapter(callback)</td>
+    <td style="padding:15px">This call provides the ability to resume a suspended adapter. Any requests in queue will be processed before new requests.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapGetAdapterQueue(callback)</td>
+    <td style="padding:15px">This call will return the requests that are waiting in the queue if throttling is enabled.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapTroubleshootAdapter(props, persistFlag, adapter, callback)</td>
+    <td style="padding:15px">This call can be used to check on the performance of the adapter - it checks connectivity, healthcheck and basic get calls.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+
+  <tr>
+    <td style="padding:15px">iapRunAdapterHealthcheck(adapter, callback)</td>
+    <td style="padding:15px">This call will return the results of a healthcheck.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapRunAdapterConnectivity(callback)</td>
+    <td style="padding:15px">This call will return the results of a connectivity check.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapRunAdapterBasicGet(callback)</td>
+    <td style="padding:15px">This call will return the results of running basic get API calls.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapMoveAdapterEntitiesToDB(callback)</td>
+    <td style="padding:15px">This call will push the adapter configuration from the entities directory into the Adapter or IAP Database.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">genericAdapterRequest(uriPath, restMethod, queryData, requestBody, addlHeaders, callback)</td>
+    <td style="padding:15px">This call allows you to provide the path to have the adapter call. It is an easy way to incorporate paths that have not been built into the adapter yet.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">genericAdapterRequestNoBasePath(uriPath, restMethod, queryData, requestBody, addlHeaders, callback)</td>
+    <td style="padding:15px">This call is the same as the genericAdapterRequest only it does not add a base_path or version to the call.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapHasAdapterEntity(entityType, entityId, callback)</td>
+    <td style="padding:15px">This call verifies the adapter has the specific entity.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapVerifyAdapterCapability(entityType, actionType, entityId, callback)</td>
+    <td style="padding:15px">This call verifies the adapter can perform the provided action on the specific entity.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapUpdateAdapterEntityCache()</td>
+    <td style="padding:15px">This call will update the entity cache.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+</table>
+<br>
+  
+### Adapter Broker Calls
+
+These are adapter methods that are used to integrate to IAP Brokers. This adapter currently supports the following broker calls.
+
+<table border="1" class="bordered-table">
+  <tr>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Method Signature</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Description</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Workflow?</span></th>
+  </tr>
+  <tr>
+    <td style="padding:15px">hasEntities(entityType, entityList, callback)</td>
+    <td style="padding:15px">This call is utilized by the IAP Device Broker to determine if the adapter has a specific entity and item of the entity.</td>
+    <td style="padding:15px">No</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">getDevice(deviceName, callback)</td>
+    <td style="padding:15px">This call returns the details of the requested device.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">getDevicesFiltered(options, callback)</td>
+    <td style="padding:15px">This call returns the list of devices that match the criteria provided in the options filter.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">isAlive(deviceName, callback)</td>
+    <td style="padding:15px">This call returns whether the device status is active</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">getConfig(deviceName, format, callback)</td>
+    <td style="padding:15px">This call returns the configuration for the selected device.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+  <tr>
+    <td style="padding:15px">iapGetDeviceCount(callback)</td>
+    <td style="padding:15px">This call returns the count of devices.</td>
+    <td style="padding:15px">Yes</td>
+  </tr>
+</table>
+<br>
+
+### Specific Adapter Calls
+
+Specific adapter calls are built based on the API of the Meraki. The Adapter Builder creates the proper method comments for generating JS-DOC for the adapter. This is the best way to get information on the calls.
+
+<table border="1" class="bordered-table">
+  <tr>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Method Signature</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Description</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Path</span></th>
+    <th bgcolor="lightgrey" style="padding:15px"><span style="font-size:12.0pt">Workflow?</span></th>
+  </tr>
+</table>
+<br>

package/CHANGELOG.md

@@ -1,4 +1,28 @@
 
+## 0.8.3 [05-08-2022]
+
+* Patch/broker cleanup
+
+See merge request itentialopensource/adapters/sd-wan/adapter-meraki!18
+
+---
+
+## 0.8.2 [05-02-2022]
+
+* Patch/broker fix
+
+See merge request itentialopensource/adapters/sd-wan/adapter-meraki!17
+
+---
+
+## 0.8.1 [04-13-2022]
+
+* added properties for broker calls and new documentation
+
+See merge request itentialopensource/adapters/sd-wan/adapter-meraki!16
+
+---
+
 ## 0.8.0 [01-21-2022]
 
 * migration to the latest foundation and broker ready

package/CODE_OF_CONDUCT.md

@@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
 
 Examples of behavior that contributes to creating a positive environment include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 
@@ -34,15 +34,10 @@ This Code of Conduct applies both within project spaces and in public spaces whe
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [support@itential.com](mailto:support@itential.com). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at support@itential.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
-
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/4/
-
-_return to [README](../README.md)_
+This Code of Conduct is adapted from the <a href="http://contributor-covenant.org" target="_blank">Contributor Covenant</a>, version 1.4, available at <a href="http://contributor-covenant.org/version/1/4/" target="_blank">version</a>