ERP SOAP Plugin will not find classes in modules

English forums
1

Hello,

EE 5.1.7, ERP 2.13.0

We have developed a module in which we have defined some model classes.
Now we are developping a plugin for SOAP.

When calling oxNew(‘myclass_in_my_module’) in our plugin code we get a Class Not Found exception.
When calling oxNew(‘oxarticle’) everything is fine.

When we call oxNew(‘myclass_in_my_module’) somewhere in the Frontend everything is fine, too.

So it seems that included module classes cannot be referenced by a SOAP ERP plugin.

Of course we can copy our module class in application/models - then the plugin code works.

But this would break the new coding guidelines: put all your own stuff in modules and leave the Oxid file structure untouched.

Is this a bug?
Is this a situation the developers have not considered?

Or do I miss the right way to do it - call a module class from within an ERP plugin?

Any ideas appreciated!

finnegan

2

Hi finnegan,
from the first look it should work as described by you.
If it does not, please contact OXID’s support about this case: https://www.oxid-esales.com/supportrequest

3

salut,


–> files

ceau

4

Oh, I just got it. You did not register the additional files for the autoloader, right?

5

Thanks for all your replies!

,@martin.wegele: no, your assumption is not right. We did register the class in the metadata file of our module in the files section.

As I wrote in my initial posting:

“When we call oxNew(‘myclass_in_my_module’) somewhere in the Frontend everything is fine, too.”

This would not work without registering the module class in the metadata file.

My suspect is that the ERP Soap interface loads only basic shop functionality which is ok for calling Oxid classes but does not walk through the module chain and import module classes. But I have not investigated into the ERP mechanisms deep enough to prove this assumption right or wrong.

If you guys have more thoughts they are most welcome. Otherwise I will file a support request.

finnegan

6

Since the ERP initializes the shop framework with the same bootstrap mechanism as the index.php the oxNew factory should work the same: http://wiki.oxidforge.org/Tutorials/bootstrap_process_refactored_in_4.7_5.0

7

Just saw that you reported this as an issue in the bugtracker: https://bugs.oxid-esales.com/view.php?id=5939
Now I understand what’s going wrong there. :smiley:

8

[QUOTE=finnegan;151002]My suspect is that the ERP Soap interface loads only basic shop functionality which is ok for calling Oxid classes but does not walk through the module chain and import module classes. But I have not investigated into the ERP mechanisms deep enough to prove this assumption right or wrong.

If you guys have more thoughts they are most welcome. Otherwise I will file a support request.

finnegan[/QUOTE]

I investigated a bit and it seems that it is possible to use a workaround to get it working. Did you try to call the oxerpservice script via the url of the subshop? This could be a solution, because the method oxUtilsServer::isCurrentUrl() tries to match the current url with the registered urls of the malls, when some other checkings were failed before (and they will fail in case of ERP).