The default implementation processScanRequest() does nothing. It is a placeholder function in the SDK provided as a suggestion for a function you can implement if you want to generate data by polling some resource. The SDK will never call processScanRequest() in response to anything. It is the edge developer's job to both implement and call this function periodically if they want to produce or sample data on a schedule.
If you turn off the caching your property will be explicitly fetched by the server through a service call. It is a pull request originating from the server. No action on your part is required as a developer beyond binding your VirtualThing to a client.
Thank you for your answer.
Yes, in my question I took for granted that a classical developer implementation of processScanRequest() would contain the invocation of updateSubscribedProperties() at the end of the method to send the property updates to the platform.
However this does not really answer my question. This "pull request" seems to be an internal Thingworx message and it doesn't appear to be any documentation about its external behaviour. What value does this "pull request" message retrieve?
If "pull request" method does not invoke processScanRequest then it must necessarily retrieve the last collected property value that is cached inside the device, without executing any logic to retrieve the CURRENT values from the I/O of the physical device. Is it correct?
Another point is: what happens if I set the folded property=false? Then, inside the device, there must necessarily be is a local "queue" of all the "property updates" that are not sent yet to the ThingWorx platform. Does the "pull request" message trigger the sending of all the device-local queued updates to the platform? This would anticipate the invocation of updateSubscribedProperties(), overriding the implementation decisions that the user has taken when implementing the processScanRequests().
In order to make sure I answer all your questions, I will restate them and then answer them
1. What value does a pull request from the server receive if I have disabled caching for a property?
A pull request from the server retrieves the current remote VirtualThing state. This state is independent of any pushed values that are being delivered to the server via a call to updateSubscribedProperties(), either folded or not. Think of the property values you are pushing as a queue of updates, each with a timestamp. These property changes are delivered to the server and applied to the current property value in the cache in the order their timestamps say they should be. The result of all these property changes are stored in the server cache. A property of a Thing on the server will either consult the cache for this value or it will ignore it and make a call over your edge connection to get the latest value, completely bypassing the cached value, if you configure it to disable caching.
2. If a "pull request" method does not invoke processScanRequest() then how does it get the current values from an actual physical device?
There are two ways you can get data from a physical device. You can poll it periodically (processScanRequest()) or it can deliver data when it arrives via an interrupt or an asynchronous message when it has received an update. Either way, when new data arrives, you must store it in your VirtualThing on the device the hardware is attached to as a property value. If this change is significant, you can choose to record the value change immediately by calling updateSubscribedProperties() at the time the value changes. If folded, your change is recorded but not necessarily delivered to the server right away.
Your VirtualThing on your edge device contains in it a map of property names and current values which reflects its current state. It is also recording and forwarding changes to that state when you call updateSubscribedProperties() to the server so that the current value in the cache can be in sync with the remote state. It can also log these changes to a ValueStream on the server for use in historical mashups.
When you perform a "pull request", you bypass the server cached value and make a remote request to the getProperty() function of the remote VirtualThing for each property that is configured to not use cached values. As you can imagine, doing this too often can create a performance issue for your mashup because obtaining these values is a function of how long it takes to make multiple remote service calls, each representing a round trip over the network to your remote device. If you want to trigger a request to your hardware to collect data in response to when the server requests a property, you can also override the processPropertyRead() function in your VirtualThing. This function will be called right before getProperty() and would give you an opportunity to update the property value before it gets read. Note that the default implementation of processPropertyRead() does nothing.
I hope this answers your questions. Understanding the mechanisms at work in edge connectivity, server state, remote state, property change events and how the cache works to improve mashup performance, are very important to the design decisions a developer has to make when implementing a solution with our Edge SDKs.
If you are using the C-SDK and you have registered a property callback, and there is no cache set in the server for that property (Fetched From Remote Every Read is set for that property), then the value returned by the device (as the answer to a pull request from the ThingWorx Platform server) is whatever value the property callback returned.