|
| 1 | + # Change log |
| 2 | + |
| 3 | + ## What's new |
| 4 | + |
| 5 | + ### Better ID references |
| 6 | + |
| 7 | + #### The problem |
| 8 | + Many APIM resources reference others through IDs. For example, here is a diagnostic that references a logger through the `loggerId` property: |
| 9 | + ```json |
| 10 | + { |
| 11 | + "properties": { |
| 12 | + ... |
| 13 | + "loggerId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg1/providers/Microsoft.ApiManagement/service/apimService1/loggers/azuremonitor" |
| 14 | + ... |
| 15 | + } |
| 16 | +} |
| 17 | + ``` |
| 18 | + |
| 19 | +If we publish this diagnostic as-is to another APIM instance, the publisher will fail. The logger reference is specific to APIM instance `apimService1` in resource group `rg1` and subscription `00000000-0000-0000-0000-000000000000`. To work around this, we have to edit the JSON or override the publisher configuration to reference the new APIM instance. |
| 20 | + |
| 21 | +#### The solution |
| 22 | +Going forward, the extractor will use relative references where possible. In the above scenario, it will write `loggerId: "/loggers/azuremonitor"`. This relative reference will work when publishing across instances. |
| 23 | + |
| 24 | +> [!NOTE] |
| 25 | +> This change was manually implemented across resources. We're not aware of a way to ask the APIM REST API to return relative references. Some resources may have been missed. If you'd like to request that we add a missed resource, please raise an issue. |
| 26 | +
|
| 27 | + ### Nested configuration |
| 28 | +We now support nested levels of configuration for the extractor and publisher. This allows the configuration of child resources (e.g. api operations, workspace api diagnostics, etc). |
| 29 | + |
| 30 | +#### Sample extractor configuration |
| 31 | +Only operations 1 and 2 will be extracted in api 1. All operations in api 2 will be extracted. |
| 32 | +```yaml |
| 33 | +apis: |
| 34 | +- api1: |
| 35 | + operations: |
| 36 | + - operation1 |
| 37 | + - operation2 |
| 38 | +- api2 |
| 39 | +... |
| 40 | +``` |
| 41 | + |
| 42 | +#### Sample publisher configuration |
| 43 | +The display name of diagnostic 3 in api 2 in workspace 1 will be overriden with `my display name`. |
| 44 | +```yaml |
| 45 | +workspaces: |
| 46 | +- workspace1: |
| 47 | + apis: |
| 48 | + - api2: |
| 49 | + diagnostics: |
| 50 | + - diagnostic3: |
| 51 | + properties: |
| 52 | + displayName: my display name |
| 53 | +... |
| 54 | +``` |
| 55 | + |
| 56 | +### Empty configuration in extractor |
| 57 | + |
| 58 | +Previously, if we wanted to skip extracting all resources of a type, we had to put a random placeholder value (e.g. `ignore`). We now support the more intuitive `[]`. |
| 59 | + |
| 60 | +#### Before |
| 61 | +```yaml |
| 62 | +apis: ignore # Workaround to skip extracting all APIs. |
| 63 | +``` |
| 64 | +
|
| 65 | +#### After |
| 66 | +````yaml |
| 67 | +apis: [] # All APIs will be skipped. |
| 68 | +```` |
| 69 | +
|
| 70 | +## Breaking changes |
| 71 | +### New section names in extractor configuration |
| 72 | +We've made the section names in the extractor and publisher identical. This provides a more consistent experience and greatly simplifies code maintenance. |
| 73 | +#### Before (extractor configuration) |
| 74 | +```yaml |
| 75 | +apiNames: |
| 76 | +- api1 |
| 77 | +- api2 |
| 78 | +productNames: |
| 79 | +- product1 |
| 80 | +- product2 |
| 81 | +``` |
| 82 | +#### After (extractor configuration) |
| 83 | +```yaml |
| 84 | +apis: |
| 85 | +- api1 |
| 86 | +- api2 |
| 87 | +products: |
| 88 | +- product1 |
| 89 | +- product2 |
| 90 | +``` |
0 commit comments