Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 309 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Web service vs NAV Client 2017 context of execution
zpgm
Member Posts: 6
Hi all,
I have a question regarding a web service call and the code execution context in NAV 2017.
I have a card page which has an action to post the document. After some validations and using CODEUNIT.RUN(CODEUNIT::"MyCodeunit_name", MyTable), the post routine generates an XML that will be used in a DLL (it is a certified functionality created by some partner we had) to send encrypted data to some governmental agency.
Everything works fine when running in the NAV 2017 client.
Our company is taking out of NAV a couple of personalized developments and one of them is this page, though we must use the DLL to communicate with the governmental agency!
So, in an MVC project and using stored procedures I can insert/update data in the NAV 2017 database. I published a codeunit web service, that mimics the page action described, to use the same business logic.
The problem resides in the DLL method that is called: when running on the NAV Client it executes perfectly; but when is the web service codeunit to execute the call, it fails with the error "MyDll.MyMethod failed with this message: Object reference not set to an instance of an object".
My first thought was DateTime data types, Time Zones and the way NAV manages this issue, but debugging the NAV 2017 web service call every DateTime field has correct and consistent value (I don't know what the DLL code does).
Could the scope of execution (client vs web service context of execution) being the cause of this error?
Thank you.
I have a question regarding a web service call and the code execution context in NAV 2017.
I have a card page which has an action to post the document. After some validations and using CODEUNIT.RUN(CODEUNIT::"MyCodeunit_name", MyTable), the post routine generates an XML that will be used in a DLL (it is a certified functionality created by some partner we had) to send encrypted data to some governmental agency.
Everything works fine when running in the NAV 2017 client.
Our company is taking out of NAV a couple of personalized developments and one of them is this page, though we must use the DLL to communicate with the governmental agency!
So, in an MVC project and using stored procedures I can insert/update data in the NAV 2017 database. I published a codeunit web service, that mimics the page action described, to use the same business logic.
The problem resides in the DLL method that is called: when running on the NAV Client it executes perfectly; but when is the web service codeunit to execute the call, it fails with the error "MyDll.MyMethod failed with this message: Object reference not set to an instance of an object".
My first thought was DateTime data types, Time Zones and the way NAV manages this issue, but debugging the NAV 2017 web service call every DateTime field has correct and consistent value (I don't know what the DLL code does).
Could the scope of execution (client vs web service context of execution) being the cause of this error?
Thank you.
0
Comments
Yes, because there is a property that you should check on the NAV dll that is RunOnClient.
For your previous error I would guess that your current "working" code runs on client and "your new one" on server.
Thank you.
I found some Microsoft documentation about .NET types usage and some best practices:
I sent an email to the partner that build this DLL asking for help because they have to check out the DLL code and we must take a look at where is called in C/AL.