@itentialopensource/adapter-microsoft_graph 1.4.7 → 1.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (45) hide show
  1. package/.eslintrc.js +1 -0
  2. package/AUTH.md +4 -4
  3. package/BROKER.md +4 -4
  4. package/CALLS.md +9 -9
  5. package/ENHANCE.md +3 -3
  6. package/PROPERTIES.md +24 -9
  7. package/README.md +24 -23
  8. package/SUMMARY.md +2 -2
  9. package/SYSTEMINFO.md +1 -1
  10. package/TAB1.md +2 -2
  11. package/TAB2.md +17 -11
  12. package/TROUBLESHOOT.md +10 -1
  13. package/UTILITIES.md +473 -0
  14. package/adapter.js +5 -5
  15. package/adapterBase.js +52 -16
  16. package/package.json +24 -28
  17. package/pronghorn.json +15 -13
  18. package/propertiesSchema.json +68 -7
  19. package/report/adapterInfo.json +7 -7
  20. package/report/auto-adapter-openapi.json +8063 -0
  21. package/report/updateReport1748551976792.json +120 -0
  22. package/sampleProperties.json +4 -0
  23. package/test/integration/adapterTestBasicGet.js +88 -54
  24. package/test/integration/adapterTestConnectivity.js +15 -16
  25. package/test/integration/adapterTestIntegration.js +1 -38
  26. package/test/unit/adapterBaseTestUnit.js +641 -39
  27. package/test/unit/adapterTestUnit.js +17 -54
  28. package/utils/adapterInfo.js +114 -164
  29. package/utils/argParser.js +44 -0
  30. package/utils/checkMigrate.js +77 -38
  31. package/utils/entitiesToDB.js +53 -42
  32. package/utils/logger.js +26 -0
  33. package/utils/modify.js +56 -55
  34. package/utils/mongoDbConnection.js +79 -0
  35. package/utils/mongoUtils.js +162 -0
  36. package/utils/taskMover.js +31 -32
  37. package/utils/tbScript.js +36 -172
  38. package/utils/tbUtils.js +84 -226
  39. package/utils/troubleshootingAdapter.js +68 -84
  40. package/utils/updateAdapterConfig.js +158 -0
  41. package/utils/addAuth.js +0 -94
  42. package/utils/artifactize.js +0 -146
  43. package/utils/basicGet.js +0 -50
  44. package/utils/packModificationScript.js +0 -35
  45. package/utils/patches2bundledDeps.js +0 -90
package/UTILITIES.md ADDED
@@ -0,0 +1,473 @@
1
+ # Adapter Utilities
2
+
3
+ Adapter Utilities is not the same thing as adapter-utils. Adapter Utilities refers to utilities that are provided within each adapter to perform generic functionality to assist with troubleshooting, configuration, and support. Where as adapter-utils is a library used by almost all open source adapters to perform core functionality (translation, communication, authentication, throttling, etc) with the external system.
4
+
5
+ If the customer is having issues getting the adapter up and running, they may utilize the adapter utilities to help them determine the issues. If the customer moves the adapter endpoint configuration from the file system to the database they will utilize the adapter utilities.
6
+
7
+
8
+ ## Definitions
9
+
10
+ - **IP Workflow**: Defines the adapter method/task that has been provided in the Itential Platform Automation Studio as a task a customer can add to a workflow, this method can also be utilized in other parts of the Itential Platform such as JSON Forms and in other applications.
11
+ - **CLI**: How a customer would run the script which has been provided in the package.json on the Itential Platform Server command line.
12
+
13
+
14
+ ## Adapter Troubleshooting Utilities
15
+
16
+ ### Run Adapter Healthcheck
17
+ - **IP Workflow**: iapRunAdapterHealthcheck
18
+ - **CLI**: npm run healthcheck
19
+
20
+ This utility exposes a way to run the adapter healthcheck “on demand”. This method has no input and simply runs the healthcheck on the existing adapter and returns the results.
21
+
22
+ #### Input Parameters
23
+ There is no input for this call.
24
+
25
+ #### Operation Flow
26
+ The utility performs only one check:
27
+ 1. **Health Check**: Validates the adapter's health check endpoint.
28
+
29
+ #### Output
30
+ Output format will vary based on whether the call is run from the Itential Platform or the command line. Essentially, the call will return whether the healthcheck was successful or not.
31
+
32
+ #### Best Practices
33
+ 1. Run when:
34
+ - Setting up a new adapter instance
35
+ - Experiencing issues with the adapter or external system that are not obvious
36
+ - After making configuration changes
37
+ 2. Review the results
38
+ 3. Use CLI for quick checks
39
+ 4. Use IP Workflow for checking when there is no access to the CLI.
40
+ 5. Use IP Workflow for automated testing. If adding this task to a "permanent" workflow understand that http(s) adapters are connectionless which means that one calls success has little to do with another calls success or failure.
41
+
42
+ ### Run Adapter Connectivity
43
+ - **IP Workflow**: iapRunAdapterConnectivity
44
+ - **CLI**: npm run connectivity
45
+
46
+ This utility provides the ability to run a connectivity check from the adapter and IP system to the down stream system. It checks things like DNS name resolution, ping, https on the port, etc. This is a nice test to use especially if curl is not available on the IP Server. It utilizes a mocha test that is contained within the adapter integration tests. There is no input required for this call.
47
+
48
+ #### Input Parameters
49
+ There is no input for this call.
50
+
51
+ #### Operation Flow
52
+ The utility performs several connectivity checks:
53
+ 1. **DNS Resolution**: Validates the hostname for the external system can be resolved
54
+ 2. **Ping Test**: Validates the external system is pingable, if not it could be that the system does not respond to ping or that it is not reachable.
55
+ 3. **https to port**: Validates that we can https to the port for the external system. If the external system is http this is not a valid test. If https, then this test failing could mean there is a network issue not allowing the adapter to reach the external system.
56
+ 4. **ip test**: Validates whether IPv4 and/or IPv6 are supported.
57
+
58
+ #### Output
59
+ Output format will vary based on whether the call is run from the Itential Platform or the command line. Essentially, the call will return the results of several tests. These include whether the host for the external system could be resolved, whether the external system is pingable, whether https to the port is successful, and whether the system supports IPv4 and IPv6.
60
+
61
+ #### Best Practices
62
+ 1. Run when:
63
+ - Setting up a new adapter instance
64
+ - Experiencing issues with the adapter or external system that are not obvious
65
+ - After making configuration changes
66
+ 2. Review the results
67
+ 3. Use CLI for quick checks
68
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
69
+
70
+ ### Basic Get
71
+ - **IP Workflow**: iapRunAdapterBasicGet
72
+ - **CLI**: npm run basicget
73
+
74
+ This utility provides the ability to run get calls from the adapter and IP system to the down stream system. This goes beyond the connectivity check to actually check that authentication, endpoints and other components of the call are valid. It utilizes a mocha test that is contained within the adapter integration tests. There is no input required for this call.
75
+
76
+ #### Input Parameters
77
+ The utility optionally accepts a single parameter, maxcalls, a number which references how many GET endpoints to test. If it is not provided the default is 5.
78
+
79
+ #### Operation Flow
80
+ The utility performs as many checks as you would like:
81
+ 1. **Get Call(s) Test**: Validates as many of the *NO INPUT* get calls as you would like. The default number is 5 but you can change this by providing a maxCalls. Changing this will increase the time required for this test to complete. Partial success is often a success as the calls that fail could be the result of permission issues in the external system (e.g. the service account has permissions to do some things but not others).
82
+
83
+ #### Output
84
+ Output format will vary based on whether the call is run from the Itential Platform or the command line. Essentially, the call will returns the results, showing either failure (all tests failed), partial success (some tests succeeded), or success (all tests succeeded).
85
+
86
+ #### Best Practices
87
+ 1. Run when:
88
+ - Setting up a new adapter instance
89
+ - Experiencing issues with the adapter or external system that are not obvious
90
+ - After making configuration changes
91
+ 2. Review the results
92
+ 3. Use CLI for quick checks
93
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
94
+
95
+ ### Troubleshoot Adapter
96
+ - **IP Workflow**: iapTroubleshootAdapter
97
+ - **CLI**: npm run troubleshoot
98
+
99
+ This utility provides the ability to troubleshoot an adapter. It includes comprehensive troubleshooting capabilities for the adapter by combining multiple diagnostic checks into a single operation. It verifies the adapter's connection, health status, and basic functionality. There is no input required for this call.
100
+
101
+ #### Input Parameters
102
+ No input is required from the command line, however the command line is interactive and will allow you to override the default properties taken from the samplePropperties.json file.
103
+ From the Itential Platform workflow, the utility optionally accepts a props object with the following structure:
104
+ ```javascript
105
+ {
106
+ connProps: {
107
+ host: 'string',
108
+ base_path: 'string',
109
+ protocol: 'string',
110
+ port: 'number',
111
+ version: 'string'
112
+ },
113
+ healthCheckEndpoint: 'string',
114
+ auth: {
115
+ auth_method: 'string',
116
+ username: 'string',
117
+ password: 'string'
118
+ }
119
+ }
120
+ ```
121
+ If no properties are provided, the utility will use the current adapter service instance configuration.
122
+
123
+ #### Operation Flow
124
+ The utility performs three checks in sequence:
125
+ 1. **Connectivity Check**: Verifies basic network connectivity
126
+ 2. **Health Check**: Validates the adapter's health check endpoint
127
+ 3. **Basic GET Operations**: Tests fundamental API operations
128
+
129
+ #### Output
130
+ Returns a result object containing:
131
+ - Connectivity test results
132
+ - Health check status
133
+ - Basic GET operation outcomes
134
+ - Any encountered errors or warnings
135
+
136
+ #### Best Practices
137
+ 1. Run when:
138
+ - Setting up a new adapter instance
139
+ - Experiencing issues with the adapter or external system that are not obvious
140
+ - After making configuration changes
141
+ 2. Review all three check results to identify specific issues
142
+ 3. Use CLI for quick checks:
143
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
144
+
145
+ ### Lint
146
+ - **IP Workflow**: iapRunAdapterLint
147
+ - **CLI**: npm run lint:errors
148
+
149
+ This utility provides the results of linting the adapter. This will be success if there are no errors or the actual lint errors if there are errors. This call can be helpful after installing an adapter and finding that it did not come up in the Platform. There is no input required for this call.
150
+
151
+ #### Input Parameters
152
+ There is no input for this call.
153
+
154
+ #### Operation Flow
155
+ The utility run lint on the adapter:
156
+ 1. **Lint Test**: Validates that the adapter lints clean. While lint issues may not impact functionality, clean lint results are desireable and can often eliminate may functional issues. All of the Itential open source adapters are required to lint clean and linting is performed in their pipelines.
157
+
158
+ #### Output
159
+ Output format will vary based on whether the call is run from the Itential Platform or the command line. Essentially, the call will returns the results, showing either success or whatever linting errors it has found. npm run lint:errors will not return any other issues (warnings, etc) making it much easier to see any errors that exist.
160
+
161
+ #### Best Practices
162
+ 1. Run when:
163
+ - Setting up a new adapter instance
164
+ - Making customizations to the code (js files) or configuration (json files) of any adapter
165
+ 2. Review the results
166
+ 3. Use CLI for quick checks
167
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
168
+
169
+ ### Test
170
+ - **IP Workflow**: iapRunAdapterTests
171
+ - **CLI**: npm run test
172
+
173
+ This utility provides the results of running the adapter base unit and unit tests (uses sampleProperties - not actual properties) and returns the results. This will be success if there are no errors or the actual test errors if there are errors. This call can be helpful after installing an adapter and finding that it did not come up in the Platform. There is no input required for this call.
174
+
175
+ #### Input Parameters
176
+ There is no input for this call.
177
+
178
+ #### Operation Flow
179
+ The utility run tests on the adapter:
180
+ 1. **Test Test**: Validates that the adapter tests clean. Adapters are built with unit and integration tests for every method. Many of these tests check for basic functionality. They can be used to make sure the adapter was installed properly (including dependencies). All of the Itential open source adapters are required to test clean and testing is performed in their pipelines.
181
+
182
+ #### Output
183
+ Output format will vary based on whether the call is run from the Itential Platform or the command line. Essentially, the call will returns the results, showing either success or whatever testing errors it has found.
184
+
185
+ #### Best Practices
186
+ 1. Run when:
187
+ - Setting up a new adapter instance
188
+ - Making customizations to the code (js files) or configuration (json files) of any adapter
189
+ 2. Review the results
190
+ 3. Use CLI for quick checks
191
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
192
+
193
+
194
+ ## Adapter Configuration & Information Utilities
195
+
196
+ ### Find Adapter Path
197
+ - **IP Workflow**: iapFindAdapterPath
198
+ - **CLI**: npm run adapter:findpath
199
+
200
+ This utility provides a way for a customer to check to see if an endpoint is available within an adapter. The customer provides part of the path for the endpoint and this method returns all adapter endpoints that match the criteria. Since adapters can have hundreds of calls, this call pays huge dividends to identify whether a call exists and if it does what the call is. Takes in a path or partial path (e.g. /devices, /network/devices, etc).
201
+
202
+ #### Input Parameters
203
+ The partial path you are attempting to find. If the path has dynamic variables within it, those variables should be replaces with {pathv#} or you should use a partial path that excludes the variables.
204
+
205
+ #### Operation Flow
206
+ The utility checks all of the endpoints that the adapter uses to the external system.
207
+
208
+ #### Output
209
+ Returns all of the endpoints that match the path that was provided. It includes the entity and action where those endpoints are which helps to intentify the call that the customer should use.
210
+
211
+ #### Best Practices
212
+ 1. Run when:
213
+ - You are attempting to find if an endpoint exists in an adapter.
214
+ 2. Review the results
215
+ 3. Use CLI for quick checks
216
+ 4. Use IP Workflow for checking when there is no access to the CLI. There should be no reason to use this call in any "permanent" workflows.
217
+
218
+ ### Suspend Adapter
219
+ - **IP Workflow**: iapSuspendAdapter
220
+ - **CLI**: N/A
221
+
222
+ This utility provides the ability for an adapter to be put into a suspended state. In this state an adapter can either reject requests or queue those requests until the adapter is activated. This was originally built so that customers could suspend an adapter when it was known that the downstream system would be unavailable (maintenance window, etc) so that workflows would not fail. Takes as input the mode - if the mode is pause the adapter will queue the requests if it is anything else requests will be rejected.
223
+
224
+ #### Input Parameters
225
+ Mode - whether you want the adapter to pause (queue requests) or do nothing (reject all requests)
226
+
227
+ #### Operation Flow
228
+ The utility puts the adapter in a suspended state meaning the adapter will no longer send anything to the external system. This is useful if we know that the external system will be down for maintenance as instead of failing any requests, the adapter can queue requests and send them once the adapter resumes (e.g. is unsuspended). These reequests are stored in the adapter memory so subsequently restarting the adapter will remove all of the items in the queue.
229
+
230
+ #### Output
231
+ The state of the adapter is changed.
232
+
233
+ #### Best Practices
234
+ 1. Run when:
235
+ - The external system will be unavailable for some reason (e.g. it is under maintenance)
236
+
237
+ ### Unsuspend Adapter
238
+ - **IP Workflow**: iapUnsuspendAdapter
239
+ - **CLI**: N/A
240
+
241
+ This utility provides the ability for an adapter to be made active from a suspended state. If requests were being queued, the adapter will start working down the queue. There is no input required for this call.
242
+
243
+ #### Input Parameters
244
+ There is no input for this call.
245
+
246
+ #### Operation Flow
247
+ The utility will unsuspend (make active) an adapter that has been suspended. When the adapter resumes, if it was paused and queueing requests, the adapter will work down the queue in order to complete all of the requests that had been submitted.
248
+
249
+ #### Output
250
+ The state of the adapter is changed.
251
+
252
+ #### Best Practices
253
+ 1. Run when:
254
+ - An adapter was suspended and the external system is available again
255
+
256
+ ### Move Adapter Entities To DB
257
+ - **IP Workflow**: iapMoveAdapterEntitiesToDB
258
+ - **CLI**: N/A
259
+
260
+ This utility was created explicitly for SaaS environments. It provides the mechanism to move the adapter endpoint configurations from the entities directory on the file system into a database. The advantage of doing this was so that changes could be made to the adapter endpoint configuration that would persist when the SaaS IP instance was updated or reloaded. There is no input required for this call.
261
+
262
+ #### Requirements and Prerequisites
263
+ - MongoDB connection configuration in the adapter properties
264
+ - Valid database permissions to create and write documents
265
+ - Proper MongoDB URL format or individual connection properties
266
+
267
+ #### Configuration Options
268
+ The utility supports two ways to configure the MongoDB connection:
269
+ 1. **URL-based connection**: Using a complete MongoDB URL
270
+ ```json
271
+ {
272
+ "mongo": {
273
+ "url": "mongodb://hostname:port/database"
274
+ }
275
+ }
276
+ ```
277
+
278
+ 2. **Individual properties**: Using separate connection parameters
279
+ ```json
280
+ {
281
+ "mongo": {
282
+ "host": "hostname",
283
+ "port": 27017,
284
+ "database": "dbname",
285
+ "username": "user",
286
+ "password": "pass"
287
+ }
288
+ }
289
+ ```
290
+
291
+ #### Additional Features
292
+ - **Database Override**: Can override the database name specified in the URL
293
+ - **SSL Support**: Supports SSL/TLS connections with options for:
294
+ - Certificate validation
295
+ - Custom CA certificates
296
+ - Client certificates
297
+ - **Authentication**: Supports various MongoDB authentication mechanisms
298
+ - **Replica Sets**: Supports MongoDB replica set configurations
299
+
300
+ #### Input Parameters
301
+ There is no input for this call.
302
+
303
+ #### Operation Flow
304
+ 1. The utility will automatically:
305
+ - Read all entities from the filesystem
306
+ - Convert them to the appropriate format
307
+ - Insert them into the specified MongoDB collection
308
+ 2. Existing documents with the same ID will be overwritten
309
+ 3. The operation is atomic - all entities are moved together
310
+ 4. Backup your filesystem entities before running this utility
311
+
312
+ #### Output
313
+ Report whether the moving of the adapter endpoint configuration to the database was successful.
314
+
315
+ #### Error Handling
316
+ The utility handles various error scenarios:
317
+ - Missing connection properties
318
+ - Invalid URL format
319
+ - Authentication failures
320
+ - Connection timeouts
321
+ - Database write errors
322
+
323
+ #### Best Practices
324
+ 1. Always backup configurations before updates
325
+ 2. Test changes in non-production environment
326
+ 3. Run when you need to make changes to the adapter endpoint configuration and do not have access to the Itential Platform Server to be able to make changes in the file system or if you are in the Itential SaaS environment and want to persist your adapter endpoint configuration changes.
327
+ 4. In SaaS it is recommended that you review this with Itential Cloud Ops and the Adapter Team prior to using.
328
+
329
+ ### Update Adapter Configuration
330
+ - **IP Workflow**: iapUpdateAdapterConfiguration
331
+ - **CLI**: N/A
332
+
333
+ This utility was created so that customers would not have to make modifications directly into the adapter files on the file system. It was originally built to work on the file system files but was extended to work in the instance when the adapter configuration had been moved to the database as well. This method takes in a lot of information include the name of the config file, the changes, entity and action information as well as a flag to determine whether it is to be appended to contents or replacement for contents.
334
+
335
+ #### Requirements and Prerequisites
336
+ - Valid entity path in the filesystem (required for all updates except package.json)
337
+ - Proper filesystem permissions to modify files
338
+ - Valid configuration changes that conform to expected schemas
339
+ - MongoDB connection configuration (optional, for database synchronization)
340
+
341
+ #### Configuration Options
342
+ The utility supports four types of configuration updates:
343
+
344
+ 1. **Package Updates** (Dependencies Only)
345
+ ```json
346
+ {
347
+ "configFile": "package.json",
348
+ "changes": {
349
+ "dependencies": {
350
+ "package-name": "version"
351
+ }
352
+ }
353
+ }
354
+ ```
355
+ Note: Only package dependencies can be updated. Other package.json fields cannot be modified.
356
+ The adapter will automatically restart after package dependency updates.
357
+
358
+ 2. **Action Updates**
359
+ ```json
360
+ {
361
+ "configFile": "action.json",
362
+ "changes": {
363
+ "name": "actionName",
364
+ "method": "GET",
365
+ "entitypath": "/api/path"
366
+ },
367
+ "entity": "entityName",
368
+ "type": "action",
369
+ "action": "specificAction"
370
+ }
371
+ ```
372
+ Note: The action file must exist in the entity directory.
373
+
374
+ 3. **Schema Updates**
375
+ ```json
376
+ {
377
+ "configFile": "schema.json",
378
+ "changes": {
379
+ "type": "object",
380
+ "properties": {}
381
+ },
382
+ "entity": "entityName",
383
+ "type": "schema"
384
+ }
385
+ ```
386
+ Note: The schema file must exist in the entity directory.
387
+
388
+ 4. **Mock Data Updates**
389
+ ```json
390
+ {
391
+ "configFile": "mockData.json",
392
+ "changes": {
393
+ "key": "value"
394
+ },
395
+ "entity": "entityName",
396
+ "type": "mock",
397
+ "replace": false
398
+ }
399
+ ```
400
+ Note: If the mock data directory doesn't exist, it will be created.
401
+
402
+ #### Input Parameters
403
+ - `configFile`: (Required) Name of the file to update
404
+ - `changes`: (Required) Object containing the modifications
405
+ - `entity`: (Required for action/schema/mock updates) Target entity name
406
+ - `type`: (Required for action/schema/mock updates) Type of update ("action", "schema", or "mock")
407
+ - `action`: (Required for action updates) Specific action name
408
+ - `replace`: (Required for mock updates) Boolean flag for replacing or merging data
409
+
410
+ #### Operation Flow
411
+ 1. For package.json updates:
412
+ - Validates changes contain only dependencies
413
+ - Updates dependencies
414
+ - Restarts adapter
415
+
416
+ 2. For entity-based updates:
417
+ - Validates entity exists in filesystem
418
+ - Validates required parameters based on type
419
+ - Updates filesystem files
420
+ - If MongoDB is configured:
421
+ - Attempts to synchronize changes to database
422
+ - Maintains existing document structure
423
+ - Logs any database operation failures
424
+
425
+ #### Output
426
+ Report whether the configuration changes were successful.
427
+
428
+ #### Error Handling
429
+ The utility returns errors for:
430
+ - Missing required parameters
431
+ - Non-existent entities
432
+ - Missing configuration files (except for mock data)
433
+ - Invalid file types
434
+ - File system permission issues
435
+ - MongoDB synchronization failures (non-blocking)
436
+
437
+ #### Best Practices
438
+ 1. Always backup configurations before updates
439
+ 2. Test changes in non-production environment
440
+ 3. For mock data:
441
+ - Use replace=false to merge changes
442
+ - Use replace=true to overwrite entirely
443
+ 4. Monitor logs for both filesystem and MongoDB operation results
444
+ 5. Expect adapter restart after package dependency updates
445
+
446
+
447
+ ## Adapter Support Utilities
448
+
449
+ ### Check Migration Eligible
450
+ - **CLI**: node utils/checkMigrate.js
451
+
452
+ This utility determines three things:
453
+ 1. Whether the adapter needs to be migrated to the latest adapter foundation. It compares the local adapter-engine version with the latest.
454
+ 2. Whether a new adapter version needs to be pulled, it compares the current adapter version with the latest.
455
+ 3. Whether remediation is needed, it compares the local adapter-utils version with the latest.
456
+ There is no input required for this call.
457
+
458
+ #### Input Parameters
459
+ There is no input for this call.
460
+
461
+ #### Operation Flow
462
+ The utility checks the state of the adapter to see if it is up to date:
463
+ 1. **Adapter Test**: Validates that the adapter being used is the latest instance of the open source adapter. If it is out of date, it could be missing calls, capabilities, fixes, have vulnerabilities, etc.
464
+ 2. **Migration Test**: Validates that the adapter foundation is up to date. This means that it has the ability to perform any and all capabilities that are available in the adapter foundation. Could also address security vulnerabilities that have been reported and fixed.
465
+ 3. **Renmediation Test**: Validates that the adapter is on the latest adapter-utils version. This means that it has the ability to perform any and all capabilities that are available in the adapter foundation. Could also address bug fixes and security vulnerabilities that have been reported and fixed.
466
+
467
+ #### Output
468
+ Will report if adapter update, migration or remediation are needed.
469
+
470
+ #### Best Practices
471
+ 1. Run periodically or when you are having issues with an adapter to verify that you are staying up to date.
472
+ 2. Review the results
473
+ 3. There is little to no use for this in SaaS as adapters are kept up to date each month during their release cycles so at most they are <30 days out of date.
package/adapter.js CHANGED
@@ -198,16 +198,15 @@ class MicrosoftGraph extends AdapterBaseCl {
198
198
  * @function iapTroubleshootAdapter
199
199
  * @param {Object} props - the connection, healthcheck and authentication properties
200
200
  *
201
- * @param {boolean} persistFlag - whether the adapter properties should be updated
202
201
  * @param {Callback} callback - The results of the call
203
202
  */
204
- iapTroubleshootAdapter(props, persistFlag, callback) {
203
+ iapTroubleshootAdapter(props, callback) {
205
204
  const meth = 'adapter-iapTroubleshootAdapter';
206
205
  const origin = `${this.id}-${meth}`;
207
206
  log.trace(origin);
208
207
 
209
208
  try {
210
- return super.iapTroubleshootAdapter(props, persistFlag, this, callback);
209
+ return super.iapTroubleshootAdapter(props, this, callback);
211
210
  } catch (error) {
212
211
  log.error(`${origin}: ${error}`);
213
212
  return callback(null, error);
@@ -257,15 +256,16 @@ class MicrosoftGraph extends AdapterBaseCl {
257
256
  * @summary runs basicGet script for adapter
258
257
  *
259
258
  * @function iapRunAdapterBasicGet
259
+ * @param {number} maxCalls - how many GET endpoints to test (optional)
260
260
  * @param {Callback} callback - callback function
261
261
  */
262
- iapRunAdapterBasicGet(callback) {
262
+ iapRunAdapterBasicGet(maxCalls, callback) {
263
263
  const meth = 'adapter-iapRunAdapterBasicGet';
264
264
  const origin = `${this.id}-${meth}`;
265
265
  log.trace(origin);
266
266
 
267
267
  try {
268
- return super.iapRunAdapterBasicGet(callback);
268
+ return super.iapRunAdapterBasicGet(maxCalls, callback);
269
269
  } catch (error) {
270
270
  log.error(`${origin}: ${error}`);
271
271
  return callback(null, error);
package/adapterBase.js CHANGED
@@ -32,6 +32,7 @@ const entitiesToDB = require(path.join(__dirname, 'utils/entitiesToDB'));
32
32
  const troubleshootingAdapter = require(path.join(__dirname, 'utils/troubleshootingAdapter'));
33
33
  const tbUtils = require(path.join(__dirname, 'utils/tbUtils'));
34
34
  const taskMover = require(path.join(__dirname, 'utils/taskMover'));
35
+ const { updateMongoDBConfig } = require(path.join(__dirname, 'utils/updateAdapterConfig'));
35
36
 
36
37
  let propUtil = null;
37
38
  let choosepath = null;
@@ -366,7 +367,6 @@ class AdapterBase extends EventEmitterCl {
366
367
  // if we were healthy, toggle health
367
368
  if (this.healthy) {
368
369
  this.emit('OFFLINE', { id: this.id });
369
- this.emit('DEGRADED', { id: this.id });
370
370
  this.healthy = false;
371
371
  if (typeof error === 'object') {
372
372
  log.error(`${origin}: HEALTH CHECK - Error ${JSON.stringify(error)}`);
@@ -385,7 +385,6 @@ class AdapterBase extends EventEmitterCl {
385
385
 
386
386
  // if we were unhealthy, toggle health
387
387
  if (!this.healthy) {
388
- this.emit('FIXED', { id: this.id });
389
388
  this.emit('ONLINE', { id: this.id });
390
389
  this.healthy = true;
391
390
  log.info(`${origin}: HEALTH CHECK SUCCESSFUL`);
@@ -583,21 +582,32 @@ class AdapterBase extends EventEmitterCl {
583
582
 
584
583
  // take action based on type of file being changed
585
584
  if (type === 'action') {
586
- // BACKUP???
587
585
  const ares = updateAction(epath, action, changes);
588
586
  if (ares) {
589
587
  const errorObj = this.requestHandlerInst.formatErrorObject(this.id, meth, `Incomplete Configuration Change: ${ares}`, [], null, null, null);
590
588
  log.error(`${origin}: ${errorObj.IAPerror.displayString}`);
591
589
  return callback(null, errorObj);
592
590
  }
593
- // AJV CHECK???
594
- // RESTORE IF NEEDED???
591
+ // Update MongoDB if possible
592
+ updateMongoDBConfig({
593
+ id: this.id,
594
+ mongoProps: this.allProps.mongo,
595
+ entity,
596
+ type,
597
+ configFile,
598
+ changes,
599
+ action,
600
+ replace
601
+ }).catch((error) => {
602
+ log.error(`${origin}: Error updating MongoDB configuration: ${error.message}`);
603
+ });
595
604
  const result = {
596
605
  response: `Action updates completed to entity: ${entity} - ${action}`
597
606
  };
598
607
  log.info(result.response);
599
608
  return callback(result, null);
600
609
  }
610
+
601
611
  if (type === 'schema') {
602
612
  const sres = updateSchema(epath, configFile, changes);
603
613
  if (sres) {
@@ -605,12 +615,26 @@ class AdapterBase extends EventEmitterCl {
605
615
  log.error(`${origin}: ${errorObj.IAPerror.displayString}`);
606
616
  return callback(null, errorObj);
607
617
  }
618
+ // Update MongoDB if possible
619
+ updateMongoDBConfig({
620
+ id: this.id,
621
+ mongoProps: this.allProps.mongo,
622
+ entity,
623
+ type,
624
+ configFile,
625
+ changes,
626
+ action,
627
+ replace
628
+ }).catch((error) => {
629
+ log.error(`${origin}: Error updating MongoDB configuration: ${error.message}`);
630
+ });
608
631
  const result = {
609
632
  response: `Schema updates completed to entity: ${entity} - ${configFile}`
610
633
  };
611
634
  log.info(result.response);
612
635
  return callback(result, null);
613
636
  }
637
+
614
638
  if (type === 'mock') {
615
639
  // if the mock directory does not exist - error
616
640
  const mpath = `${__dirname}/entities/${entity}/mockdatafiles`;
@@ -624,18 +648,31 @@ class AdapterBase extends EventEmitterCl {
624
648
  return callback(null, errorObj);
625
649
  }
626
650
  const mres = updateMock(mpath, configFile, changes, replace);
627
-
628
651
  if (mres) {
629
652
  const errorObj = this.requestHandlerInst.formatErrorObject(this.id, meth, `Incomplete Configuration Change: ${mres}`, [], null, null, null);
630
653
  log.error(`${origin}: ${errorObj.IAPerror.displayString}`);
631
654
  return callback(null, errorObj);
632
655
  }
656
+ // Update MongoDB if possible
657
+ updateMongoDBConfig({
658
+ id: this.id,
659
+ mongoProps: this.allProps.mongo,
660
+ entity,
661
+ type,
662
+ configFile,
663
+ changes,
664
+ action,
665
+ replace
666
+ }).catch((error) => {
667
+ log.error(`${origin}: Error updating MongoDB configuration: ${error.message}`);
668
+ });
633
669
  const result = {
634
670
  response: `Mock data updates completed to entity: ${entity} - ${configFile}`
635
671
  };
636
672
  log.info(result.response);
637
673
  return callback(result, null);
638
674
  }
675
+
639
676
  const errorObj = this.requestHandlerInst.formatErrorObject(this.id, meth, `Incomplete Configuration Change: Unsupported Type - ${type}`, [], null, null, null);
640
677
  log.error(`${origin}: ${errorObj.IAPerror.displayString}`);
641
678
  return callback(null, errorObj);
@@ -831,14 +868,13 @@ class AdapterBase extends EventEmitterCl {
831
868
  *
832
869
  * @function iapTroubleshootAdapter
833
870
  * @param {Object} props - the connection, healthcheck and authentication properties
834
- * @param {boolean} persistFlag - whether the adapter properties should be updated
835
871
  * @param {Adapter} adapter - adapter instance to troubleshoot
836
872
  * @param {Callback} callback - callback function to return troubleshoot results
837
873
  */
838
- async iapTroubleshootAdapter(props, persistFlag, adapter, callback) {
874
+ async iapTroubleshootAdapter(props, adapter, callback) {
839
875
  try {
840
- const result = await troubleshootingAdapter.troubleshoot(props, false, persistFlag, adapter);
841
- if (result.healthCheck && result.connectivity.failCount === 0 && result.basicGet.failCount === 0) {
876
+ const result = await troubleshootingAdapter.troubleshoot(props, false, adapter);
877
+ if (result.healthCheck && result.connectivity.failCount === 0 && result.basicGet.passCount !== 0) {
842
878
  return callback(result);
843
879
  }
844
880
  return callback(null, result);
@@ -875,8 +911,7 @@ class AdapterBase extends EventEmitterCl {
875
911
  */
876
912
  async iapRunAdapterConnectivity(callback) {
877
913
  try {
878
- const { host } = this.allProps;
879
- const result = tbUtils.runConnectivity(host, false);
914
+ const result = tbUtils.runConnectivity(this.allProps.host, false);
880
915
  if (result.failCount > 0) {
881
916
  return callback(null, result);
882
917
  }
@@ -890,12 +925,13 @@ class AdapterBase extends EventEmitterCl {
890
925
  * @summary runs basicGet script for adapter
891
926
  *
892
927
  * @function iapRunAdapterBasicGet
928
+ * @param {number} maxCalls - how many GETs to run (optional)
893
929
  * @param {Callback} callback - callback function to return basicGet result
894
930
  */
895
- iapRunAdapterBasicGet(callback) {
931
+ iapRunAdapterBasicGet(maxCalls, callback) {
896
932
  try {
897
- const result = tbUtils.runBasicGet(false);
898
- if (result.failCount > 0) {
933
+ const result = tbUtils.runBasicGet(this.allProps, false, maxCalls);
934
+ if (result.passCount === 0) {
899
935
  return callback(null, result);
900
936
  }
901
937
  return callback(result);
@@ -917,7 +953,7 @@ class AdapterBase extends EventEmitterCl {
917
953
  log.trace(origin);
918
954
 
919
955
  try {
920
- const result = await entitiesToDB.moveEntitiesToDB(__dirname, { pronghornProps: this.allProps, id: this.id });
956
+ const result = await entitiesToDB.moveEntitiesToDB(__dirname, { pronghornProps: { mongo: this.allProps && this.allProps.mongo }, id: this.id });
921
957
  return callback(result, null);
922
958
  } catch (err) {
923
959
  const errorObj = this.requestHandlerInst.formatErrorObject(this.id, meth, 'Caught Exception', null, null, null, err);