loopback-next
loopback-next copied to clipboard
LB4 equivalent of `lb soap`
Suggestion
In LB3, lb soap command generates application artifacts based on WSDL file. It will be good to have the LB4 version of it.
From our npm download numbers, there are a good number of users using strong-soap. The new lb4 soap command will brings values to users who still wants to connect to SOAP services with a specified WSDL.
cc @raymondfeng
Acceptance criteria
- [ ] Implement
lb4 soapcommand - [ ] create a page under cli reference on
lb4 soapand update the main table - [ ] update the sidebar accordingly.
I'm also needing this for one of our project, as of today we would have to write the code on our own right?
Also, is there any working example/guide on how to do the process manually?
@raymondfeng, any suggestions?
@fenixsolorzano We do support SOAP Web Service today but in a weakly typed style. See https://loopback.io/doc/en/lb4/Calling-other-APIs-and-web-services.html#datasource-for-soap-web-service and https://github.com/strongloop/loopback-next/tree/master/examples/soap-calculator.
Will it be possible to get the same functionality of lb soap anytime soon? @raymondfeng
@raymondfeng , I am planning to add this functionality during the following weeks. As a starting point we can inspect the wsdl at lb4 datasource creation time and ask the developer which remote methods he/she wants to incorporate. I will try to see the current strong-soap package capabilities to retrieve this meta data.
Then I think we can incorporate another option lb4 soap to add methods to an already created service?.
Does it make sense?, please confirm or guide.
@marioestradarosa Thank you for stepping up. Here is what I have in mind:
- We can mimic the flow of
lb4 openapi --client
- Allow both
urlto the wsdl/xsd or--dataSourcefor an existing soap datasource - Use
strong-soapto load the wsdl/xsd - List service/port/operations to selected (or just select all)
- List XSD elements/types used by the operations
-
The operations will translated into service interfaces grouped by
portType -
Generate model definitions or TypeScript types for XSD elements/types (Maybe we can build json schema from XSDs so that we can reuse the code to generate models/types)
-
Generate service providers by the soap datasource
-
There are quite a lot of similarities we can use from https://github.com/strongloop/loopback-next/tree/master/packages/cli/generators/openapi
@marioestradarosa, thanks for taking up the implementation. Let me assign this issue to you now. Thanks.
@raymondfeng I agree with your approach and think it makes sense to have the datasource already there. Thanks @dhmlau 👍 . I will start the implementation.
Any updates on that one?
The calculator soap service does not appear to be working and the second url page is not found. Would appreciate an updated working SOAP example.
@fenixsolorzano We do support SOAP Web Service today but in a weakly typed style. See https://loopback.io/doc/en/lb4/Calling-other-APIs-and-web-services.html#datasource-for-soap-web-service and https://github.com/strongloop/loopback-next/tree/master/examples/soap-calculator.
The calculator soap service does not appear to be working and the second url page is not found. Would appreciate an updated working SOAP example.
@fenixsolorzano We do support SOAP Web Service today but in a weakly typed style. See https://loopback.io/doc/en/lb4/Calling-other-APIs-and-web-services.html#datasource-for-soap-web-service and https://github.com/strongloop/loopback-next/tree/master/examples/soap-calculator.
Soap-Calculator example is working fine at this moment. The link referenced by @raymondfeng is now here Calling Soap web services
First time user of this library here. I don't understand why the LoopBack 4 documentation is providing examples and instructions with LoopBack 3 commands. Eventually found this GH issue to come to the conclusion that what I was trying to do isn't really possible, or if it is then it's not documented. It's confusing. Maybe its a great library, but seeing that this issue is nearly a year old now gives me pause. Unfortunately I don't have the expertise in this area to offer any sort of contribution - I was just trying to do some research and/or plumbing.
First time user of this library here. I don't understand why the LoopBack 4 documentation is providing examples and instructions with LoopBack 3 commands. Eventually found this GH issue to come to the conclusion that what I was trying to do isn't really possible, or if it is then it's not documented. It's confusing. Maybe its a great library, but seeing that this issue is nearly a year old now gives me pause. Unfortunately I don't have the expertise in this area to offer any sort of contribution - I was just trying to do some research and/or plumbing.
@jziggas I am working on this feature as of today, couldn't work on this in the past due to some other duties. But I have integrated SOAP proxy service in several projects, perhaps I can assist if you explain what is your use case scenario ? The SOAP calculator is a good example that shows how the REST server integrates very well with external services exposing SOAP .
On a side note, this particular features is not really needed to work with external SOAP services. I have mapped manually the interfaces exposed by the XSD ver well.
@marioestradarosa, Hi I'm thankful that you're willing to work on this. The expected behavior of this command is documented here. This would be very useful for me because I am consuming many APIs that have many methods, so manually creating proxy classes for them would be a tedious. this is what the command helps with as far as I understand.
Hi guys, any update on this one? I would really love to use Loopback4 for some simple soap to rest conversion that I currently do in LB3 very easily using lb soap to set it all up. LB4 is a different story and difficult to use for non-developers like myself. It would be great if LB4 could offer that same functionality.
Unfortunately no new updates AFAIK; Just haven't had the resources to work on this feature; It's still possible to do it manually without the CLI, and we're open to community contributions to implement this feature if anyone wants to champion it.