Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Ussing .Net WebService in Powerbuilder (Obsolete)

  1. Advice
1
Votes
Undo
  1. shaila panwar
    shaila panwar
  2. PowerBuilder
  3. Thursday, 28 November 2019 05:37 AM UTC

Creating webservice proxy using .Net Engine, this feature was available and very much in support with the version 2017

With the current version Appeon 2019 , I am finding this as Obsolete, though the document says that it is only when  “Web service proxy for connecting to SOAP server”,

Which is quite understood for the Easy Soap Engine, but does that mean when we use the .Net Engine it will be considered as Obsolete because at the end Proxy generated through .Net engine also uses the SOAP connection methods to connect  the webservices.

The alternate method proposed HTTPClient needs lot of coding if we wanted the data the way it used to be generated by the Webservice Proxy Wizard.

 

 

 

  1. PB Native
How to get the query string in PowerSript
Create a .NET Web Service in PB2017
Accepted Answer
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 28 November 2019 07:09 AM UTC
  2. PowerBuilder
  3. # Permalink

If you want to consume a Web API you should be using the HTTPClient or RESTClient objects.  The old SOAP clients are obsolete... they are heavy to deploy and have security issues.

If you have legacy SOAP Web services you need to consume, this article may help you: https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/236-call-soap-web-services-using-httpclient-object

If you want to create Web services, PowerBuilder 2019 supports doing so using DataWindow technology, C# programming language, and REST standard.  Here are some tutorials: https://docs.appeon.com/appeon_online_help/snapdevelop2019/Create_a_Web_API/index.html and https://docs.appeon.com/appeon_online_help/powerbuilder/CRUD_Operations_with_.NET_DataStore/index.html

You can use any C# IDE to maintain your Web API project, but of course the tools PowerBuilder provides is simpler and more productive ;-)

Comment
Load more comments
Ricardo Jasso
  1. Ricardo Jasso
  2. Saturday, 21 December 2019 01:43 AM UTC
... until something new is developed that replaces it.
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Saturday, 21 December 2019 03:07 AM UTC
We totally understand that a specialized web service client for SOAP just like the RESTClient object we provide for REST services is preferred. We are just not seeing enough demand at this point in time. If you don't want to use the HTTPClient the other option would be create a proxy object/bridge in C# that calls the SOAP service. PB 2019 R2 can import C# libraries and call natively from PowerScript. https://youtu.be/kmzvjQ6yI-Y?t=293
  1. Helpful
Ricardo Jasso
  1. Ricardo Jasso
  2. Saturday, 21 December 2019 19:24 PM UTC
We are already using the REST and HTTP Client objects because the digital invoice provider changed its service from SOAP to REST but with the drawback that now we must send the digital invoice XML document as a single Base 64 encoded string (!). So, we had to implement code to manually build the XML based on its corresponding XSD which in my point of view was a huge step back. This is one of the reasons we are considering switching providers, among its poor customer support.

Now that you mention the C# Importer, I mentioned in another post but would to repeat it here that it should be called .NET Importer and not C# Importer. I made a test importing .NET assemblies made using Visual Basic.NET and could do it with no problem. Since I cannot attach images to comments I’m making a new reply to this post to show the original VB.NET project, the C#(.NET) Importer, and the resulting PB NVOs.

  1. Helpful
There are no comments made yet.
Responses (2)
Ricardo Jasso
Ricardo Jasso Accepted Answer Pending Moderation
  1. Saturday, 21 December 2019 19:25 PM UTC
  2. PowerBuilder
  3. # 1

Why it should be called .NET Importer and not C# Importer (see attached images).

Attachments (3)
PTest 1 - VB.NET.PNG PTest 1 - VB.NET.PNG
PTest 2 - PB C#(.NET) Importer.PNG PTest 2 - PB C#(.NET) Importer.PNG
PTest 3 - PB NVOs.png PTest 3 - PB NVOs.png
Comment
Load more comments
Ricardo Jasso
  1. Ricardo Jasso
  2. Sunday, 22 December 2019 00:18 AM UTC
Yes, you did mention it and I responded then that there is no such thing as a C# library. They are only .NET libraries which can be produced by any .NET language like C# or VB.NET. (I recommend the excellent book Understanding .NET by David Chappell where this is clearly explained). So, in my view and unless I'm missing something the Importer works for both C# produced .NET libraries as well as VB.NET produced .NET libraries. There's no additional testing needed for what I understand. My example proves it. I could successfully import .NET libraries that were produced by VB.NET. That's why I think it should be called .NET Importer. It might be considered just semantics, but I don’t see it that way. C# Importer sounds technically cumbersome to me and I guess to any .NET developer. Renaming it to .NET Importer would make more sense and will automatically expands its reach inside the .NET community. I thought it was important to mention it at this point but maybe I misunderstood what is the purpose of a Beta release.
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Sunday, 22 December 2019 04:19 AM UTC
We are trying to keep it short instead of saying something like '.NET Library Developed in C#". I understand it's not the technically accurate way to describe it. If you have a better suggestion that is very short we welcome your suggestion.

If you are certain VB.NET language will work then I don't understand what you want us to change in the product. As I mentioned, we won't officially claim other .NET languages are supported until we have carefully tested this ourselves, so for the time being we are making the "C#" distinction.
  1. Helpful
Ricardo Jasso
  1. Ricardo Jasso
  2. Sunday, 22 December 2019 16:44 PM UTC
Armeen, first of all, I want to thank you for all the effort you and your team have done since Appeon took over PowerBuilder. We are with no doubt in a much better position than we were several years ago. All the new cloud enhancements are in the right direction IMHO as well as the native product enhancements, and it’s good to have them as integral part of the tool, not just as extensions. Again, thank you for your effort.



If the C# importer allows me to import not just C# classes but also VB.NET classes (all .NET classes), I’m fine with that and I’ll be happy to use them as is. This is way much better than having to deal with COM callable wrappers. The important thing is to have this functionality as soon as possible to allow us to stay competitive.



I think it’s best for me not to interfere in Appeon’s decisions about what’s best for the product. The market is good enough feedback already. I’ll continue doing more testing on all the new features of the beta release in my spare time and if I find something that is not working as it should I’ll report it as soon as I can.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.