Archive
SWS GetAvailableDiscounts Method
Retrieves a collection of discount data for a specified rental item. This is specific to discounts and promotions, it does not include credits.
Parameters
| Name | DataType | Is Required |
|---|---|---|
| OrgID | Long | Required |
| Description | The organization’s ID number. | |
| RentalID | Long | Optional* |
| Description | The Rental_ID for which to retrieve possible discounts. Use this for existing rentals. This is returned when using the MakeReservation method or can be searched for using the SearchBy method. * Either the Rental_ID or Unit_ID is required. |
|
| SiteID | Long | Required |
| Description | The site’s ID number. This can be found using the GetSiteList method. | |
| UnitID | Long | Optional* |
| Description | The unit’s ID number. This is returned when you use any of the GetSiteUnitData calls and is maintained through rentals. * Either the Rental_ID or Unit_ID is required. |
|
Returned Parameters
| Name | DataType |
|---|---|
| APPL_BEST_PCD | APPL_BEST_PCD |
| Description | Returns the object containing the data for the method call. |
Example
As with every method we need to pass in credentials. We do this with the LookupUser request object.
We’ll assume you’ve got a web reference, let’s name it SWS, in your Visual Studio project. At this point we need to our objects. We’ll need the standard service object, a GetAvailableDiscounts request object and a GetAvailableDiscounts response object. We can define and create those like this:
// Create a request and response objects
SWS.WSSoapClient service = new SWS.WSSoapClient();
SWS.GetAvailableDiscounts_Request request = new SWS.GetAvailableDiscounts_Request();
SWS.GetAvailableDiscounts_Response response;
Here’s my sample code of the Request object.
// GetAvailableDiscounts Request for an available unit
request.OrgID = 123456;
request.SiteID = 123456;
request.UnitID = 123456;
Finally we can call the method and pass across the login object and the request object to retrieve our discounts. It’s a good idea to do this in a Try Catch block.
// Call the method that will load the response object
try
{
response = service.GetAvailableDiscounts(user_request,request);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
Note that if something goes wrong the service will respond with an exception. You’ll want to take a look at that message returned in that exception so it can be debugged.
For a full list of methods see SWS Methods.
Software Testing
Software testing is an integral part of the software development process. For every code change made, every line updated, there are multiple testing steps to ensure its validity. Long before the code is released, it is put through a rigorous exercise routine and in various environments.
First the code is reviewed by another developer. This is called ‘peer review’. By doing this more than one set of eyes are lent to the line changes or updates. This serves two purposes as it allows for double checking the work, but also an opportunity to learn from each other.
Once the code has been reviewed, it is built into a development environment. This is where it is tested for the application. Changes in the code are tested for compatibility with the platform. This lets us know that the updates are fully compatible and did not conflict with any of the existing code. When the development environment testing is completed, the code changes are approved and the code is then pushed to a QA environment.
In the QA environment, the same testing is done but on a larger scale. Many more sets of eyes can view and review the QA environment. This allows for a more thorough testing platform across the board. The code will stay in the QA environment for anywhere from a week to two weeks depending on the type of code it is or the need for more extensive testing.
Once the code has passed QA testing, it is then pushed to a sandbox platform. This platform is our general beta platform in which clients and companies may test our software. Again it is available for a broader testing scope. The code will stay in sandbox for approximately two weeks before being pushed to production.
If any errors or defects in the code are found during this process, the code is pulled down from the testing platform and corrected. After which the testing routine starts all over again.
For back end code that is updated or changed and has passed peer review but is not available for UI testing, the testing process is slightly different. The code is initially processed through a what are called unit tests and SOAP tests. These tests allow the developers to know if the code written will perform as expected. These tests are generally used for SWS and method updates and are generally not tested in the same way as UI changes would be. The unit and SOAP tests target the specific SWS or method code identifying the parameters and string types. The code is then tested to ensure it calls and returns the correct data.
Once the back end code is tested and verified, it then follows the same testing flow from development to production as any other code. The SOAP and unit testing is repeated in each of the platforms by many different sets of eyes. This again allows for more thorough testing. If at any time data is not returned correctly, the code is pulled, re-written and then tested all over again.
Yardi Store Developer eXchange 