Parsing Set Example |
Top Previous Next |
The best way to learn how to set up parsing rules is to do an example. To really learn how this works, we suggest working through the example below. If you're in a hurry and want a completed example of a web form page and parsing rules you can import, see the next section, Web form example with parsing rules.
For iCal file importing, see the separate section under iCal File Support for a Sample iCal Parsing Set -- however going through the step-by-step example here is still good practice if you need to create your own.
E-mail format example
Below is an example of how a reservation request might be E-mailed to you from a form submission on your web site (the full E-mail header information is excluded for simplicity).
E-mail Subject:
Form : Big River Reservation Request (Joe Public)
E-mail Text:
NAME=Joe Public
ADDRESS=4035 Main
ADDRESS2=
CITY=Gardiner
STATE=NY
ZIP=43558
PHONE=8884148384
EMAILADDR=joepublic@aol.com
UNIT_TYPE=Full Hookup : 50A
NIGHTS=3
ARRIVAL=03/10/2005 about 10:00 pm
EXTRA=0301020001
SPECIAL_REQUESTS=Need pet area
OTHER_NOTES=We will arrive after dark
Parsing Set
Of course to start a parsing set definition, go to Maintenance / Online Reservations / Other Online Interfaces / Parsing Sets. Then click "New parsing set definition".
Give it a Set name, for instance "Big River website", to denote where the request is from.
Enter the Identifying text -- in this case, use "Form : Big River Reservation Request" for the identifying text. Web site forms usually let you specify a subject, or at least part of it will be what you specify for the form. The key is to make this subject unique enough that the chances of receiving any other E-mail with that text in it would be very slim. In this case, the fact that the subject starts with "Form : " helps a lot in making it distinctive.
Parsing Rules
Now you can add the rules using the Add New Rule button.
Below are the essential elements to be defined in the parsing rules. Most of it should be straightforward, but notes are added where clarification may be needed. Click Save after each rule to save it and get back to the Parsing Set dialog, then Add New Rule to add the next rule.
Unless otherwise noted, assume that the "Append..." option is not checked, and the "Trim any extra..." option is checked. The "Convert to Mixed..." and "Convert to UPPER..." options are set to your preference.
Rule 1:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: NAME=
Text after field: \r
Number of characters:
Field descriptor: Cust:Cust_First_And_Last (Select, "Customers" data table, "First and Last Name")
This grabs everything on the line following "NAME=" (remember that "\r" is a special escape sequence meaning the end of the line, so it will stop extracting there). The pseudo-field "First and Last Name" is used, so it converts the extracted text into the separate First Name and Last Name customer fields.
Rule 2:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: ADDRESS=
Text after field: \r
Number of characters:
Field descriptor: Cust:Cust_Address_1 (Select, "Customers", "Address Line 1")
This locates the address line and grabs everything on that line after the "ADDRESS=". This might also work if the "Where to look" was set to "After previous field", but sometimes submissions from web site forms don't put fields in order so it's safest to just tell it to look anywhere in the text.
Rules 3 through 8:
These rules will be the same as rule 2, just changing the text before and the field descriptor to get each part of the address, phone number and E-mail address.
Rule 9:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: UNIT_TYPE=
Text after field: :
Number of characters:
Field descriptor: Resv:Resv_Online_Email_Type ("Reservations", "Unit type from E-mail requests")
Note that the "Text after field" entry is actually the colon character ( : ), so we're stopping before the end of the line. While this isn't typical for web forms, in this example we're assuming that the data in this line has the unit type followed by an option for whether they want 50A service. (Presumably if they didn't need 50A service, it would have been something like "Full Hookup : 30A".) So we stop at the colon for the unit type, both to ignore that part for matching the unit type field and also to prepare for getting the 50A option in the next rule.
Also note that we're using the pseudo-field "Unit type from E-mail requests". This is not the same as the Site Type used many other places in Campground Master. It's not a good idea to use the normal Site Type field because if you decide to change the wording in your Site Type pick list, the online reservation parsing wouldn't work anymore. Therefore there is a separate field for each site which specifies the "Unit type" you expect to retrieve from E-mail requests. So when you set up your web form you only need to be sure that the selections offered for this field match up with the values used in this special Site data field.
Rule 10:
Where to look: After previous text
Parsing Action: Set field value if 'Compare to' matches
Text before field:
Text after field: \r
Number of characters:
Compare to: 50A
Set value to: Must Have
Field descriptor: Resv:Attrib_50A (Select, "Reservations", "50A")
As mentioned above, we're expecting this option to follow the unit type, on the same line. Since we already "used" the colon character as the after-text in the previous rule, it won't see it for this rule. So we leave the Text before field blank to start extracting immediately. Then we stop at the end of the line as most other rules do. After any extra spaces are trimmed, the extracted text should be either "30A" or "50A".
The other difference in this rule is that we're not just extracting a value. Since the 50A option is a reservation preference field, it must be set to "Must Have" in order to show that preference. So we use the comparison rule and set the field only if the extracted text is "50A".
Rule 11:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: ARRIVAL=
Text after field: \r
Number of characters: 10
Field descriptor: Resv:Resv_First_Date (Select, "Reservations", "First Night")
We're assuming that the date in this field will always be in the form MM/DD/YYYY, and that it might have an arrival time after it but we don't care to get that part. So since we know the date will be exactly 10 characters, starting immediately after the '=' character, we tell it to extract to the end of the line but just keep the first 10 characters (the date).
Of course this would normally be a little risky since it's not often that date formats can be relied upon to be so precise, but we're just illustrating how the number of characters might be used to specify a maximum, throwing away any extra information.
Rule 12:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: NIGHTS=
Text after field: \r
Number of characters:
Field descriptor: Resv:Resv_Number_Of_Nights (Select, "Reservations", "Number of Nights")
This may seem to be just another extraction rule, but there is something special about it.
Notice that this rule and the previous one are not in the order that the respective form fields appear in the request data. Of course we can normally put a rule like this anywhere since we use "Anywhere in text". However in this case it must be after the rule that gets the First Night, because we're using the "Number of Nights" pseudo-field. This pseudo-field won't work unless the parsing engine already knows the starting date of the reservation, so the rules must be in this order.
Rule 13:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: EXTRA=
Text after field:
Number of characters:2
Field descriptor: Resv:Resv_Adult (Select, "Reservations", "# Adults")
This is an example of getting a precise number of characters, and preparing to continue with more characters in the next rule. We're assuming that the EXTRAS field actually contains a 10-character string of data in the form: AACCPPVVTT, where AA = # adults, CC = # Children, PP = # pets, VV = # extra vehicles, and TT = # extra trailers. So in this rule, we find the starting point and get 2 characters. We leave the after-text blank so it leaves the position pointer on the next character in the data we need (the first 'C' in the format).
Rule 14 through 17:
Where to look: After previous field
Parsing Action: Extract Field value
Text before field:
Text after field:
Number of characters:2
Field descriptor: Resv:Resv_Children through Resv:Resv_Trailers
The next 4 rules continue getting 2 characters for each of the other #-of fields. We're looking "After previous field" for each one, and both the before-text and after-text are blank. So all it does is get 2 characters and move the pointer up 2 characters for the next rule.
Rule 18 through 22:
Repeat rules 13 through 17 exactly, but for the fields Cust:Cust_Adult through Cust:Cust_Trailers
Since we also want to save the #-of information in the customer's details (so we have it for future reservations), we need to extract the same data again for the customer record. Remember to use "Anywhere in text" for the first rule to reset the pointer and look for the "EXTRA=" label again, then continue with "After previous field" for the following ones.
Rule 23:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: SPECIAL_REQUESTS=
Text after field: \r
Number of characters:
Field descriptor: Resv:Resv_Notes (Select, "Reservations", "Notes")
This is straight forward, just putting their special requests in the Notes field so we can see it when processing the reservation. But in this case we have more than one thing that we want to go in the notes, so pay attention to the next couple of rules.
Rule 24:
Where to look: Anywhere in text
Parsing Action: Set Field to a fixed value (always)
Set value to: \x20\\\x20
Field descriptor: Resv:Resv_Notes (Select, "Reservations", "Notes")
Append to any previous text for the same field: CHECKED
Trim any leading and trailing spaces from the value: NOT CHECKED
We're using a fixed-value field here, not to actually set the whole Notes field, but to add text on to it (because the Append option is checked). What we're doing is putting separation between any notes that might be in the special requests item above and the other notes item we'll extract next.
Also note the value we're setting it to. It contains the escape sequence for a "space" character, \x20, at the beginning and end. This will actually convert to " \\ " (note the spaces on each side of the back-slashes). Because we want to keep those spaces, we also need to disable the Trim option.
By the way, the reason we're using this odd " \\ " separator is because that's recognized by the program as a new-line when viewing the Notes. Campground Master data fields can't normally contain actual carriage-return characters (and they would be stripped out anyway), so this special sequence is used. For instance, when you go to Reservation Details you may see the \\ characters like this in the Notes line, but if you click the "..." button next to the Notes field, a multi-line window will open. In there, the lines will be separated the way we want them. This also happens when you double-click on a reservation in the Rack to show the Quick-info.
Rule 25:
Where to look: Anywhere in text
Parsing Action: Extract Field value
Text before field: OTHER_NOTES=
Text after field: \r
Number of characters:
Field descriptor: Resv:Resv_Notes (Select, "Reservations" Data table, "Notes")
Append to any previous text for the same field: CHECKED
Again we're basically just extracting text, but telling it to just append the extracted text to the end of the Notes field instead of replacing it. So now we'll have the results of the last 3 rules all in the single Notes field.
Testing the Rules
If you're following along and entering the rules above, you can use the Save & Test Parsing Set function to see if they've been entered right. If you're viewing this documentation online or through the Help function, you can just copy the sample request above and paste it into the test window. Otherwise you'll need to type it in. Don't worry, it will save what you type so you don't have to do it over each time you want to test it.