Any SOAP success stories?

[MikeBranch]

Greetings - I've been trying off and on to expose SOAP web services in OFBiz. I mean "normal" SOAP, not services that can only return a map. I know that this is supposedly possible now, but I just haven't had much luck. I was wondering if anybody out there has got this to work. Specifically, I want to call the services from a .NET application so I can integrate with QuickBooks. I'm also looking into calling OFBiz from Salesforce.com.

Is XML-RPC, or some other method, preferred?

[BJ Freeman]

not much help as far as SOAP.
been using both QB and quicken home and business with ofbiz for years.
here is the doc for Quickbooks if you want to integrate directly into ofbiz.
http://developer.intuit.com/qbsdk-current/doc/pdf/qbwc_proguide.pdf
why not integrate Salesforce.com into ofbiz SFA?


=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/control/forum?forumId=SUPPLYCHAIN>

Specialtymarket.com <http://www.specialtymarket.com>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


MikeBranch sent the following on 6/23/2011 9:46 AM:

> Greetings - I've been trying off and on to expose SOAP web services in OFBiz.
> I mean "normal" SOAP, not services that can only return a map. I know that
> this is supposedly possible now, but I just haven't had much luck. I was
> wondering if anybody out there has got this to work. Specifically, I want to
> call the services from a .NET application so I can integrate with
> QuickBooks. I'm also looking into calling OFBiz from Salesforce.com.
>
> Is XML-RPC, or some other method, preferred?
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Any-SOAP-success-stories-tp3620409p3620409.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[David E. Jones-2]

I'd recommend doing more research on SOAP and XML-RPC. They are VERY different specifications.

If you're using SOAP in many cases it is just a very heavy and expensive wrapper around an XML payload that represents the actual data to be transferred. Those XML payloads are generally defined with a custom XSD and it is almost always necessary to write code to process the input and output for each message (ie map them to OFBiz services or entities).

The OFBiz service engine can handle any object going in or out, but the easiest structures to organize data are Maps and Lists.

The nice thing about XML-RPC (and JSON-RPC) is that the spec includes mappings to and from the documents for Maps and Lists, as well as data types such as Strings and Numbers. Because of this it is much easier to use XML-RPC or JSON-RPC, and honestly this is why JSON is such a nice standard for data transfer (because it is data structured in lists and maps, making it easier to deal with than an arbitrary XML document that requires code to map to either an object model or to lists and maps).

-David


On Jun 23, 2011, at 9:46 AM, MikeBranch wrote:

> Greetings - I've been trying off and on to expose SOAP web services in OFBiz.
> I mean "normal" SOAP, not services that can only return a map. I know that
> this is supposedly possible now, but I just haven't had much luck. I was
> wondering if anybody out there has got this to work. Specifically, I want to
> call the services from a .NET application so I can integrate with
> QuickBooks. I'm also looking into calling OFBiz from Salesforce.com.
>
> Is XML-RPC, or some other method, preferred?
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Any-SOAP-success-stories-tp3620409p3620409.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

[Jacques Le Roux]

It works, some prefer XML-RPC because it's simpler (no confusing specifications)

OTTOMH I remember https://issues.apache.org/jira/browse/OFBIZ-4245

You should have a look at https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12315880
Most are unrelated to your question but it might help

Jacques

MikeBranch wrote:
> Greetings - I've been trying off and on to expose SOAP web services in OFBiz.
> I mean "normal" SOAP, not services that can only return a map. I know that
> this is supposedly possible now, but I just haven't had much luck. I was
> wondering if anybody out there has got this to work. Specifically, I want to
> call the services from a .NET application so I can integrate with
> QuickBooks. I'm also looking into calling OFBiz from Salesforce.com.
>
> Is XML-RPC, or some other method, preferred?

[prasath]

hi,

We made a XML-RPC call from ESB- java to ofbiz export service (webservices).
It is perfectly running.

thanks & regards
prasath. r

On Thu, Jun 23, 2011 at 11:44 PM, Jacques Le Roux <
[hidden email]> wrote:

> It works, some prefer XML-RPC because it's simpler (no confusing
> specifications)
>
> OTTOMH I remember https://issues.apache.org/**jira/browse/OFBIZ-4245<https://issues.apache.org/jira/browse/OFBIZ-4245>
>
> You should have a look at https://issues.apache.org/**
> jira/secure/IssueNavigator.**jspa?mode=hide&requestId=**12315880<https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12315880>
> Most are unrelated to your question but it might help
>
> Jacques
>
>
> MikeBranch wrote:
>
>> Greetings - I've been trying off and on to expose SOAP web services in
>> OFBiz.
>> I mean "normal" SOAP, not services that can only return a map. I know that
>> this is supposedly possible now, but I just haven't had much luck. I was
>> wondering if anybody out there has got this to work. Specifically, I want
>> to
>> call the services from a .NET application so I can integrate with
>> QuickBooks. I'm also looking into calling OFBiz from Salesforce.com.
>>
>> Is XML-RPC, or some other method, preferred?
>>
>
>

[MikeBranch]

Thanks, everybody for your replies. They were all very helpful. It sounds like my idea of using XML-RPC would be the less painful approach. I have gotten XML-RPC to work on .NET, but haven't tried it with OFBiz yet.

Re: The QB Web Connector: That was where I started, but the problem is that you have a canned client (QBWC) that you can't change, so you need to build the service to be compatible with the client. Given the state of SOAP in OFBiz this turned out to be too big of an obstacle, at least for me.

I agree with David that XML/JSON-RPC are attractive options, and I think I'm going to go that route. But your reply prompts me to make a comment about the open source world in general:

Coming from a .NET background (but quickly recovering!), it's very frustrating for me to have to wade through discussions about specifications and standards, Java data types vs .NET data types, this protocol is better than that protocol because it only uses 547 bytes instead of 613 bytes, etc. etc. etc. Now, I have a master's degree in software engineering, so it's not that I don't understand that stuff. It's just that I shouldn't have to.

When I write a .NET program to make SOAP calls to Salesforce, it just works. I don't even have to worry about what version of SOAP I'm using (or they're using). I have no idea what kind of web servers, database, programming language, or operating system Salesforce is using. And I don't care, because everything just works.

My point is this: If you want to improve adoption of any open source platform or technology, it wouldn't hurt to shorten the list of things that newcomers (like me) need to figure out. If I have to drill down through 17 layers of libraries, protocols, specifications, etc., then eventually my brain is going to overflow and I'll just go work on something else where I can make just as much money with fewer headaches (and fewer things that might break for my clients). In the case of OFBiz, which I think is very cool, when I get to the word "SOAP" that should be the end. I should be able to say "OK, that's just SOAP. I get it. Now I'll go learn how to build a UI or something." I guess I'm really talking about a change in attitude, where it's not assumed that the application developer needs to understand every line of code right down to the kernel.

Sorry, I didn't mean to turn this into a rant. But please take it in the spirit in which it's intended: An idea that might help improve adoption of OFBiz. I would certainly like to help contribute to that effort myself, if I could just get 6 months of income in the bank :-)

[David E. Jones-2]

There's nothing we can do about bad specs like SOAP. However, consider that OFBiz is just one little open source project, and hasn't seen even close to one percent of the investment in development that .NET or even SalesForce.com have.

On the other hand, there are good tools for building SOAP clients and servers, so fortunately in OFBiz we don't have to invest in such things. Just look into a good IDE that has tools for building SOAP services and service clients, that's the easy way out. There are some nice tools built on the Eclipse IDE, though I use IntelliJ IDEA mostly these days.

BTW, in the real world of integration the reality is that there are hundreds of standards, and unless two things are designed to work well together or one has extensions to support the other, then you'll have to look into what each supports and figure it out. You didn't say what made you experiences with .NET and Salesforce easy, so it would be hard to guess at that, but changes are the SalesForce SOAP services are just as annoying as any other to work with manually, so it was really the .NET IDE you used that made it easy.

The same things exist in the Java world, but not part of OFBiz (which is not an IDE).

-David


On Jun 24, 2011, at 6:49 PM, MikeBranch wrote:

> Thanks, everybody for your replies. They were all very helpful. It sounds
> like my idea of using XML-RPC would be the less painful approach. I have
> gotten XML-RPC to work on .NET, but haven't tried it with OFBiz yet.
>
> Re: The QB Web Connector: That was where I started, but the problem is that
> you have a canned client (QBWC) that you can't change, so you need to build
> the service to be compatible with the client. Given the state of SOAP in
> OFBiz this turned out to be too big of an obstacle, at least for me.
>
> I agree with David that XML/JSON-RPC are attractive options, and I think I'm
> going to go that route. But your reply prompts me to make a comment about
> the open source world in general:
>
> Coming from a .NET background (but quickly recovering!), it's very
> frustrating for me to have to wade through discussions about specifications
> and standards, Java data types vs .NET data types, this protocol is better
> than that protocol because it only uses 547 bytes instead of 613 bytes, etc.
> etc. etc. Now, I have a master's degree in software engineering, so it's not
> that I don't understand that stuff. It's just that I shouldn't have to.
>
> When I write a .NET program to make SOAP calls to Salesforce, it just works.
> I don't even have to worry about what version of SOAP I'm using (or they're
> using). I have no idea what kind of web servers, database, programming
> language, or operating system Salesforce is using. And I don't care, because
> everything just works.
>
> My point is this: If you want to improve adoption of any open source
> platform or technology, it wouldn't hurt to shorten the list of things that
> newcomers (like me) need to figure out. If I have to drill down through 17
> layers of libraries, protocols, specifications, etc., then eventually my
> brain is going to overflow and I'll just go work on something else where I
> can make just as much money with fewer headaches (and fewer things that
> might break for my clients). In the case of OFBiz, which I think is very
> cool, when I get to the word "SOAP" that should be the end. I should be able
> to say "OK, that's just SOAP. I get it. Now I'll go learn how to build a UI
> or something." I guess I'm really talking about a change in attitude, where
> it's not assumed that the application developer needs to understand every
> line of code right down to the kernel.
>
> Sorry, I didn't mean to turn this into a rant. But please take it in the
> spirit in which it's intended: An idea that might help improve adoption of
> OFBiz. I would certainly like to help contribute to that effort myself, if I
> could just get 6 months of income in the bank :-)
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Any-SOAP-success-stories-tp3620409p3623964.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

[BJ Freeman]

depends on how much integration you are after and if you want it automated.
the solution I have is I export from ofbiz a web connect qfx files,
using xsl.
there is a record limit for intuit products so I just download the GL.

hope that helps.


MikeBranch sent the following on 6/24/2011 6:49 PM:
> Re: The QB Web Connector: That was where I started, but the problem is that
> you have a canned client (QBWC) that you can't change, so you need to build
> the service to be compatible with the client. Given the state of SOAP in
> OFBiz this turned out to be too big of an obstacle, at least for me.
>

[BJ Freeman]

My background starts with 8bit machine code in the 70's with runtime
basic, Pascal ( the bases for .NET) C, C++, VB, Java.
I even spent 5 yrs on the Microsoft Campus in the MSDN group consulting.
lets starts with simple hello world.
first you have the OS interface layer
then you have the framworks to present the Hello world to the user.
Now in C this compiles down to about 1K
in C++ you jump to 10K because of the string overhead of a class.
to use .Net on any system the User will have a few gigabytes of frame
work loaded on their system. and memory.
Java runtime is not as large as the .Net framwork.
to me Size of the frame work translates to the bloat of memory use.
I won't even get into swapping of code sections due to this bloat.

so the ease of .Net requires a lot more user memory to use than Java.
not to mention the security holes in MS Object framework they keep patching.

back in the early 2000 I started the trek you are on and ended up with
Ofbiz framework. This is because it does not have the bloat that even
Java classes have.

Unlike .NET I don't have to wait for an ugrade or patch to fix what I
find are problems.

Note: be thankful for the documentation that is now available. When I
started with ofbiz you had to read the code to find out anything.

MikeBranch sent the following on 6/24/2011 6:49 PM:

> Coming from a .NET background (but quickly recovering!), it's very
> frustrating for me to have to wade through discussions about specifications
> and standards, Java data types vs .NET data types, this protocol is better
> than that protocol because it only uses 547 bytes instead of 613 bytes, etc.
> etc. etc. Now, I have a master's degree in software engineering, so it's not
> that I don't understand that stuff. It's just that I shouldn't have to.
>
> When I write a .NET program to make SOAP calls to Salesforce, it just works.
> I don't even have to worry about what version of SOAP I'm using (or they're
> using). I have no idea what kind of web servers, database, programming
> language, or operating system Salesforce is using. And I don't care, because
> everything just works.
>
> My point is this: If you want to improve adoption of any open source
> platform or technology, it wouldn't hurt to shorten the list of things that
> newcomers (like me) need to figure out. If I have to drill down through 17
> layers of libraries, protocols, specifications, etc., then eventually my
> brain is going to overflow and I'll just go work on something else where I
> can make just as much money with fewer headaches (and fewer things that
> might break for my clients). In the case of OFBiz, which I think is very
> cool, when I get to the word "SOAP" that should be the end. I should be able
> to say "OK, that's just SOAP. I get it. Now I'll go learn how to build a UI
> or something." I guess I'm really talking about a change in attitude, where
> it's not assumed that the application developer needs to understand every
> line of code right down to the kernel.
>