Issue in CodeUnit-WEB SERVICE

Ravi_Thakkar

Hello All Experts,

1) I am facing problems in publishing the CodeUnit WEB SERVICES, which are having Record Variables as a Paramaters. Issue related screenshot is attached bellow.

If any idea then please help.

2) If any body is having idea then please, suggest me the procedure to do the Posting by using the Web Services from WEB.

Any replies will be appreciated.
Thanks in Advance.

kine

Try to publish the codeunit as extension of some page based on same record. You can do that in this way:

Publish the page in common way
Add the codeunit into the Web Service table, with same name as the page. Do not tick the Publis checkmark.

Now, when you look at the WebService for the page, you should see the functions from the codeunit between other methods...

ara3n

Create a new codeunit that takes two paramaters DocumentType and documentNo

In the function.

SalesHeader.get(DocumentType,documentNo);
CU80.run(SalesHeader);

Publish this new codeunit on webservice.

kriki

[Merged posts from topic http://www.mibuso.com/forum/viewtopic.php?t=33776 ]

Ravi_Thakkar

Thanks for your replies.

I can use codeunits as an Extension Codeunit. That is right.
But,
E.G. I want to have access of methods of Code Unit 80 Sales Post.
So, I published Page 42 Sales Order with name SalesOrder and used CU 80 as an Extension CU with the same name SalesOrder.
When I try to consume the Web-Service SalesOrder at that time It should also show me all methods of CU 80. But only showing the methods of Default Page Web-Service.
So is there any another solution to get the access of such long codeunits' methods?

Please suggest me as soon as possible.
Thanks in ADV.

kine

And is the Publish checkmark checked or not for the codeunit?

Ravi_Thakkar

Hello Kine,

I dont have put the Checkmark in that CodeUnit as the process for Extension Codeunit.

Any suggestion or help?

freddy.dk

Note, that we do not recommend that you just expose base NAV codeunits as web services.
You should create the codeunit that expresses the high-level contract you want to use and then that code can call into CU 80 or whatever.

Ravi_Thakkar

Thanks for reply.

Yes, I know there is no any recommendation to expose the same CU.
And I also planned to use my customized CU and in that I called the required CU.

But, I am wondering, why I am not able to get the Methods of Existing CU having much more complexity and more methods with more parameters.

Any suggestion?

ara3n

because there are many function that take non primitive parameters, and web service can allows you to use one at least provided it has the same name as the Page you are publishing.

Ravi_Thakkar

That means, to access complex existing codeunits, I will always required to create a seperate codeunits and make a call to the required codeunits.

If that is right, then it's not a feasible option. Because I need to use so many codeunits from NAV. Then to access any simple & small methd of any Complex CU, I will require to make CU.

Is there any another option or logic to implement?

ara3n

If the function parameters are all primitive you can use it as web service.
And you don't necessary need to create a new codeunit for each codeunit.
You only need one codeunit with all the necessary functions.
This is for your benefied. Main reason is that if anything gets modified in NAV, you don't have to modify what ever you are integrating with.

Also what are you integrating that you need all the CU?

Ravi_Thakkar

ara3n wrote:

This is for your benefied. Main reason is that if anything gets modified in NAV, you don't have to modify what ever you are integrating with.

Also what are you integrating that you need all the CU?

Thanks. I really appreciate your suggestion.


Please, keep me updated if you find any other feasible sollution,

freddy.dk

One advantage of having one codeunit, where you define the contract to your web service consumer (as Rashed suggests) is, that IF somebody changes something in one of the codeunits in the system - then they would get a compile error in NAV. If you just expose everything, then you would never know whether or not a contract has been broken until you actually run into the problem - and then you would have to change your web service consumer.

Also, the recommendation is to create a highlevel communication with web services - and not a ton of calls to a lot of different methods.

Same with Pages - if you consume a page as a web service and somebody customizes the page (removing some fields) then your contract is broken and your consumer might run into problems. To avoid this problem you have 3 options: Create the pages you consume yourself, use loosely coupled page WS access (sample on my blog) or update the service references and recompile your web service consumer app everytime somebody customizes NAV.

Ravi_Thakkar

freddy.dk wrote:

One advantage of having one codeunit, where you define the contract to your web service consumer (as Rashed suggests) is, that IF somebody changes something in one of the codeunits in the system - then they would get a compile error in NAV. If you just expose everything, then you would never know whether or not a contract has been broken until you actually run into the problem - and then you would have to change your web service consumer.

Also, the recommendation is to create a highlevel communication with web services - and not a ton of calls to a lot of different methods.

Same with Pages - if you consume a page as a web service and somebody customizes the page (removing some fields) then your contract is broken and your consumer might run into problems. To avoid this problem you have 3 options: Create the pages you consume yourself, use loosely coupled page WS access (sample on my blog) or update the service references and recompile your web service consumer app everytime somebody customizes NAV.

Thanks for your nice Suggestion.