Chapter 12 Interfacing with Other Applications

The RealTimeDesigner was built with the purpose of passing data back and forth with other applications. Three particular tools are External Notification, External Variables and the API programming environment.

External Notification refers to what happens with the internal RealTimeDesigner data when the user submits. If this feature is enabled, the data is sent to the URL page you designate. This module works very similar to the “Email & Export Templates” module.

There are just some new fields here, in the “FORMSEND FIELDS” area, which are very important:

1. EXTERNAL FORM: Target URL Page
2. EXTERNAL FORM: Target Port
3. EXTERNAL FORM: Custom Params
4. EXTERNAL FORM: Submit method

“Target URL Page” is essentially where the module sends the data. For example, something like “http://mydomain.com/mypage.php” Basically, the same value you would insert in a form as “action”.
“Target port” is the port you want to address while sending data Normally, for webservers, this port is 80. But it may happen that, for security reasons, you need to address a different port.
“Custom Params” is the place to enter your custom form fields, if needed. If filled, it must be written in querystring form, so something like: param1=abc&param2=123&param3=helloworld etc…
“Submit method” is how to send data If it's set to “Silent”, the checkout will work normally, but you will have your form sent to your processing page also.
If it's set to “Redirect”, the checkout will redirect the user to your processing page, no matter if paypal or quote orders are set. “Redirect” is the option you want to use if, for example, you want to complete the checkout in a cart placed on your systems.

These fields are just like the ones in “Email & Export Templates”. Just fill the field relative to the filed you're interested in. For example, if you want your “form” to send the order# value as “ord_id”, just write “ord_id” in the “ORDER: Order ID” row. - ORDER FIELDS They contains only general order data, so they will be passed only once. 110 - “ITEMS FIELDS” As an order may contain more than one item, the fieldnames you'll write for items will have a postfix indicating the item#. For example: let's say you wrote “productname” as the value for “ITEM: product name”. If the order has only one item, the field will be passed as “productname_1”. If the order has 3 items, the fields will be passed as “productname_1”, “productname_2” and “productname_3”. - “SIDES FIELDS” Again, an item may contain more than one side. So, the fieldnames you'll write for sides will have a postfix indicating the item# and the side#. For example: let's say you wrote - “productname” as the value for “ITEM: product name” - “width” as the value for “SIDE: Inches Width Size” If the order has 2 items, and the first has only one side while the 2nd has 3, the fields will be passed as: “productname_1” “productname_2” “width_1_1” “width_2_1” “width_2_2” “width_2_3” THE “Simulate results with this order id” BUTTON Be sure everything works as expected before deployment. Verify using the SIMULATE button! You can fill the “Order ID” field with a valid ord# you have. Clicking the button, you will see a pop-up that will show all the fieldsnames and values your actual setup would have created on that order submittal. In the pop-up you will also see the option of testing a real send to your page: in case you want to try data collection, you can use that option to really “send” the order just as it would happen while in use.

As you probably guessed, it would be nice for your target script to know the number of items and sides. You can obtain them using the “ORDER: ITEMS # Inside Order” and “ITEM: SIDES # Inside Item” codes. For example: let's say you wrote - “ordnum” as the value for “ORDER: Order ID” - “orddate” as the value for “ORDER: Insert Date” - “itemscount” as the value for “ORDER: ITEMS # Inside Order” - “sidescount” as the value for “ITEM: SIDES # Inside Item” - “productname” as the value for “ITEM: product name” - “width” as the value for “SIDE: Inches Width Size” - “height” as the value for “SIDE: Inches Height Size” - “thumbnail” as the value for “SIDE: GIF thumbnail version” - “pngfile” as the value for “SIDE: Designer size PNG version” The items# will be passed as “itemscount”; the sides# for each item will be passed as “sidescount_1”, “sidescount_2”, etc….

In PHP, it would have been:
*
<?
$allpagevaluesarray=array_merge($_POST, $_GET);
foreach (array_keys($allpagevaluesarray) as $key) {
if (!get_magic_quotes_gpc()) {
$$key=$allpagevaluesarray[$key];
} else {
$$key=stripslashes($allpagevaluesarray[$key]);
}
}
echo ”<center>ORDER #”.$ordnum.”, sent on ”.$orddate.”</center><br>\n”;
echo “there are ”.$itemscount.” items<br>Sizes and images are:<br><br>\n”;
for ($i=1; $i⇐$itemscount; $i++) {
eval ('$sidescount=$sidescount_'.$i.';');
for ($j=1; $j⇐$sidescount; $j++) {
eval ('$width=$width_'.$i.'_'.$j.';');
eval ('$height=$height_'.$i.'_'.$j.';');
eval ('$thumbnail=$thumbnail_'.$i.'_'.$j.';');
eval ('$pngfile=$pngfile_'.$i.'_'.$j.';');
echo “ITEM ”.$i.” SIDE ”.$j.” size: ”.$width.” X ”.$height.”<br>\n”;
echo “ITEM ”.$i.” SIDE ”.$j.” thumbnail: ”.$thumbnail.”<br>\n”;
echo “ITEM ”.$i.” SIDE ”.$j.” pngfile: ”.$pngfile.”<br>\n”;
} echo ”<br>\n”;
}?

*

This is an example where the “Custom Params” fields is useful. As you probably know, the PayPal buttons has to be filled with some param/value pairs. For example, a standard “add to PayPal cart” button has the following fields:
target form page ⇒ https://www.paypal.com/cgi-bin/webscr
item_name ⇒ An item name
amount ⇒ Total order price
add ⇒ 1
cmd ⇒ _cart
business ⇒ yourpaypalemail
currency_code ⇒ USD
bn ⇒ PP-ShopCartBF
no_shipping ⇒ 0
no_note ⇒ 1

To have customers adding orders in a PayPal cart on submittal, you would need to do something like: - “Redirect” as the value of “EXTERNAL FORM: Submit method”
- “https://www.paypal.com/cgi-bin/webscr” as the value for “EXTERNAL FORM: Target Url Page”
- “80” as the value for “EXTERNAL FORM: Target port”
- “item_name” as the value for “ORDER: Order ID”
- “amount” as the value for “ORDER: Total Order Price”

As you can see, you now miss some fields which are not part of the generator: add, cmd, businness, currency_code, bn=PP-ShopCartBF, no_shipping and no_note To pass them to the PayPal script, you can use “Custom Params”. Here's how they should be compiled for this example: add=1&cmd=_cart&businness=yourpaypalemail&currency_code=USD&bn=PPShopCartBF&no_shipping=0&no_note=1

Place all the above as the value for “EXTERNAL FORM: Custom Params” (changing the “yourpaypalemail” value, of course!)
At order submittal a setup like this will simply lead your customer in PayPal's site, with a cart and the designer item added to it. There are various PayPal params to control what should happen there: again, you can set them all in “Custom Params” as described above.

Do you need more control over your users? You need something to track “who's who” in your own system? You want to apply discounts/surcharges only to some defined customer? External Variables do this and lots more.

• STEP 1: DEFINE EXTERNAL VARIABLES AND THEIR RULES

The first step is to define your “library” of accepted variables. To do this, go into the “PRODUCT CONFIGURATOR OPTIONS ⇒ Manage/Define External Variables” area of your admin panel. You will see two main areas here: “Manage/Define External Variables” and “Manage/Define External Variables Rules” Let's start with the “Manage/Define External Variables” area. Here is where you set the variable names that will be accepted by your RTD. For example, let's suppose you want to accept something that defines the customer and a product ID from your system. You would then need to accept 2 variables. Let's say you will name them “customer_id” and “product_id”. So, simply add them. In this first area you can set just the name, and nothing else. Next let 's switch to the “Manage/Define External Variables Rules” area. You will find a brief technical description of how it works in that page too. In this area you can select rules that will be valid if a given match with the passed variable value is satisfied. The possible fields are: Rule Name: a name for the rule, that will be seen only into admin panel Rule Desc (max 255 chars): an optional description that will be shown also to users in case they are “positives” to the rule Source Variable: the external variable of which the value is to be checked for matching Checkvalue: a string that will be used for matching. It can be a regular Perl expression Modifier: a fixed numerical modifier that will be applied to the fields using this rule % Modifier: a percent modifier that will be applied to the fields using this rule A detailed description of regular expressions is beyond the scope of this document, so let's imagine a simple example. Suppose you want a 15% discount rule if the passed “customer_id” is 227. You would then just need to set: Rule Name: discount for user 227 Rule Desc (max 255 chars): hi 227, you and only you have a discount! Source Variable: customer_id Checkvalue: 227 Modifier: 0 % Modifier: -15 More details about how to apply rules can be found on STEP 3 of this chapter

• STEP 2: PASSING VALUES TO RTD AND RETRIEVING THEM ON SUBMITTAL

One of the most interesting uses of external variables is to give you a way to “connect” you own system with RTD. Let's suppose you do have your own ecommerce site, and you link RTD just to create the design. When design is submitted from RTD, you can use the “External Notification on Submittal” to lead your customer back to your site but… how to know what he ordered into RTD? I will try to give a simple example. Let's say you have a product in your own site, and this product has “120” as ID. You would need to link RTD passing this product_id value from your site, and you'd also need RTD to pass this value back to your site with the external notification. As for the example in STEP 1, suppose you have created a “product_id” external variable. To pass an external variable to RTD, you will need to prefix “extvar_” to you variable name. Depending if you are calling RTD using a link (URL METHOD) or a form (FORM METHOD), you would need to pass the variable(s) this way: URL METHOD: add &extvar_product_id=120 to the url FORM METHOD: add <input type=“hidden” name=“extvar_product_id” value=“120”> to your form to RTD When RTD is called this way, and if the variable is in the list of the ones to be accepted (in this case, “product_id”), the passed variable name and value will be stored in the RTD session. This means that, till the customer will not end his session or close his browser, the variable name/value will be remembered by RTD Now: in the “ORDERS ⇒ External Notification on Submittal” area of the admin panel, you will see something new. Not only the usual fields you generally have there, but also a new “EXTERNAL VARIABLES FIELDS” section. It's simply what it seems: you can set a variable name for the external notification, and RTD will return you with that name the value of the passed variable, if any. As for our examples, external notification would now return 120 as the “product_id” external variable value. Note that RTD will keep passing “120” for any submission performed by your customer. External variables are stored in sessions, and their values can be changed only with another call. So: - if you called RTD by add-in &extvar_product_id=120 to the url, 120 will be returned as “product_id” value - if you call again RTD by add-in &extvar_product_id=130 to the url, 120 will be discarded and 130 will be returned as “product_id” value - if you call again RTD by add-in &extvar_product_id= to the url, “product_id” value will simply be nullifyed

• STEP 3: USING AND APPLYING RULES TO THE PRICING MATRIX

And finally, how to see external variables rules in action! Go into the “PRODUCT OPTIONS ⇒Configure Products” area of your admin panel, and select the product you want to apply rules to. Once there, click the “Configure Pricing Structure” link to launch the pricing matrix tool. The button you have to look for is “Apply External Variables Rules”, that appears only if you have defined rules (as explained in STEP 1): click it. In this area you will see a collapsed view of all of your matrices for the selected product. Click the “Expand/Collapse fullview” button for the matrix you want to apply rules to. Depending on how complex your setup is, you may see tons of checkboxes now: don't be scared, it's all easy! Basically, you can enable/disable each of your rules for each of your pricing matrix field. Let's turn back to the example of STEP 1, with a 15% discount if the passed “customer_id” is 227. We do already have a rule, but it's actually applied nowhere. This is the area where you can apply it: just check the “discount for user 227” checkbox for all the fields you want the discount to be applied. If you want the discount to be applied to the global price, just check it for all of the pricing matrix fields. But if, for example, you want to apply the discount to anything but NOT to some add-ons, you just need not to check the rule for the add-ons Sounds complicated, but at the end it isn't! Result from user point of view is now obvious: if he is positive to the rule, all affected pricing fields will be 15% discounted. If you set also a Rule Desc, then he will also see the “hi 227, you and only you have a discount!” note

This is an example where the “Custom Params” fields is useful. As you probably know, the PayPal buttons has to be filled with some param/value pairs. For example, a standard “add to PayPal cart” button has the following fields: target form page ⇒ https://www.paypal.com/cgi-bin/webscr item_name ⇒ An item name amount ⇒ Total order price add ⇒ 1 cmd ⇒ _cart businness ⇒ yourpaypalemail currency_code ⇒ USD bn ⇒ PP-ShopCartBF no_shipping ⇒ 0 no_note ⇒ 1 To have customers adding orders in a PayPal cart on submittal, you would need to do something like: - “Redirect” as the value of “EXTERNAL FORM: Submit method” - “https://www.paypal.com/cgi-bin/webscr” as the value for “EXTERNAL FORM: Target Url Page” - “80” as the value for “EXTERNAL FORM: Target port” - “item_name” as the value for “ORDER: Order ID” - “amount” as the value for “ORDER: Total Order Price” As you can see, you now miss some fields which are not part of the generator: add, cmd, businness, currency_code, bn=PP-ShopCartBF, no_shipping and no_note To pass them to the PayPal script, you can use “Custom Params”. Here's how they should be compiled for this example: add=1&cmd=_cart&businness=yourpaypalemail&currency_code=USD&bn=PPShopCartBF& no_shipping=0&no_note=1 Place all the above as the value for “EXTERNAL FORM: Custom Params” (changing the “yourpaypalemail” value, of course!) At order submittal a setup like this will simply lead your customer in PayPal's site, with a cart and the designer item added to it. There are various PayPal params to control what should happen there: again, you can set them all in “Custom Params” as described above.

The API, Application Programming Interface, is a common way for programmers to interface with the data between applications without the worry of compromising the application code. Below is a technical description of each of the API functions. FUNCTIONS REFERENCE

ACTION 'GetProductCompiledDescription' This action will return an XML file with only one tag, containing your compiled HTML code for a specific Product ID. Required input parameters are: * 'product_id' (INT) - the product id you want to query For example, to query product 123, value should be: 'product_id'=“123” To find your product IDs, refer to the “GetProductIDs” action * 'description' (STRING) - the string containing your live pricing code. Direct link to the help section describing how to compile it is available here. This method will parse only what's included between [MATRIX] and [ENDMATRIX]. FORMAT OF THE XML RESPONSE <RTD_REPLY> <PARSED_DESCRIPTION> string </PARSED_DESCRIPTION> </RTD_REPLY> The returned string uses the same codes of the Optional Long Description for products in your admin panel. ACTION 'GetProductIDs' This action will return an XML file with details and IDs of your products and product categories. * It does not accept any input parameter

FORMAT OF THE XML RESPONSE
<RTD_REPLY>
<CATEGORY_1>
<CATEGORY_NAME> string </CATEGORY_NAME>
<CATEGORY_ID> int </CATEGORY_ID>
<PRODUCT_1>
<PRODUCT_NAME> string </PRODUCT_NAME>
<PRODUCT_ID> int </PRODUCT_ID>
</PRODUCT_1>
<PRODUCT_2>
<PRODUCT_NAME> string </PRODUCT_NAME>
<PRODUCT_ID> int </PRODUCT_ID>
</PRODUCT_2>
[…]
</CATEGORY_1>
<CATEGORY_2>
<CATEGORY_NAME> string </CATEGORY_NAME>
<CATEGORY_ID> int </CATEGORY_ID>
<PRODUCT_1>
<PRODUCT_NAME> string </PRODUCT_NAME>
<PRODUCT_ID> int </PRODUCT_ID>
</PRODUCT_1>
<PRODUCT_2>
<PRODUCT_NAME> string </PRODUCT_NAME>
<PRODUCT_ID> int </PRODUCT_ID>
</PRODUCT_2>
[…]
</CATEGORY_2>
[…]
</RTD_REPLY>

ACTION 'GetOrderDetails' This action will return an XML file with details of a specific Order ID. Required input parameters are: * 'order_id' (INT) - the order # you want to query For example, to query order #123456, value should be: 'order_id'=“123456” FORMAT OF THE XML RESPONSE A single record will be returned. The fields will be all the special codes normally available for templates.

<RTD_REPLY>
<FIELD_1> </FIELD_1>
<FIELD_2> </FIELD_2>
<FIELD_3> </FIELD_3>
[…]
</RTD_REPLY>

You can find details about them in your admin panel, by going in: ORDERS ⇒ Email & Export Templates ⇒ Click here to see all the special codes available ACTION 'GetOrdersByDate' This action will return an XML file with details and IDs of orders placed within a given date range. Required input parameters are: * 'date_start' - starting date in “yyyy-mm-dd” format * 'date_end' - ending date in “yyyy-mm-dd” format Both parameters must be provided. For example, to query orders sent between January 1st and January 15th 2011, values should be:

'date_start'=“2011-01-01”
'date_end'=“2001-01-15”

FORMAT OF THE XML RESPONSE A single record will be returned in this form, with matching order numbers comma-separated:

<RTD_REPLY>
<DATE_START> date </DATE_START>
<DATE_END> date </DATE_END>
<ORDERS_TOTAL> int </ORDERS_TOTAL>
<ORDERS_NEW> int </ORDERS_NEW>
<ORDERS_HOLD> int </ORDERS_HOLD>
<ORDERS_REFUNDED> int </ORDERS_REFUNDED>
<ORDERS_COMPLETED> int </ORDERS_COMPLETED>
<ORDERS_DELETED> int </ORDERS_DELETED>
<MATCHING_ORDER_IDS_TOTAL> string </MATCHING_ORDER_IDS_TOTAL>
<MATCHING_ORDER_IDS_NEW> string </MATCHING_ORDER_IDS_NEW>
<MATCHING_ORDER_IDS_HOLD> string </MATCHING_ORDER_IDS_HOLD>
<MATCHING_ORDER_IDS_REFUNDED> string
</MATCHING_ORDER_IDS_REFUNDED>
<MATCHING_ORDER_IDS_COMPLETED> string
</MATCHING_ORDER_IDS_COMPLETED>
<MATCHING_ORDER_IDS_DELETED> string
</MATCHING_ORDER_IDS_DELETED>
</RTD_REPLY>

ACTION 'GetUserDetails' This action will return an XML file with details of a registered user. Accepted input parameters are: * 'login' - the registered user login name * 'email' - the registered user email * 'user_id' - the registered user ID

Only one of those parameters should be set. If not, only one will be used anyhow. This method does not search for substring, but for perfect matches. So, if the user name you are looking for is 'johnsmith', this method will not return any result if you search by 'john' only. FORMAT OF THE XML RESPONSE if a match is found, a single record will be returned in this form:

<RTD_REPLY>
<USER_ID> int </USER_ID>
<USER_LOGIN> string </USER_LOGIN>
<USER_EMAIL> string </USER_EMAIL>
<USER_REGISTER_DATE> date </USER_REGISTER_DATE>
<USER_LAST_ACCESS> date </USER_LAST_ACCESS>
</RTD_REPLY>

if no matched are found, returned USER_ID will be 0 (zero). ACTION 'GetUserDesigns' This action will return an XML file with details of Saved Designs belonged to a USER ID. Required input parameters are: * 'user_id' - the ID of the registered user For example, to query for user #123456, value should be: 'user_id'=“123456” FORMAT OF THE XML RESPONSE <RTD_REPLY> <DESIGN_1> <DESIGN_ID> int </DESIGN_ID> <DESIGN_PRODUCT_CATEGORY> string </DESIGN_PRODUCT_CATEGORY> <DESIGN_PRODUCT> string </DESIGN_PRODUCT> <DESIGN_INSDATE> date </DESIGN_INSDATE> <DESIGN_THUMB> string </DESIGN_THUMB> <DESIGN_DESIGNERSIZE_JPG> string </DESIGN_DESIGNERSIZE_JPG> <DESIGN_DESIGNERSIZE_PNG> string </DESIGN_DESIGNERSIZE_PNG> <IMPORT_LINK> string </IMPORT_LINK> </DESIGN_1> <DESIGN_2> <DESIGN_ID> int </DESIGN_ID> <DESIGN_PRODUCT_CATEGORY> string </DESIGN_PRODUCT_CATEGORY> <DESIGN_PRODUCT> string </DESIGN_PRODUCT> <DESIGN_INSDATE> date </DESIGN_INSDATE> <DESIGN_THUMB> string </DESIGN_THUMB> <DESIGN_DESIGNERSIZE_JPG> string </DESIGN_DESIGNERSIZE_JPG> <DESIGN_DESIGNERSIZE_PNG> string </DESIGN_DESIGNERSIZE_PNG> <IMPORT_LINK> string </IMPORT_LINK> </DESIGN_2> […] </RTD_REPLY> ACTION 'GetUserCliparts' This action will return an XML file with details of Saved Clip arts belonged to a USER ID. Required input parameters are: * 'user_id' - the ID of the registered user For example, to query for user #123456, value should be: 'user_id'=“123456” FORMAT OF THE XML RESPONSE <RTD_REPLY> <CLIPART_1> <CLIPART_ID> int </CLIPART_ID> <CLIPART_NAME> string </CLIPART_NAME> <CLIPART_INSDATE> date </CLIPART_INSDATE> <CLIPART_UNIQUECOLORS> int </CLIPART_UNIQUECOLORS> <CLIPART_ASPECTRATIO> float </CLIPART_ASPECTRATIO> <CLIPART_THUMB> string </CLIPART_THUMB> <CLIPART_DESIGNERSIZE> string </CLIPART_DESIGNERSIZE> <CLIPART_ORIGINAL> string </CLIPART_ORIGINAL> </CLIPART_1> <CLIPART_2> <CLIPART_ID> int </CLIPART_ID> <CLIPART_NAME> string </CLIPART_NAME> <CLIPART_INSDATE> date </CLIPART_INSDATE> <CLIPART_UNIQUECOLORS> int </CLIPART_UNIQUECOLORS> <CLIPART_ASPECTRATIO> float </CLIPART_ASPECTRATIO> <CLIPART_THUMB> string </CLIPART_THUMB> <CLIPART_DESIGNERSIZE> string </CLIPART_DESIGNERSIZE> <CLIPART_ORIGINAL> string </CLIPART_ORIGINAL> </CLIPART_2> […] </RTD_REPLY> ACTION 'GetUserOrders' This action will return an XML file with details of Saved Clip arts belonged to a USER ID. Required input parameters are: * 'user_id' - the ID of the registered user For example, to query for user #123456, value should be: 'user_id'=“123456” FORMAT OF THE XML RESPONSE A single record will be returned in this form, with order numbers comma-separated: <RTD_REPLY> <USER_ORDER_IDS> string </USER_ORDER_IDS> </RTD_REPLY> ACTION 'CreateNewUser' This action will add a new registered user to your company, and return an XML file with details of the operation. Required input parameters are: * 'login' - the new user's login name * 'email' - the new user's email * 'password' - the new user's password

This action will not register the user if: - the login is already in use - the login is not composed exclusively of letters and/or digits - the login is not at least 5 characters long - the email is already in use - the email is not at least a 6 characters valid formatted email address - the password is not at least 5 characters long FORMAT OF THE XML RESPONSE <RTD_REPLY> <USER_ID> int </USER_ID> <USER_LOGIN> string </USER_LOGIN> <USER_EMAIL> string </USER_EMAIL> <USER_PASSWORD> string </USER_PASSWORD> <USER_REGISTER_DATE> date </USER_REGISTER_DATE> <ERROR> string </ERROR> </RTD_REPLY> if the action fails, returned USER_ID will be 0 (zero) and details will be available in ERROR. ACTION 'EditUserDetails' This action change email and/or password of a registered user, and return an XML file with details of the operation. Required input parameters are: * 'user_id' - the ID of the registered user * 'old_login' - the user's login name * 'old_email' - the user's email * 'new_email' - the new user's email * 'new_password' - the new user's password

Even if the login name cannot be changed, old_login and old_email are required for security reasons. If there will be no match of user_id, old_login and old_email, the action will fail. This action will also not apply any change if: - the new email is already in use by other users - the new email is not at least a 6 characters valid formatted email address - the new password is not empty and not at least 5 characters long The new password field can be empty: in this case, only the email field will be changed. If new password will not be empty and not at least 5 characters long, the action will fail. To keep the current email, just set the value of the new email to be the same os of the old one. FORMAT OF THE XML RESPONSE <RTD_REPLY> <USER_ID> int </USER_ID> <USER_LOGIN> string </USER_LOGIN> <USER_EMAIL> string </USER_EMAIL> <USER_PASSWORD> string </USER_PASSWORD> <ERROR> string </ERROR> </RTD_REPLY> if the action fails, returned USER_ID will be 0 (zero) and details will be available in ERROR. ACTION 'GetUserAutologinUrl' This action will create a link to the RTD which will also log in a specific registered user. Required input parameters are: * 'rtd_link' - any full RTD link you want the user to be redirected to once logged in * 'user_id' - the ID of the registered user FORMAT OF THE XML RESPONSE <RTD_REPLY> <AUTOLOGINURL> string </AUTOLOGINURL> <ERROR> string </ERROR> </RTD_REPLY> if the action fails, returned AUTOLOGINURL will be empty and details will be available in ERROR. If successful, loading the AUTOLOGINURL will auto login the user ID in RTD, and redirect him to the original rtd_link.