You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/iot-dps/concepts-custom-allocation.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -188,7 +188,7 @@ For the TPM registration request in the previous section, the device runtime con
188
188
}
189
189
```
190
190
191
-
If this isn't the initial registration for the device then the runtime context will also include the **currentIoTHubHostname** and the **currentDeviceId** properties.
191
+
If this isn't the initial registration for the device, then the runtime context will also include the **currentIoTHubHostname** and the **currentDeviceId** properties.
192
192
193
193
### Custom allocation webhook returns data to DPS
194
194
@@ -249,7 +249,7 @@ The following points describe the requirements that your custom allocation webho
249
249
250
250
* On initial assignment, if the **initialTwin** property is returned by the webhook, DPS will set the initial twin for the device on the assigned IoT hub accordingly. If the **initialTwin** property is omitted or is **null**, DPS sets the initial twin for the device to the initial twin setting specified in the enrollment entry.
251
251
252
-
* On reprovsioning, DPS follows the reprovisioning policy set in the enrollment entry. DPS only uses **initialTwin** property in the response if the current IoT hub is changed and the reprovisioning policy set on the enrollment entry is *Re-provision and reset to initial config*. In this case, DPS sets the initial twin for the device on the new IoT hub exactly as it would during initial assignment in the previous bullet. In all other cases, DPS ignores the **initialTwin** property.
252
+
* On reprovisioning, DPS follows the reprovisioning policy set in the enrollment entry. DPS only uses **initialTwin** property in the response if the current IoT hub is changed and the reprovisioning policy set on the enrollment entry is *Re-provision and reset to initial config*. In this case, DPS sets the initial twin for the device on the new IoT hub exactly as it would during initial assignment in the previous bullet. In all other cases, DPS ignores the **initialTwin** property.
253
253
254
254
* If the **payload** property is set in the response, DPS will always return it to the device regardless of whether the request is for initial assignment or reprovisioning.
255
255
@@ -268,7 +268,7 @@ The following points describe the requirements that your custom allocation webho
268
268
269
269
The DPS device SDKs provide APIs in C, C#, Java, and Node.js to help you register devices with DPS. Both the IoT Hub SDKs and the DPS SDKs provide classes that represent device and service artifacts like device twins and enrollment entries that might be helpful when developing custom allocation webhooks. To learn more about the Azure IoT SDKs available for IoT Hub and IoT Hub Device Provisioning service, see [Azure IoT Hub SDKs](../iot-hub/iot-hub-devguide-sdks.md) and [Azure DPS SDKs](./libraries-sdks.md).
270
270
271
-
## Next Steps
271
+
## Next steps
272
272
273
273
* For an end-to-end example using a custom allocation policy, see [Use custom allocation policies](tutorial-custom-allocation-policies.md)
Copy file name to clipboardExpand all lines: articles/iot-dps/tutorial-custom-allocation-policies.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -145,7 +145,7 @@ In this section, you create an Azure function that implements your custom alloca
145
145
146
146
5. On the left pane of the function app **Overview** page, select **Functions** and then **+ Create** to add a new function.
147
147
148
-
6. On the **Create function** page, make sure that **Development environment** is set to **Develop in portal**. Then se;ect the **HTTP Trigger** template followed by the **Create** button.
148
+
6. On the **Create function** page, make sure that **Development environment** is set to **Develop in portal**. Then select the **HTTP Trigger** template followed by the **Create** button.
149
149
150
150
7. When the **HttpTrigger1** function opens, select **Code + Test** on the left pane. This allows you to edit the code for the function. The **run.csx** code file should be opened for editing.
To use the sample with a private endpoint, the highlighted code above would be changed to use the service endpoint for your DPS resource. For example, if you service endpoint was `mydps.azure-devices-provisioning.net`, the code would look as follows.
131
+
To use the sample with a private endpoint, the highlighted code above would be changed to use the service endpoint for your DPS resource. For example, if your service endpoint was `mydps.azure-devices-provisioning.net`, the code would look as follows.
0 commit comments