Call to a member function get() on null

[tylerr92]

Hello,

I am trying to get your package running as a proof of concept. I am getting the error Call to a member function get() on null when I try to make the call from the readme

My code:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use NetSuite\Classes\GetRequest;
use NetSuite\Classes\RecordRef;

class HomeController extends Controller
{

    public function index ()
    {
        $myWebService =  app('Usulix\NetSuite\NetSuiteService')->getService();

        $request = new GetRequest();
        $request->baseRef = new RecordRef();
        $request->baseRef->internalId = "57190";
        $request->baseRef->type = "customer";

        $getResponse = $myWebService->get($request);

        if ( ! $getResponse->readResponse->status->isSuccess) {
            echo "GET ERROR";
        } else {
            $customer = $getResponse->readResponse->record;
        }

        dd($customer);
    }
}

My ENV

NETSUITE_ENDPOINT=2018_2
NETSUITE_WEBSERVICES_HOST=https://webservices.sandbox.netsuite.com
NETSUITE_ACCOUNT=*******_SB1
NETSUITE_CONSUMER_KEY=***********
NETSUITE_CONSUMER_SECRET=***********
NETSUITE_TOKEN=***********
NETSUITE_TOKEN_SECRET=***********

I am using a token and secret for a full access user

Are you able to provide any direction as to why I am getting null out of $myWebService = app('Usulix\NetSuite\NetSuiteService')->getService();

[usulix]

Looks like the cal to the Laravel inversion of control container is not finding the service

did you add one or both service providers to config/app.php ?

   'providers' => [
   /*
   * Laravel Framework Service Providers...
   
   Usulix\NetSuite\Providers\NetSuiteServiceProvider::class,
   Usulix\NetSuite\Providers\NetSuiteApiProvider::class,

These providers register the services with the container :

    public function register()
    {
        $this->logger = new Logger('name');
        $this->app->singleton('Usulix\NetSuite\NetSuiteApi', function ($app) {
            return new NetSuiteApi($this->logger, (new ConfigApiService($this->logger))->getConfig());
        });
    }

so, you can call

app('Usulix\NetSuite\NetSuiteService')
and get the service instead of null

As for the token and token_secret, I do not have access to a netsuite account anymore, but as I recall, when you create access tokens, you should get these as well as your consumer_key and consumer_secret

---

upon a quick Google, yes... consumer_key and secret come from an integration request creation... and then you generate tokens for that integration

https://community.boomi.com/s/article/howtoconfigurethenetsuiteconnectionwithtokenbasedauthentication

Best of luck, and I have not updated / reviewed this in a while, but I am still using it in production without error - as far as I know...

[tylerr92]

Thanks for getting back to me. I found the tokens finally. Now I am getting

Psy Shell v0.9.9 (PHP 7.1.25 — cli) by Justin Hileman
>>> use NetSuite\Classes\GetRequest;
>>> use NetSuite\Classes\RecordRef;
>>> $myWebService =  app('Usulix\NetSuite\NetSuiteService')->getService();
[2019-03-06 22:10:53] name.INFO: Config settings for netsuite service in .env appear to be incomplete [] []
[2019-03-06 22:10:53] name.INFO: NetSuiteService requested but config not available. [] []
=> null

When I try to use this with Laravel Tinker. It looks like it something is wrong with the ENV settings. I have of course run php artisan config:cache

Yes I did add the providers to config/app.php

[usulix]

I have not tried it with Tinker. I will try it and see what I get.

[usulix]

I discovered that in running from tinker and from phpunit, getenv() returns the environment variables of your local shell.

I updated to use Laravel's env() ... but I recall initially having issues with that if the values were in the .env file

This may work with the values in .env if not, then you would have to set them in some other way .. ie in phpunit with values or by directly exporting them for Tinker... if that will get them into the Tinker environment

see laravel/framework#8191

and I love GrahamCampbell's comment... which is a very concise embodiment of the reason I went more in the Vue.js / Node direction :-)