Knowledge & Connect PHP API, Found object(Account or Answer) but contains only null fields

Question

I'm facing some strange issues when I try to fetch(Connect PHP API)/searchContent(Knowledge Foundation API) following the tutorials/documentations.

Behaviour and output

• Following the documentation, we initialize the API. The function error_get_last() (called after the fetch) states that the core read-only file (we are not allowed to modify it) contains an error:

Array ( [type] => 8 [message] => Undefined index: REDIRECT_URL [file] => /cgi-bin/${interface_name}.cfg/scripts/cp/core/framework/3.2.4/init.php [line] => 246 )

• After initialization, we call the fetch function to retrieve an account. If we give a wrong ID, it returns an error:

Invalid ID: No such Account with ID = 32

Otherwise, furnishing a correct ID returns an Account object with all fields populated as NULL:

object(RightNow\Connect\v1_2\Account)#22 (25) {
  ["ID"]=>
  NULL
  ["LookupName"]=>
  NULL
  ["CreatedTime"]=>
  NULL
  ["UpdatedTime"]=>
  NULL
  ["AccountHierarchy"]=>
  NULL
  ["Attributes"]=>
  NULL
  ["Country"]=>
  NULL
  ["CustomFields"]=>
  NULL
  ["DisplayName"]=>
  NULL
  ["DisplayOrder"]=>
  NULL
  ["EmailNotification"]=>
  NULL
  ["Emails"]=>
  NULL
  ["Login"]=>
  NULL
  /* [...] */
  ["StaffGroup"]=>
  NULL
}

Attempts, workaround and troubleshooting information

1. Configuration: The account used using the InitConnectAPI() has the permissions
2. Initialization: Call to InitConnectAPI() not throwing any exception(added a try - catch block)
3. Call to the fetch function: As said above, the call to RNCPHP\Account::fetch($act_id) finds the account (invalid_id => error) but doesn't manage to populate the fields

4. No exception is thrown on the RNCPHP::fetch($correct_id) call

5. The behaviour is the same when I try to retrieve an answer following a sample example from the Knowledge Foundation API : $token = \RNCK::StartInteraction(...) ; \RNCK::searchContent($token, 'lorem ipsum');

6. Using PHP's SoapClient, I manage to retrieve populated objects. However, It's not part of the standard and a self-call-local-WebService is not a good practice.

Code reproducing the issue

error_reporting(E_ALL);
require_once(get_cfg_var('doc_root') . '/include/ConnectPHP/Connect_init.phph');
InitConnectAPI();
use RightNow\Connect\v1_2 as RNCPHP;
/* [...] */
try
{
  $fetched_acct = RNCPHP\Account::fetch($correct_usr_id);
} catch ( \Exception $e)
{
  echo ($e->getMessage());
}
// Dump part 
echo ("<pre>");
var_dump($fetched_acct);
echo ("</pre>");

// The core's error on which I have no control
print_r(error_get_last());

Questions:

• Have any of you face the same issue ? What is the workaround/fix which would help me solve it ?
• According to the RNCPHP\Account::fetch($correct_usr_id) function behaviour, we can surmise that the issue comes from the 'fields populating' step which might be part of the core (on which I have no power). How am I supposed to deal with this (fetch is static and account doesn't seem abstract) ?
• I tried to use the debug_backtrace() function in order to have some visibility on what may go wrong but it doesn't output relevant information. Is there any way I can get more debug information ?

Thanks in advance,

Answer 1

Oracle Service Cloud uses lazy loading to populate the object variables from queried data using Connect for PHP APIs. When you output the result of an object, it will appear as each variable is empty, per your example. However, if you access the parameter, then it becomes available. This is only an issue when you try to print your object, like this example. Accessing the data should be immediate.

To print your object, like in your example, you would need to iterate through the object variables and access each one first. You could build a helper class to do that through reflection. But, to illustrate with a single field, do the following:

$acct = RNCPHP\Account::fetch($correctId);
$acct->ID;
print_r($acct); // Will now "show" ID, but none of the other fields have been loaded.

In the real world, you probably just want to operate on the data. So, even though you cannot "see" the data in the object, it's there. In the example below, we're accessing the updated time of the account and then performing an action on the object if it meets a condition.

//Set to disabled if last updated < 90 days ago
$acct = RNCPHP\Account::fetch($correctId);
$chkDate = time() - 7776000;
if($acct->UpdatedTime < $chkDate){
    $acct->Attributes->PermanentlyDisabled = true;
    $acct->save(RNCPHP\RNObject::SuppressAll);
}

If you were to print_r the object after the if condition, then you would see the UpdatedTime variable data because it was loaded at the condition check.