Technical reference manual

Option 3: use a clientDiscount feed

You will have to set up what we'll call a closed environment, a closed directory (these steps are required in both options 3 and 4), and a clientDiscount file (the centerpiece of this approach). You will also have to take care of a tiny update of the program files. The fifth section covers some common pitfalls and how to avoid them.

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.

How to set up a closed environment

A closed environment is a collection of directory, program and optionally clientDiscount files that, when read by the EDU-DEX server, will only be delivered to specifically targeted clients. In order to hide these files from public view, they are accessed with a GET parameter called key.

The key value will be assigned by EDU-DEX upon registration of a supplier's closed environment. Like the registration of a public environment, the process is an informal one: an email message to info@edudex.nl, stating the location of your directory feed, is sufficient.

From now on, the EDU-DEX servers will visit the registered URL adding the key as a GET parameter. This protocol has several implications:

Since the key is passed as plain text, it is necessary to use SSL (https) for this communication to avoid sniffing.
Per learning provider only one closed environment is in use, servicing all targeted clients.
All links published here will be visited by EDU-DEX appending the key as GET parameter, so they too should use SSL (https).
It is the publisher's responsibility to make sure that key parameters are checked whenever a closed feed is accessed.

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.

Create a closed directory

Suppose (as in all examples in this section) a learning provider with an orgUnitId of pres wishes to target three clients: first, second and third.

Using (in this case) three clientDiscountResources enables institute pres to define discounts for all targeted clients in a very concise and compact way: the only additional information that has to be transferred to EDU-DEX are the three resourceUrls, each pointing to a location where the discount definitions (covered in the next step) can be found.

Attention: in order to keep displayed code readable, even on small screens, some lengthy attributes have been replaced with an ellipsis (...); the full code is avaiable using the Download Code button.

Download code

	
<?xml version="1.0" encoding="utf-8"?>
<edudexDirectory ... >
	<editor>info@presendata.nl</editor>
	<generator>PresenData XML generator 1.4</generator>
	<version>0.90429</version>
	<orgUnitId>pres</orgUnitId>
	<clientDiscountResource>
		<clientId>first</clientId>
		<resourceUrl>https://www.presendata.nl/api/closed/cld_first</resourceUrl>
	</clientDiscountResource>
	<clientDiscountResource>
		<clientId>second</clientId>
		<resourceUrl>https://www.presendata.nl/api/closed/cld_second</resourceUrl>
	</clientDiscountResource>
	<clientDiscountResource>
		<clientId>third</clientId>
		<resourceUrl>https://www.presendata.nl/api/closed/cld_thirdt</resourceUrl>
	</clientDiscountResource>
</edudexDirectory>

EDU-DEX will offer to each client a feed containing the orgUnitId's public offering, after applying the discounts referenced here and further described in the next step. If a programId does not appear in a clientDiscountResource, it will be passed to the targeted organisation but showing pricing information identical to that in the provider's public feed.

This approach, as stated above, makes for a very efficient transfer of discount information. On the downside, a data consumer (first, second and third) has to be aware of the presence of both discounted and non-discounted programs. As step 4 indicates, they can (and should) be identified by the absence or presence of a clientId element.

In the code sample, no programResources follow the clientDiscountResources. Nothing opposes adding them, but there is a pitfall. Every programResource following the clientDiscountResources will override discounts defined earlier! More is available in the last tab.

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.

Create a clientDiscount feed

Suppose (as in all examples in this section) a learning provider with an orgUnitId of pres wishes to target three clients: first, second and third.

The following code sample shows the discounts for client first. Programs PRD-160 and PRD-161 will see a discount of 12.5 percent being applied to the tuition fee, defined in pres's public feed. Additionaly, a discount of €75 will be applied to the tuition fee of program PRD-170 (supposing that the public feed shows the tuition fee in Euros).

Download code

	
<?xml version="1.0" encoding="utf-8"?>
<clientDiscounts ... >
	<editor>info@presendata.nl</editor>
	<expires xsi:nil="true" />
	<format>1.11</format>
	<generator>PresenData XML generator 1.4</generator>
	<lastEdited>2019-02-10T11:00:01</lastEdited>
	<supplier>pres</supplier>
	<client>first</client>
	<discount>
		<amount>12.5</amount>
		<costType>tuition fee</costType>
		<programId>PRD-160</programId>
		<programId>PRD-161</programId>
		<type>percentage</type>
	</discount>
	<discount>
		<amount>75</amount>
		<costType>tuition fee</costType>
		<programId>PRD-170</programId>
		<type>nominal</type>
	</discount>
</clientDiscounts>

For brevity, only the discounts targeting client first are shown. All other clients will need their own clientDiscount document.

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.

Review the program files

Since discounts are applied to the offerings in the provider's public feed, no special interventions are needed in the program documents.

Nevertheless, it couldn't do any harm to review the collection of programs: are all products suitable to be published in both public and closed feeds, or would, in some occasions, a different approach be more suitable?

This would also be an appropriate moment to check whether clientDiscount and public programs collection are in sync: is every programId mentioned in the former, also available in the latter? Better safe than sorry…

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.

Tips, tricks and pitfalls

The most common pitfall, when conveying client specific information, occurs when the two possible options are combined in the one and only directory feed. Nothing opposes combining them, but please take into account that every programResource following the clientDiscountResources will override discounts defined earlier!

By and by, more tips will be added to this section - keep visiting this page!

If anything on this page needs further clarification, don't hesitate to use the Feedback button at the top. We take your comments seriously and will respond within 24 hours.