SOAP Api Connection Errors after upgrade to 19.4.17

[Dirtyhair1]

Preconditions (*)

1.Previously had OpenMage 19.4.15 installed with no issues. We updated to 19.4.17 on Wednesday and straight away have had issues connecting by SOAP to our inventory system. We have also been notified that Klaviyo cannot connect to our store either.
2.

Steps to reproduce (*)

1.Update to Openmage 19.4.17 from Openmage 19.4.15

Expected result (*)

1. We should have a clean update with no issues, we tested the site on our staging setup before pushing live and didn't notice anything. On the staging site we don't have these platforms connected though so only found out once pushed to production/live site.

Actual result (*)

1. Dear Systems - inventory system - cannot pull any orders from Magento store into Dear Systems, nor can it push any inventory updates to our Magento store. When we try to force it to do one of these actions, an error comes up which is in the image below:
   
   "Unexpected WSDL element"
2. Klaviyo - email marketing platform - same issue but mainly refers to order/customer data, it is not syncing with Klaviyo and comes up with similar error:
   "Invalid WSDL file at website. Received error message: ":8:37: not well-formed (invalid token)."

Anyone else seeing anything like this?

[fballiano]

would it be possible for you to test the github version of openmage19? there are so many things going on at the moment that the problem could have been solved already?

[fballiano]

It could be this one btw:
#2405

[ADDISON74]

Check this file /app/code/core/Mage/Api/etc/wsi.xml.

If you have in line 8 the following statement targetNamespace="OpenMage" then change it to targetNamespace="urn:OpenMage".

[Dirtyhair1]

Hey guys, thanks for your feedback, fix mentioned above has been applied.

Klaviyo - can sync now so all good, no problems there.

Dear Systems - still having problems but changed message, per below:

“Failed to load orders: SOAP-ERROR: Parsing Schema: can't import schema from 'http://schemas.xmlsoap.org/soap/encoding/'”

So will have to look further.

Appreciate all you guys are doing but did the change that caused this need to be implemented in OpenMage 19.4.x?

I have gone through #2399 and #2405

Just wondering if these kinds of changes should be kept in OpenMage 2.0.x?

[sreichel]

Dear Systems - still having problems but changed message, per below:

“Failed to load orders: SOAP-ERROR: Parsing Schema: can't import schema from 'http://schemas.xmlsoap.org/soap/encoding/'”

This URL works for me. I just found this ... https://community.oracle.com/tech/apps-infra/discussion/648011/schemas-xmlsoap-org-is-not-working.

Just wondering if these kinds of changes should be kept in OpenMage 2.0.x?

This issue/error/bug is not related to 19.4 or 20.x versioning at all. This change was made to validate XML files, that would be okay for 19.x too, but we just have not tested it properly.

My question is, why it takes so long to bring a new release. This problem is known for 3 weeks and i dont know when next release is planned. If we break something in latest release, we should be possible to fix it quickly.

[Dirtyhair1]

@sreichel ok got you. Sorry if that came across wrong, but what I meant was, this change has caused issues in previously fine Magento/OpenMage stores. Anyway, didn’t mean to be rude, just commenting.

Further, I have run the process again and now the error message is changed:

“ Failed to load orders: CommunicationException: Error in deserializing body of reply message for operation 'salesOrderList'.”

I understand what you were saying and I wonder how many other stores have been affected like this. One thing to note is we DON’T have “WS-I Compliant” enabled which was mentioned in #2399

I’m sure this will be an easy fix, but yeah, unexpected issue for sure.

[sreichel]

There was nothing wrong or rude :) This problem exists since some days an should be fixed asap.

[ADDISON74]

From what someone said in another post, the cache must be deleted and it still lasts until it is deleted on the other side.

[fballiano]

@sreichel let's merge #2546, then I'll update #2416 and we merge that too and then I'll do a release.

In the meanwhile let's not merge anything else, at least we get that done!

[Dirtyhair1]

From what someone said in another post, the cache must be deleted and it still lasts until it is deleted on the other side.

Yes sorry I went back through those other issues. Have reached out to them to ask for them to clear the cache on their side…who knows how long that will take. Will update once resolved.

[sreichel]

In the meanwhile let's not merge anything else, at least we get that done!

Good idea. This is why i set all my PRs on draft (except from admin css fix an php7.3/intl)

[elidrissidev]

Dear Systems - still having problems but changed message, per below:

“Failed to load orders: SOAP-ERROR: Parsing Schema: can't import schema from 'http://schemas.xmlsoap.org/soap/encoding/'”

So will have to look further.

Just thought I'd share that we also get similar errors from time to time since a few months ago (running an 19.4.14), might be a problem from upstream.

[fballiano]

@elidrissidev if you've a lot of traffic on the API you'll reach the rate limit of calls to the schema.org domain and sadly I think that's nothing we can do about that :-\

[fballiano]

@Dirtyhair1 did it solve?

[elidrissidev]

@fballiano yeah I know, just thought I will mention since he posted he was receiving the same error.

[Dirtyhair1]

@fballiano thanks for checking in. Not good here unfortunately. This could turn into a disaster but we are hoping for the best. We have contacted our inventory system support team numerous times but they have not flushed the wsdl cache, who knows how long it is set to. Their higher level tech support doesn't work weekends apparently.

All our product stock levels are incorrect. All our products are synced in the backend using a "bill of materials" structure, so selling one item affects stock levels of different items. Anyway, I am sure we will get it resolved I am just not sure how the system will handle it when all these orders from 5 days come in and then what that will do to the stock levels of items we have been selling via our storefront and wholesale. Currently we are manually managing things and hoping for the best. Will keep you updated when I know more.

[sreichel]

Maybe this helps ... https://stackoverflow.com/questions/323561/force-re-cache-of-wsdl-in-php

[Dirtyhair1]

Maybe this helps ... https://stackoverflow.com/questions/323561/force-re-cache-of-wsdl-in-php

Cheers!

Reason this is still on-going is I am not a developer, I am the humble store owner, I wish I could implement the actions in the above line. I will get our developers to check it out once they are online, hopefully it does the trick and we can move on.

[Dirtyhair1]

Right, so the inventory guys have replied they don't cache wsdl data and anyway it would have cleared over the weekend. Will have the developers keep digging.

[fballiano]

they may not cache it actively but (for example) php does it anyway:

php --info | grep soap.wsdl_cache_dir

that dir has to be checked for wasdl cache files and cleaned

[luigifab]

We have the same problem, but with another solution.
One of our installed module use the old targetNamespace:

app/code/community/Fooman/Surcharge/etc/wsdl.xml

<definitions xmlns:typens="urn:{{var wsdl.name}}" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas..."
             xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"
             name="{{var wsdl.name}}" targetNamespace="urn:{{var wsdl.name}}">
 
     <types>
        <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:Magento">
             <import namespace="http://schemas.xmlsoap.org/soap/encoding/" schemaLocation="http://schemas....
             <complexType name="salesOrderEntity">
                 <all>

This produce:

PHP Fatal error:  Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL:
  Unexpected WSDL element <schema> in testapi/soap-sales.php:58
Stack trace:
#0 testapi/soap-sales.php(58): SoapClient->__construct()
#1 {main}
  thrown in testapi/soap-sales.php on line 58

So the solution is to replace urn:Magento by urn:OpenMage.

[ADDISON74]

A warning related to this modification is required in the README file.

If there are still extensions that use targetNamespace ="urn:Magento" or wsdl.name , they must be changed ASAP.

[Dirtyhair1]

Yes @ADDISON74 and @luigifab are spot on.

Looks like some of the extensions we had installed were causing this issue due to them using the older targetNamespace.

I am surprised that this was only mentioned in this issue and also #2399, must be a lot of stores out there affected.

[elidrissidev]

A warning related to this modification is required in the README file.

If there are still extensions that use targetNamespace ="urn:Magento" or wsdl.name , they must be changed ASAP.

If that's the case I vote for reverting "OpenMage" to "Magento" change in 1.9.4.x, it's too much of a hassle for such a minor change.

[ADDISON74]

I would not revert, but change from OpenMage to Magento, possibly in both versions.

[elidrissidev]

I would not revert, but change from OpenMage to Magento, possibly in both versions.

Yes, exactly what I meant

[fballiano]

I wouldn’t change it back cause people may already have fixed it and we’ll break it again, let’s push a backend notification, modify the release notes and add a line in readme (imho)

[Dirtyhair1]

I wouldn’t change it back cause people may already have fixed it and we’ll break it again, let’s push a backend notification, modify the release notes and add a line in readme (imho)

I think backend notification is best, I also thought that originally. Just like the “free Ukraine” one that is hard to miss.

[ADDISON74]

Both a notification in the README file and one in the Backend are fine. The latter must be approved quickly (I have no rights there).

[ADDISON74]

Here is the repository https://github.com/OpenMage/Web_Notifications. I think that the major changes that are in progress should be announced through this feature that exists in OpenMage. For example, the minimum requirement for PHP as being 7.3, but also others.

[fballiano]

We have the same problem, but with another solution. One of our installed module use the old targetNamespace:

app/code/community/Fooman/Surcharge/etc/wsdl.xml

<definitions xmlns:typens="urn:{{var wsdl.name}}" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas..."
             xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"
             name="{{var wsdl.name}}" targetNamespace="urn:{{var wsdl.name}}">
 
     <types>
        <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:Magento">
             <import namespace="http://schemas.xmlsoap.org/soap/encoding/" schemaLocation="http://schemas....
             <complexType name="salesOrderEntity">
                 <all>

This produce:

PHP Fatal error:  Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL:
  Unexpected WSDL element <schema> in testapi/soap-sales.php:58
Stack trace:
#0 testapi/soap-sales.php(58): SoapClient->__construct()
#1 {main}
  thrown in testapi/soap-sales.php on line 58

So the solution is to replace urn:Magento by urn:OpenMage.

you could also have replaced with {{var wsdl.name}}", probably cleaner

[fballiano]

I've updated the release notes (in the release page here on github) and created a PR for an update to the README #2559

[sreichel]

I hope it's okay to close this.

[prafullkachhadiya]

This is still an issue with latest version 19.4.18.
We are getting same issue with Klaviyo as mentioned in this issue's description.
I checked the file app/code/core/Mage/Api/etc/wsi.xml and seen that targetNamespace is set to correct value urn:OpenMage.
Is there a way to fix this?

[prafullkachhadiya]

I found that we have wsdl.xml files in our couple of custom plugins we are using.
Fix suggested by @fballiano for replacing urn:Magento with urn:OpenMage all wsdl.xml files of custom or any 3rd party plugins worked for us and fixed the issue with WSDL error.