@itentialopensource/adapter-nokia_altiplano 0.2.0 → 0.5.0

package/CHANGELOG.md

@@ -1,4 +1,28 @@
 
+## 0.5.0 [05-02-2022]
+
+* Add calls for ema entity
+
+See merge request itentialopensource/adapters/controller-orchestrator/adapter-nokia_altiplano!6
+
+---
+
+## 0.4.0 [03-30-2022]
+
+* added ibn intent calls
+
+See merge request itentialopensource/adapters/controller-orchestrator/adapter-nokia_altiplano!5
+
+---
+
+## 0.3.0 [03-25-2022]
+
+* add new call createOntWithQuery
+
+See merge request itentialopensource/adapters/controller-orchestrator/adapter-nokia_altiplano!4
+
+---
+
 ## 0.2.0 [03-18-2022]
 
 * Migration and creation of md files

package/ENHANCE.md

@@ -1,10 +1,10 @@
-## Extending/Enhancing the Adapter
+### Enhancements
 
-### Adding a Second Instance of an Adapter
+#### Adding a Second Instance of an Adapter
 
 You can add a second instance of this adapter without adding new code on the file system. To do this go into the IAP Admin Essentials and add a new service config for this adapter. The two instances of the adapter should have unique ids. In addition, they should point to different instances of the other system. For example, they should be configured to talk to different hosts.
 
-### Adding Adapter Calls
+#### Adding Adapter Calls
 
 There are multiple ways to add calls to an existing adapter.
 
@@ -30,7 +30,7 @@ Files to update
 * test/integration/adapterTestIntegration.js (optional but best practice): add integration test
 ```
 
-### Adding Adapter Properties
+#### Adding Adapter Properties
 
 While changing adapter properties is done in the service instance configuration section of IAP, adding properties has to be done in the adapter. To add a property you should edit the propertiesSchema.json with the proper information for the property. In addition, you should modify the sampleProperties to have the new property in it.
 
@@ -42,7 +42,7 @@ Files to update
 * test/integration/adapterTestIntegration.js (optional but best practice): add the property to the global properties
 ```
 
-### Changing Adapter Authentication
+#### Changing Adapter Authentication
 
 Often an adapter is built before knowing the authentication and authentication process can also change over time. The adapter supports many different kinds of authentication but it does require configuration. Some forms of authentication can be defined entirely with the adapter properties but others require configuration.
 
@@ -57,7 +57,7 @@ Files to update
 * test/integration/adapterTestIntegration.js (optional but best practice): add the property to the global properties
 ```
 
-### Enhancing Adapter Integration Tests
+#### Enhancing Adapter Integration Tests
 
 The adapter integration tests are written to be able to test in either stub (standalone) mode or integrated to the other system. However, if integrating to the other system, you may need to provide better data than what the adapter provides by default as that data is likely to fail for create and update. To provide better data, edit the adapter integration test file. Make sure you do not remove the marker and keep custom code below the marker so you do not impact future migrations. Once the edits are complete, run the integration test as it instructs you to above. When you run integrated to the other system, you can also save mockdata for future use by changing the isSaveMockData flag to true.
 

package/PROPERTIES.md

@@ -1,6 +1,6 @@
-## Adapter Properties and Descriptions
+## Configuration
 
-This section defines **all** the properties that are available for the adapter, including detailed information on what each property is for. If you are not using certain capabilities with this adapter, you do not need to define all of the properties. An example of how the properties for this adapter can be used with tests or IAP are provided in the **Installation** section.
+This section defines **all** the properties that are available for the adapter, including detailed information on what each property is for. If you are not using certain capabilities with this adapter, you do not need to define all of the properties. An example of how the properties for this adapter can be used with tests or IAP are provided in the sampleProperties.
 
 ```json
   {
@@ -25,7 +25,10 @@ This section defines **all** the properties that are available for the adapter,
         "token_cache": "local",
         "auth_field": "header.headers.X-AUTH-TOKEN",
         "auth_field_format": "{token}",
-        "auth_logging": false
+        "auth_logging": false,
+        "client_id": "",
+        "client_secret": "",
+        "grant_type": ""
       },
       "healthcheck": {
         "type": "startup",
@@ -133,6 +136,9 @@ The following properties are used to define the authentication process to Nokia_
 | auth\_field | Defines the request field the authentication (e.g., token are basic auth credentials) needs to be placed in order for the calls to work.|
 | auth\_field\_format | Defines the format of the auth\_field. See examples below. Items enclosed in {} inform the adapter to perofrm an action prior to sending the data. It may be to replace the item with a value or it may be to encode the item. |
 | auth\_logging | Setting this true will add some additional logs but this should only be done when trying to debug an issue as certain credential information may be logged out when this is true. |
+| client\_id | Provide a client id when needed, this is common on some types of OAuth. |
+| client\_secret | Provide a client secret when needed, this is common on some types of OAuth. |
+| grant\_type | Provide a grant type when needed, this is common on some types of OAuth. |
 
 #### Examples of authentication field format