$o_config=ExampleConfig::create(WlRegionSid::US_EAST_1);
  // Retrieve the notepad string (this is a separate step of user sign in process).
  $o_notepad=new NotepadModel($o_config);
  $o_notepad->get();

  // Sign in a user.
  $o_enter=new EnterModel($o_config);
  $o_enter->cookieSet($o_notepad->cookieGet()); // Keep cookies to keep session.
  $o_enter->s_login='/** Put your login here */';
  $o_enter->s_notepad=$o_notepad->s_notepad;
  $o_enter->s_password=$o_notepad->hash('/** Put your password here */');
  $o_enter->post();

After you’ve signed in, you can begin creating the DataModel object necessary to get the report data. You’ll have to set four values to specify the report you want, along with the day, week, or month for which you want it. Once all the values are set, the get() method is called on the object. All our SDK endpoints have at least one method that corresponds to the applicable HTTP method (see HTTP methods). The HTTP method used will indicate what type of operation is performed. In this case, get() means we’ll be retrieving information.

$o_report=new DataModel($o_config);
$o_report->cookieSet($o_notepad->cookieGet()); // Keep cookies to keep session.
$o_report->id_report_group=WlReportGroupSid::DAY;
$o_report->id_report=WlReportSid::PURCHASE_ITEM_ACCRUAL_CASH;
$o_report->k_business='2149'; // Put your business key here.
$o_report->filterSet([
  'dt_date' => '2018-08-21'
]);
$o_report->get();

The example writes all the report’s information to the screen. Different calls will return data in different formats, so it’s important to check the documentation for details and test thoroughly.

$i=0;
foreach($o_report->a_data['a_row'] as $a_row)
{
  $i++;
  echo $i.'. '.$a_row['dt_date'].' '.$a_row['f_total']['m_amount'].' '.$a_row['o_user']['text_name'].' '.$a_row['s_item']."\r\n";
}

The SDK uses exceptions to communicate when an error has occurred. In the example, exceptions are printed to the screen.

catch(WlAssertException $e)
{
  echo $e;
  return;
}
catch(WlUserException $e)
{
  echo $e->getMessage()."\n";
  return;
}

Using the SDK on different servers

WellnessLiving maintains two development servers and two production server clusters.

The two development servers are demo.wellnessliving.com, where our newest code is tested and staging.wellnessliving.com, which has a more stable set of changes.

Our two production server clusters are us.wellnessliving.com and au.wellnessliving.com. These server clusters are used for the United States cluster located in Virginia (United States) and the Asia Pacific cluster located in New South Wales (Australia), respectively.

We try and make calls between the different servers as consistent as possible, but there are small differences with respect to how calls to different servers are made. All our servers use HTTPS.

Keep in mind that when moving to a different server identifiers, keys and code will differ.

Setting Demo or Staging configurations

The default example-config.php contains the following lines:

use WellnessLiving\Config\WlConfigDeveloper;

class ExampleConfig extends WlConfigDeveloper

This lets us know example-config.php is set up to use the Demo and Staging servers. If you wanted to make calls to one of the Production servers, you’d just need to change those lines to the following:

use WellnessLiving\Config\WlConfigProduction;

class ExampleConfig extends WlConfigProduction

Configuring API calls

To configure your API calls to work with a different server, you’ll need to change the URL of the name of the cookies extracted. WellnessLiving uses a persistent and a transient cookie to maintain a session. The names of these cookies are typically abbreviated using the first letter of the server and the cookie type. The persistent cookie on demo is dp and the transient cookie on the Asia Pacific cluster is at.

For more information about cookies used by WellnessLiving, see Cookies.