Issues with SOAP Api service URL in OpenMage v20.2.0

[m-overlund]

I was speaking to Klaviyo support, as i had issues after updating OpenMage.

Got it fixed, enabled Mage_Tag again, which they used.
But they say OpenMage returns the wrong ServiceUrl and told me to change it.

(10:30:45 AM) Okay, I am looking into this further now for you
(10:36:54 AM) It looks like Magento is pulling the wrong SOAP API endpoint url when it generates the wsdl file on your Magento instance.
Please go to /app/code/core/Mage/Api/Model/Wsdl/Config/Base.php around line 53 you will see something like:
 
// set up default WSDL template variables $this->_wsdlVariables =newVarien_Object( array('name'=>'Magento', 'url'=> htmlspecialchars(Mage::getUrl('*/*/*', array('_query'=> $queryParams))) ) );
 
Change this:
Mage::getUrl('*/*/*'...

To this:
Mage::getUrl('api/v2_soap/index'...

So after changing the getServiceUrl part to:
'url' => Mage::helper('api')->getServiceUrl('api/v2_soap/index', ['_query' => $queryParams], true)
( https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Wsdl/Config/Base.php#L48 )

It works again.

Is this an error in OpenMage v20.2.0?

Haven't had issues with other API connected services.

(i do patch Urn namespace in composer, but it shouldn't affect this i believe)
https://github.com/BMB-ApS/composer-patches/blob/main/openmage-api-urn-namespace.patch

[empiricompany]

what extension do you use for Klaviyo integration? Did you search in all files to see if there are any extensions that use the old namespace?

[empiricompany]

but there is already in README or do you mean in the website?

[addison74]

You are right. I forgot how much was discussed on this topic.

[m-overlund]

@empiricompany No it's not on Github.
But it seems to be available to public: https://www.klaviyo.com/media/downloads/MagentoKlaviyo-Latest.tgz
Hasn't been updated since Magento sunset.

@addison74 I have already written last in the post, that I've reverted the namespace change and provided the patch :) (due to our WMS etc., not supporting another namespace than Magento).
API is working fine in general - all modules are checked for the namespace change.

The Klaviyo module does not contain a wsi / wsdl xml file.

[empiricompany]

@m-overlund Ah, okay, I didn't understand the problem well sorry. More details are needed about the web service call that invokes Kaviyo to see if there is any inconsistency.
If there are no issues with the web services, it is strange that they are incompatible with the new namespace because web services are designed to facilitate communication between two heterogeneous systems while hiding the specific systems involved. Therefore, if it is a specific case with Kaviyo, they could be asked to create a new service for OpenMage (I saw in the extension that they register 'service' => 'magento').

class Klaviyo_Reclaim_Model_Tracker {
    public $api_key;
    public $host = 'https://a.klaviyo.com/';

    protected $TRACK_ONCE_KEY = '__track_once__';
    
    public function __construct($api_key) {
        $this->api_key = $api_key;
    }
    
    function track($event, $customer_properties=array(), $properties=array(), $timestamp=NULL) {
        if ((!array_key_exists('$email', $customer_properties) || empty($customer_properties['$email']))
            && (!array_key_exists('$id', $customer_properties) || empty($customer_properties['$id']))) {
            
            throw new Exception('You must identify a user by email or ID.');
        }

        $params = array(
            'token' => $this->api_key,
            'service' => 'magento',
            'event' => $event,
            'properties' => $properties,
            'customer_properties' => $customer_properties
        );

[alexh-swdev]

I had the same error on OM 20.2.0 in a self-written C# tool. (Kinda forgot to mention it here - despite (or because? :) ) the customer stumbeled upon it on a quite stressful day).

It required two tasks to be fixed:

• in OM .htaccess enable light API calls processing
• change the endpoint address in the client from .../api/v2_soap/index/ to .../api.php?type=v2_soap

Another self-written PHP (Symfony) tool did not show this problem to that extent. (Enabling light API calls processing was enough there)

/Edit: But still the question: Was this inteded or should someone create an issue?