Hit enter to search.
I am happy to announce a major update to our support for Microsoft Dynamics AX web services. This mainly covers Microsoft Dynamics AX 2012 R1, R2 and R3 (but also some changes for Microsoft Dynamics AX 2009).
Throughout the last 6-8 months we have worked intensly on our support for Microsoft Dynamics AX 2012 focusing in particular on our support for the Microsoft Dynamics AX 2012 web services. We are comitted to support all versions of Microsoft Dynamics AX and hence it is natural for us to continue to invest in improving our support for these systems. The update consists of a number of changes that have been introduced over time and the overall outcome is that it is now a lot easier and faster to implement an integration with Microsoft Dynamics AX 2012.
Please read on to have a complete overview of the changes:
In Microsoft Dynamics AX 2009 the default Dimensions have to be sent as a list of elements when using e.g. the Customer web service to create a new Customer in Microsoft Dynamics AX. Generally we have added support for this by allowing a List of fields to be sent as an array of strings to Microsoft Dynamics AX. In MyRapidi you can create a List in two ways - either using a Gather Transfer or you can use the SPLIT function (which is much simpler).
Here is an example:
##SPLIT('AAA|BBB|CCC','|')
This function will create a list with three elements/string which can be mapped to the Dimension field on the Microsoft Dynamics AX 2009 Customer web service. It will set AAA as the first dimension, BBB as the next dimension and CCC as the third dimension. If you have the Microsoft Dynamics AX Dimension setup to have fewer or more dimensions, then simply adapt the formula. You can also get values for the dimensions from fields on the source record by entering these fields (in double quotes) as part of the formula.
This feature was made available in version 3.2.91n of the RapidiConnector.
In Microsoft Dynamics AX 2012 the Dimension structure is more flexible allowing for a number of already named Dimensions and allowing you to set only a few Dimensions if you wish. The structure required by the Microsoft Dynamics AX web service needs to has both name and value of each dimension and you are able to set a variable number of dimensions. We have chosen again to make this more simple in MyRapidi by allowing you to specify a list. The list needs to contain an even number of elements and needs to contain both the name and the value of each dimension that you want to set.
Here is an example:
##SPLIT('CostCenter|OU_3567|Department|OU_2310','|')
When using this as source and mapping it into the field DefaultDimension on the Microsoft Dynamics AX 2012 Customer web service, you will set the CostCenter dimension to OU_3567 and the Department dimension will be set to OU_2310. In the layout you will see a type of "valueset" for the DimensionValueSet field types.
This feature is made available in version 3.2.92z of the RapidiConnector.
You can now Read Design on the standard SalesQuotationService. There was an issue related to the naming of the service, but now it is read correctly during Read Design and will work in Transfers. This was added in version 3.2.91r of the RapidiConnector
We are now reading the SOAP Action and Target Namespace from the WSDL and using this information when compose the web service calls. Before we were composing this information from the Service name. This allows us to support various web services for Microsoft Dynamics AX, including custom-built web services that do not use the standard namespace. (this was added in version 3.2.91s of the RapidiConnector).
We have later improved the Read Design process for the SOAP Action as the above approach would not always work (a fix was provided in version 3.2.92q).
In version 3.2.92z we improved the discovery of web services for Microsoft Dynamics AX 2012 - now we look for web services published with namespace tempuri.org in addition to the standard Microsoft Dynamics namespace.
And finally after more debugging, we have found a better way to extract this information from the WSDL and this is introduced in version 3.2.93a of the RapidiConnector.
In the WSDL for the different web services published in Microsoft Dynamics AX you cannot see what field is actually the primary or unique key for that web service. As we need this information when e.g. updating records, we set it manually in the code. This means that if you want to use a new (custom) web service, you might need to contact our support to get this set. We have added support for the following WebServices lately:
SalesQuotationTable table with QuotationId (version 3.2.91r)
InventTrans table with InventTransId (version 3.2.91y)
ConfigTable table with idfield ConfigId (version 3.2.92e)
smmBusRel table with idfield BusRelAccount (version 3.2.92w)
ContactPerson table with idfield ContactPersonId (version 3.2.92w)
smmOpportunityTable table with idfield OpportunityId (version 3.2.92w)
smmLeadTable with idfield LeadId (version 3.2.92z)
This is not a complete list of what we support, so please try with your web service - if you get an error like "IdFieldName not found for entity..." then please contact our support.
We are working on a better solution to this - for example to take this information from the transfer setup if possible - please stay tuned.
We have made a number of improvements to generate data in the correct format and correct order even if you specify e.g. sub-elements (or sub-tables) in a different order in MyRapidi. The Microsoft Dynamics AX web services are very strict on the order that you sent the fields and elements in - and the error messages that you get from Microsoft Dynamics AX or IIS are usually really useless (something with problems with the schema or just that the server could not process the request due to an internal error...). This can cause a lot of trouble trying to figure out what is wrong.
We are now always sending sub-elements (sub-tables) in the correct order (according to the WSDL) when creating new entities in Microsoft Dynamics AX.
We are now adding the ServiceName in front of table name in order to make the table name unique. This is important to allow several web services to co-exist even if they have sub-element with the same names (like DirParty or ContactPerson). The service name is also added to the Layout comment field so that its easy to see what service a given table (sub-table) belongs to, when doing the mapping.
We have fixed a problem that our tracing facility could fail if a date or datetime field value was empty.
We have also fixed a problem with write of datetime fields - the format needed to include a "Z" at the end.
We have fixed an error in relation to Decimal fields. The error message was: "createField: unknown type AxdType_Decimal". We are now resolving the correct type when we are Reading Design and hence you wont get this error anymore. This was fixed in version 3.2.92w.
We still have one outstanding improvement related to support for different fieldtypes with Microsoft Dynamics AX 2012 web services. For now do not support the AxdEntityKey_ fields. If you need to set a value for a field of this type, please contact us and we will work to get that supported.
For Microsoft Dynamics AX 2012 we now not only try to connect to the IIS server, but also actually try to call a web service when testing the connection - e.g. clicking the Test button on the Connection card. In this way we are sure that the Test Connection feature will actually reveal any problems related to calling the web services that are published on the server.
The Test Connection feature makes a call to the GenericDocumentService read operation to try to read the Customer Groups from Microsoft Dynamics AX. This works fine as long as you have published the GenericDocumentService Read operation.
We have at the same time worked through the error handling related to possible errors that you can get during this test and tried to make the error messages better including suggestions to possible solutions to the actual problem.
Among other things, we now check specifically for when a wrong path given in "Server Connect" parameter and provide a better error handling and message for this situation (this could result in a SocketReadError previously).
We now provide a better error message if the IIS server is not running (before we got a SocketConnectToServer error talking about central server etc.)
These improvements were introduced in version 3.2.92z.
When using a DBLookup function and reading from Microsoft Dynamics AX database (SQL Database), we used our generic MS-SQL handler to handle the lookup in the SQL database. This would work but did also create a memory leak in the RapidiConnector. This has now been fixed and we now use the Microsoft Dynamics AX handler for the DBLookup correctly.
This also means that the DBLookup will automatically have a filter on the DATAAREA field (to the company set on the Microsoft Dynamics AX Connection). This is normally perfect but in some cases you might need to lookup data in another company and then you can simply specify a filter on the DATAAREA in the DBLookup and this will overwrite the general filter.
This was fixed in version 3.2.92h of the RapidiConnector.
In general, to have the best support for Microsoft Dynamics AX web services, you should upgrade to version 3.2.93a of the RapidiConnector and version 3.2.92z or later on the central service.
Please contact our support to arrange this.
Thanks for reading and please do let us know if you have any questions.
Michael
Michael Bock, Founder & CEO
MS Dynamics GP end of life - what about integration? Rapidi ...
Upgrade from Dynamics NAV to Dynamics 365 Business Central ...
Cross Reference Keys Made Easy with the New Link Storage ...
Carrer de la Font del Colom, 6,
L'Aldosa,
AD400 La Massana, Andorra
Copyright © 2024 Rapidi.
All Rights Reserved
Terms & Conditions |
Privacy Policy