Magento API v2 PHP error - php

I'm trying to use SOAP with C#. Magento 1.4.2.
http://localhost/api/v2_soap/?wsdl
Here I can see the method catalogProductCreate
So I try to connect with:
$proxy = new SoapClient('http://localhost/api/v2_soap/?wsdl');
$sessionId = $proxy->login('xxx', 'xxxxxx'); // user with full access
$newProductData = new stdClass();
$newProductData->name = 'Product Name';
$newProductData->description = 'Description';
$newProductData->short_description = 'Short Description';
$newProductData->websites = array(138);
$newProductData->categories = array(7,15);
$newProductData->status = 1;
$newProductData->price = 45;
$newProductData->tax_class_id = 2;
$newProductData->weight = 1;
$result = $proxy->catalogProductCreate(
$sessionId, // Soap Session
'simple', // Product Type
4, // Attribute Set Id (Default)
'product-sku', // Product Sku
$newProductData // Product Data
);
But I receive this output:
Fatal error: Uncaught SoapFault exception: [4] Resource path is not callable.

(details are Magento 1.6.x specific, but techniques, if not details, should be applicable to other versions)
I'm assuming, based on your code sample, that you're using PHP client code to test for the existence of a method, which you can then apply to a call from your C# application?
Assuming that's the case, it means you know PHP, so you'll want to debug this at the Magento soap server PHP level. The only class file that produces that fault is
app/code/core/Mage/Api/Model/Server/Handler/Abstract.php
Either add the following logging temporarily and directly to that file, or drop a copy of the class file in
app/code/local/Mage/Api/Model/Server/Handler/Abstract.php
for a codepool override.
Look in that class file for the following exception
throw new Mage_Api_Exception('resource_path_not_callable')
This is what causes the Magento soap server to response with that fault. There are four places this happens in that file. Add logging calls above each one.
Mage::Log(sprintf('Line %s in file %s',__LINE__, __FILE__));
throw new Mage_Api_Exception('resource_path_not_callable');
This will let you know which fault is causing your problem, from which you can debug and log further. There are two places this can happen (four total in the file, one for a regular call, another for the multi-call).
In order of appearance, with possible causes in the comments.
//here magento is attempting to instantiate the "API Model" that will perform
//the work of your API call. Upon instantiation, it discovers that the model
//doesn't inherit from Mage_Api_Model_Resource_Abstract, and bails.
//This is rare for a non-custom API call, but might be caused by a class rewrite
//gone amuck, or a very hacked system
try {
$model = Mage::getModel($modelName);
if ($model instanceof Mage_Api_Model_Resource_Abstract) {
$model->setResourceConfig($resources->$resourceName);
}
} catch (Exception $e) {
Mage::Log(sprintf('Line %s in file %s',__LINE__, __FILE__));
throw new Mage_Api_Exception('resource_path_not_callable');
}
//Here Magento's been able to instantiate the $model, and is checking if the method is
//callable. If not, it bails. Again, for a standard, stock API call this shouldn't
//be happening, but could be the result of a rewrite gone wrong, or someone hacking an
//api class to make the method non accesible, or someone hacking the method mapping in api.xml
if (is_callable(array(&$model, $method))) {
if (isset($methodInfo->arguments) && ((string)$methodInfo->arguments) == 'array') {
return $model->$method((is_array($args) ? $args : array($args)));
} elseif (!is_array($args)) {
return $model->$method($args);
} else {
return call_user_func_array(array(&$model, $method), $args);
}
} else {
Mage::Log(sprintf('Line %s in file %s',__LINE__, __FILE__));
throw new Mage_Api_Exception('resource_path_not_callable');
}
Figure out why Magento is throwing the API error. It will often point to a type in your soap call, OR point you towards what's been hacked in your PHP system

Making sure that you can she the wsdl resource is correct, but i also ran into that issue when i didnt have the user set up to the correct permissions under the role.

Try to create a webservice user with role and assigned them to a role that has access to ‘ALL’. option in role resources menu in role information.

Put this file into root folder of magento/project so that you can access all the method of magento.
Enjoy the idea...

Related

Checkout API Setup Guide references commands that kill test pages AND do not exist in API

The following code snippets in the Checkout API Setup Guide at
https://docs.connect.squareup.com/payments/checkout/setup references GetID()
cause the page to fail and are not in the API:
$checkoutId = $result->getId();
AND
$checkoutUrl = $result->getCheckoutPageUrl();
In fact, I cannot find reference to those commands anywhere in the technical docs or API reference except on the Setup Guide.
Is the Setup Guide wrong or am I missing something? Is Checkout not fully live? I am not sure why a setup example would not be more supported or reference existing documentation.
Update: In the file provided with the SDK, the file Checkout.md describes that getId() and getCheckoutPageUrl() are getters for protected properties:
Note: All properties are protected and only accessed via getters and setters.
I get that... they just don't seem to work.
Check out the Square PHP SDK documentation on GitHub. Looks like there might be a mistake in that document, I think the code you want is something like:
(they key missing part being a ->getCheckout()
try {
$result = $checkoutClient->createCheckout(
$locationId,
$checkout
);
//Save the checkout ID for verifying transactions
$checkoutId = $result->getCheckout()->getId();
//Get the checkout URL that opens the checkout page.
$checkoutUrl = $result->getCheckout()->getCheckoutPageUrl();
print_r('Complete your transaction: ' + $checkoutUrl);
} catch (Exception $e) {
echo 'Exception when calling CheckoutApi->createCheckout: ', $e->getMessage(), PHP_EOL;
}
Let me know if that doesn't work for you.

PHP OO - How should I handle soft errors in multiple classes?

I apologise if this has already been answered somewhere, but I haven't managed to find an answer so far - maybe I'm searching for the wrong thing!
I am trying to figure out how to handle errors in my OO PHP system, which is used to generate web pages. Hopefully this example will explain what I mean.
Imagine I have a Content class, a Form class and a FormObject class, which hold all the information on page content, web forms and form fields. All classes can run multiple MySQL queries via the DB class.
Users can create new content or forms in the back-end. When they do this, I use the classes to create and store the data in the database.
I also have a System class, which is used to generate the web pages. The System class checks what should be displayed on the front-end, builds the appropriate Content and Form objects, then generates the HTML and outputs it to the screen.
I have some checks for serious errors, which stop the code from going any further. However, the problem is that I want to feed back some "soft errors" to the front-end. For example, maybe the System class builds a Form object, which in-turn builds the fields using the FormObject class. The FormObject class queries the database for a field name, but a field name is not found. So the DB class returns an error. I want to be able to feed back a message to the front-end that says the field name has not been found.
What is the best way to get that "soft error" message back to the System class, so it can be outputted to the front-end?
I realise it is fairly simple in this particular example, but as more classes are added and, crucially, more levels are added, the problem becomes a bit bigger.
One way I thought of doing this was to have an Error class. The system would create an Error object and pass it on to each Content and Form object as they are created. The Form class would pass the same Error object to the FormItem class. Whenever an error is found, it is logged via a method in the Error class. The system can then access the original Error object and output all the errors. However, as the system grows, more classes are added, and more objects are created, it could get quite confusing. Is there a better way?
You might want to use either
something global that all classes can access (e.g. a global variable or a Singleton), or
something that is passed in to all instantiations of classses producing what you call 'soft errors'
to collect such errors. You then want to use whatever you collected and add it to the output in your System class somehow.
To be more specific...
This is an example for the solution using a global:
global $softErrorMessages = array();
class A
{
function sampleFunctionA()
{
// [...]
// some code setting $result to some valid value
// or to false if an error occured
if($result === false) // check for validity
{
global $softErrorMessages;
$softErrorMessages[] = "The sample function A caused a soft error";
return;
}
// [...]
// some code requiring a valid $result
}
}
If you use such a global, you can then easily access it from your System class and put its contents into the right places of your output.
However, if you perform unit tests, you might not want to use globals or global-like solutions (like singletons). So here is an example for an 'error collection' approach:
class ErrorCollector
{
private $errors = array();
function addError($error)
{
$this->errors[] = $error;
}
function getErrors()
{
return $this->errors;
}
}
class A
{
private $errorCollector;
function __construct(/* your additional parameters */, ErrorCollector $errorCollector)
{
// [...]
// additional instantiation stuff
$this->errorCollector = $errorCollector;
}
function sampleFunctionA()
{
// [...]
// some code setting $result to some valid value
// or to false if an error occured
if($result === false) // check for validity
{
$this->errorCollector->addError("The sample function A caused a soft error");
return;
}
// [...]
// some code requiring a valid $result
}
}
You would instantiate the ErrorCollector only once and then pass it to all other class instantiations. Then you let your objects perform their duties (and possibly add soft errors to the ErrorCollector). Once they're done, your System class would then get all the error messages and - again - place them at the right place of your output.
Exceptions is a convenient mechanism to handle errors. FormObject can throw an exception of some SoftErrorException class if DB returns an error. And then in System you are catching this exception and render it to front-end.
class System {
public function showFormAction() {
try {
$form = ... // create a form
$this->renderForm($form);
} catch (SoftErrorException $e) {
$this->handleSoftError($e);
}
}
public function handleSoftError(SoftErrorException $e)
{
// Do whatever you want with exceptions: render it
// $this->renderErrorPage($e->getMessage());
// or collect them and show after
// $this->errors[] = $e;
}
}

API response - gathering errors from included classes

I'm working on a RESTful and am stuck on message gathering for returning to the user. Basically, depending on the options selected, a few classes will be included dynamically. I'll try to provide a real-world break down. We have a HTML-email-tempalte maker - depending on the template chosen a php script will be included. This script may have warnings and I need to pass them "upstream" so that the API can report them. So we have something like this ( -> = includes )
API -> HTMLGenerator -> (dynamically) template-script.php
I need the template-script to be able to report errors to the API controller so the API can report them to the API user. Not sure the best way/practice to accomplish this.
So far , my thoughts are maybe a singleton or session variable that the template-script can add messages to, then the API Controller can report them. Any thoughts?
Main API
REST create by POST to /v1/html basically just:
class API {
require($dynamic_script);
$errors = array('warnings'=>array('warning1',waring2'));
//set http header and return JSON
}
HTMLGenerator
class HTMLGenerator {
//basically some wrappers for junior / non-programmers
function addHeading($text) {
//Add a header and do some checks.
if(strlen($text) > $warnTooLong )
HTMLErrors::addWarning("Message");
}
}
Dynamic Script
$h = new HTMLGenerator();
$h->addHeader($text);
$h->addImage($imageUrl);
You need to use a custom error handler.
See this link - http://php.net/manual/en/function.set-error-handler.php
It allows us to handle a error that might be thrown to capture it and process it. So, when you capture it, you can pass this to the parent class and furthur upstream for further processing.
Global object would work, set_error_handler too, but these are just hacks. The cleanest option is to modify your app elements to do what they are suppose to do - return those messages.
These shouldn't be too hard to do:
function myOldFunction($param1, $param2)
{
// do something
}
modify this way:
function myOldFunction($param1, $param2, array &$messages = array())
{
// do something
$messages[] = 'hey mama, i\'m on stack overflow!';
}
usage:
$messages = array();
myOldFunction(1, 2, $messages);
print_r($messages);

Safely Using Magento's Pre-configuration Events

In the Magento Ecommerce System, there are three events that fire before the system is fully bootstrapped
resource_get_tablename
core_collection_abstract_load_before
core_collection_abstract_load_after
These events also fire after Magento has bootstrapped.
What's a safe and elegant (and maybe event Mage core team blessed) way to detect when Magento has fully bootstrapped so you may safely use these events?
If you attempt to use certain features in the pre-bootstrapped state, the entire request will 404. The best I've come up with (self-link for context) so far is something like this
class Packagename_Modulename_Model_Observer
{
public function observerMethod($observer)
{
$is_safe = true;
try
{
$store = Mage::app()->getSafeStore();
}
catch(Exception $e)
{
$is_safe = false;
}
if(!$is_safe)
{
return;
}
//if we're still here, we could initialize store object
//and should be well into router initialization
}
}
but that's a little unwieldy.
I don't think there is any event tailored for that.
You could add you own and file a pull request / Magento ticket to include a good one.
Until then I think the only way is to use one of the events you found and do some checks on how far Magento is initialized.
Did you try to get Mage::app()->getStores()? This might save you from the Exception catching.

Hooking into the Error processing cycle

I'm building a monitoring solution for logging PHP errors, uncaught exceptions and anything else the user wants to log to a database table. Kind of a replacement for the Monitoring solution in the commercial Zend Server.
I've written a Monitor class which extends Zend_Log and can handle all the mentioned cases.
My aim is to reduce configuration to one place, which would be the Bootstrap. At the moment I'm initializing the monitor like this:
protected function _initMonitor()
{
$config = Zend_Registry::get('config');
$monitorDb = Zend_Db::factory($config->resources->db->adapter, $config->resources->db->params);
$monitor = new Survey_Monitor(new Zend_Log_Writer_Db($monitorDb, 'logEntries'), $config->projectName);
$monitor->registerErrorHandler()->logExceptions();
}
The registerErrorHandler() method enables php error logging to the DB, the logExceptions() method is an extension and just sets a protected flag.
In the ErrorController errorAction I add the following lines:
//use the monitor to log exceptions, if enabled
$monitor = Zend_Registry::get('monitor');
if (TRUE == $monitor->loggingExceptions)
{
$monitor->log($errors->exception);
}
I would like to avoid adding code to the ErrorController though, I'd rather register a plugin dynamically. That would make integration into existing projects easier for the user.
Question: Can I register a controller plugin that uses the postDispatch hook and achieve the same effect? I don't understand what events trigger the errorAction, if there are multiple events at multiple stages of the circuit, would I need to use several hooks?
Register your plugin with stack index 101. Check for exceptions in response object on routeShutdown and postDispatch.
$response = $this->getResponse();
if ($response->isException()) {
$exceptions = $response->getException();
}
to check if exception was thrown inside error handler loop you must place dispatch() in a try-catch block
The accepted answer by Xerkus got me on the right track. I would like to add some more information about my solution, though.
I wrote a Controller Plugin which looks like that:
class Survey_Controller_Plugin_MonitorExceptions extends Zend_Controller_Plugin_Abstract
{
public function postDispatch(Zend_Controller_Request_Abstract $request)
{
$response = $this->getResponse();
$monitor = Zend_Registry::get('monitor');
if ($response->isException())
{
$monitor->log($response);
}
}
}
Note that you get an Array of Zend_Exception instances if you use $response->getException(). After I had understood that, I simply added a foreach loop to my logger method that writes each Exception to log separately.
Now almost everything works as expected. At the moment I still get two identical exceptions logged, which is not what I would expect. I'll have to look into that via another question on SO.

Categories