Archive
TLS 1.2 Update Information and Testing
Yardi TLS Update Will Affect Users of Store Web Services (SWS)
Yardi currently utilizes advanced security protocols when the Store system communicates with third party credit card gateways, email, and other data transfer partners. (This protocol standard is known as Transport Layer Security, or TLS.)
In February 2017, Yardi plans to implement the latest version of TLS (version 1.2) for all secure communications to maintain compliance with our PCI audit. However, this update will affect all users of the Store Web Services (SWS) protocol. This TLS update requires all SWS consumers to verify they can connect to an updated TLS 1.2 database using their current integration software. Credentials to an updated testing environment can be found below.
You must verify that your current software integration can successfully connect to the test environment, or you might be required to upgrade to a newer version before the February TLS update. This applies to both SWS and SWS2 consumers. The eStore application is not affected by this change.
TESTING and VERIFICATION LINK
Development credentials for testing within a QA database using TLS 1.2 protocols: (Note: that this is a temporary testing environment that will be disabled after the February update in production.)
Endpoint: https://dev.centershift.com/qa40/sws.asmx
Username: TLSTestUser
Password: testTLS12
Channel: 999
OrgID: 1000000082
We suggest using the GetOrgList method. This will return information without anything other the the information above.
OR
You can use the new Sandbox end points found at our WSDLs and End Points page. All previous log in credentials will still be valid and you can use any of the methods to test on this server.
If you receive any errors you will need to update to the TLS 1.2 protocol.
If you have any further questions, please contact the Yardi Store Web Service Support team at StoreAPISupport@Yardi.com.
SWS VerifyEcommLogin Method
This allows you to verify the login credentials for a customer. A valid return means that the credentials match a profile and returns the profile information. If it doesn’t match, you will receive an error.
Parameters
Name | DataType | Is Required |
---|---|---|
EmailAddress | String | Required |
Description | The email address of the contact. This acts as their username in eStore/eCommerce. | |
OrgID | Long | Required |
Description | The organization’s ID number. | |
Password | String | Required |
Description | The password/eCommerce code of the contact. |
Returned Parameters
Name | DataType |
---|---|
ACTIVE | String |
Description | Indicates if the eStore/eCommerce account is active (“Y”) or not (“N”). |
ECOMM_ID | Long |
Description | The eCommerce ID number for the contacts online access. |
ORG_ID | Long |
Description | The organization’s ID number. |
PASSWORD | String |
Description | No longer returned. |
USER_NAME | String |
Description | The rental contact’s email address. |
Example
As with every method we need to pass in credentials. We do this with the LookupUser request object.
We will assume you have a web reference, let us name it SWS, in your Visual Studio project. At this point we need to define our objects. We will need the standard service object, a Password request object, and a VerifyEcommLogin response object. We can define and create those like this:
// Create a request and response objects
SWS.WSSoapClient service = new SWS.WSSoapClient();
SWS.Password_Request request = new SWS.Password_Request();
SWS.VerifyEcommLogin_Response response;
Here is a sample code of the request object:
// VerifyEcommLogin Request
request.OrgID = 123456;
request.EmailAddress = "j.doe@b.c";
request.Password = "TestPass";
Finally we can call the method and pass across the login object and the request object to retrieve our requested information. 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.VerifyEcommLogin(user_request, request);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
Note that if something goes wrong the service will respond with an exception. You will want to capture the message in the exception so it can be debugged.
For a full list of methods see SWS Methods.