<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=440810&amp;fmt=gif">

Major MS Dynamics NAV Web Service Connector Upgrade

By Michael Bock - March 03, 2016

We are very pleased to announce that we have done a major update of our MS Dynamics NAV Web service support including brand new features like a one-step Sales Order creation, support for Codeunit Web services and in general better error handling.

As many of you - our valued customers - now are using the MS Dynamics NAV Web services in your integrations with MS Dynamics NAV, we found that is was time to give this module a major update. Based on your feedback we have added some exciting new features.

New feature: Create MS Dynamics NAV Sales Orders in one step (one transfer)

We have now build support for Sales Order creation into our MS Dynamics NAV Web Service Connector. This special support will recognice that you want to create a new Sales Order in MS Dynamics NAV and from just one single Transfer, where you map both header and lines with all the needed fields, the Connector will do the above listed three steps and create a new complete Sales Order in MS Dynamics NAV !

Please read this post  'MS Dynamics NAV Sales Order Using Web Services Made Simple' on a more detailed description of this feature.

DBLookup support added to MS Dynamics NAV Web Services Connector

You can now use DBLookup with MS Dynamics NAV WS Connectors. If you for example want to retrieve the Country Code based on a Country Name when creating a new Customer or Contact in MS Dynamics NAV (using the corresponding Web service), you can now use DBLookup('DESTDS','Countries','Name',"Country Name",'Code') asuming that you have published a MS Dynamics NAV Web service called "Countries" that can be used to retrieve the country code.

To use this feature, you need to upgrade both central service and local RapidiConnector to version 3.2.91y or later. Please contact our support to arrange this.

Support for Codeunits with XMLPorts published as MS Dynamics NAV Web services

In MS Dynamics NAV you can either publish Pages or Codeunits as Web services. Although Pages offer a lot of standard functionality and very good integration into the MS Dynamics NAV code as you basically publish the Pages to enter data as well, Codeunits can be a better choice in some specific situations where you need more control over the code and data. We are pleased to announce, that we have now added this option to our MS Dynamics NAV WS Connector.

How to build the Codeunit

In order for RapidiOnline to know how to call the methods in your Codeunit, you need to build the Codeunit in a specific way.
In general you need methods called "UpdateMultiple", "CreateMultiple" and "ReadMultiple", each taking a var parameter that is a XMLPort (the same XMLPort for all methods). We detect the XMLPort parameter through these methods and let you create mappings to the tables and fields specified in the XMLPort.

If you want to use this new feature, please contact our support to get some sample code. We are also planning to make a detailed blog post on this topic a little later.

To use this feature, you need to upgrade both central service and local RapidiConnector to version 3.2.92u or later. Please contact our support to arrange this.


Support for SKIPFIELD function with MS Dynamics NAV WS Connector

Back last summer we introduced a new function called 'SkipField'. The function can be used as part of the mapping and will cause that RapidiOnline dynamically can skip sending a specific field (for a specific record) to the destination system. This is very usefull if either you want to preserve the value already set in the destination (or let the destination create a default value by itself) or if a value is not accepted (even if blank) by the destination for this field (typically depending on some other fields value).

An example is when you want to create text or comment lines on a SalesOrder. In this case the MS Dynamics NAV Web service does not accept the fields 'No' (Item No), 'Quantity' and 'UnitPrice' to be sent on that line. We can use the 'SkipField' function to achive exactly that, with a formula like 

##IF(EQUALS(LineType,0),SKIPFIELD(),Quantity)

we can achive that the Quantity field is not sent to the destination if the LineType is 0.

The 'SkipField' function is now supported for use with the MS Dynamics NAV WS Connector. This also includes that information about that a field should be skipped is sent to the RapidiConnector (we had to get that to work also). This is a change to the communication between the central server and the RapidiConnector and therefore both have to be upgraded. However introducing this change, we still ensure backward compatibility for both ends - e.g. an old RapidiConnector will work with a new Rapidi Central version and likewise a new RapidiConnector will work with an old Rapidi Central version. During the initial communication the two simply agree with each other what features they have in common and what they can support in the protocol, which makes upgrades more flexible.

To use this feature, you need to upgrade both central service and local RapidiConnector to version 3.2.92u or later. Please contact our support to arrange this.
 

Better error handling, error messages, ReadDesign and other improvements

We now have a better error messages when using "All Fields" or when a Field List is not specified. Still you always need to specify a Field List when using the MS Dynamics NAV WS Connector, but at least now you get a good and descriptive error message saying what to correct. This is available in version 3.2.91y

We now check for and return a better error message if the MS Dynamics NAV WS server returns anything else than a 200 OK HTTP response. The improved error message allows for a quicker identification of the issue and hence a quicker resolution.

'ReadDesign' revised and improved

The 'ReadDesign' feature for the MS Dynamics NAV WS Connector has been improved to detect more information in the WSDLs generated by MS Dynamics NAV. We now automatically detect for example namespaces, soap actions and the main object/table in use. We then use this information to generate the XML messages to send to MS Dynamics NAV WS. This makes the connector work with more custom defined Pages and Codeunits and removes the demand to publish the Page with the same name as the main table used by the Page (before the Customer Page had to be published as "Customer" and Sales Order Page as "SalesOrder" - this is not needed anymore). This is available in 3.2.92s or later.

Other improvements

Correct decoding of UTF-8 encoded fields from NAV

When using the MS Dynamics NAV WS to read data from MS Dynamics NAV or when doing Updates to MS Dynamics NAV, the MS Dynamics NAV WS Connector would not correctly decode UTF-8 encoded fields from MS Dynamics NAV. This is now fixed.

Page and batch size extended

The default Page size when reading from MS Dynamics NAV WS is now set to 50 (before it was just 5); The same goes for the batch size for sending records to MS Dynamics NAV WS (now default 50, before 5). These two numbers can also now be adjusted using the local rapidi.cfg file (add NavWSReadMultiplePageSize : xx (default 50) or NavWSUpdateAddBatchSize : xx (default 50)).

How to avoid "Server returned a HTTP error code (not 200 OK): 400 Bad Request"

We have also introduced another rapidi.cfg parameter to control if each request to the MS Dynamics NAV WS Server should be sent on a new connection. At least MS Dynamics NAV 2009R2 WS Server requires this. It can be set with the rapidi.cfg parameter NavWSRestartConnectionEachRequest : 1 (default is 0).
This avoids an error message: "Server returned a HTTP error code (not 200 OK): 400 Bad Request"

Faster execution of transfers

When doing a Connection Test (pushing "Test" on a NAV WS Connection), we now call the SystemService to test that proper access is setup (correct username, password and domain and server connect). At the same time we have removed this extra call to SystemService from the initialization of the MS Dynamics NAV WS Connector as this is not needed anymore. This should lead to a little faster execution of transfers in general.

These features are available in version 3.2.92u, you need to upgrade both central service and local RapidiConnector to version 3.2.92u or later. Please contact our support to arrange this.

Meet our Customer Success Team - Book time now!

 


About the author

Michael Bock

Picture of
Michael founded Rapidi on technological excellence, fantastic customer service and continuous improvement. A data integration specialist since 1987, he remains focused on creating technology that solves real business problems.


SHARE