Initially you can quickly open up every field in the web services so that we can define what we require and see all of your available current data.
Moving forward we will advise how to refine the services down to
just the data that is required, which will be less resource intensive.
We look at the ability to filter the data request so that we can
pull data faster. For example, updating products normally falls in to
three scenarios:
- No filtering - If
your Dynamics Nav WS page doesn't support a filter then we would need to pull all
of the data and loop through, this is memory and time consuming and
therefore would be run less frequently, normally around twice per day.
- Filtering available
- Dynamics Nav WS will support filtering, meaning that we can specify
changes in the last X hours for example. This kind of update can be run
more frequently as the level of data to be processed will be a lot
lower. Normally this kind of service would be run every hour, or as fast
as every 5 minutes.
- Web Hook - If your Dynamics Nav system
supports it, we can give a web hook location. Nav can then notify our
system as soon as a product is updated. In turn we can then request the
data for the changed product and update the web system. This is the
closest to a real time update as after saving in Nav the subsequent
calls and updates would normally execute within 30 seconds. However it
does require the extra setup of the notification web hook in Nav.
In
terms of the direct sql method in Dynamics Nav, we advise against this due to the ability to directly affect the core data in
Nav. In addition to this if Nav has any processes or validity checking on data import
these processes would not be used with the direct sql method. Using the
Web Services page to import orders you benefit from all of the normal
data validation Nav requires to build the orders and reduces the risk of
it affecting the core Microsoft Dynamics Nav system.
| 