RAS Adapter lets you see the data coming out of the every operational block. It also has the raw byte log of all bytes received from the RAS and the log of processed messages.
To illustrate, let’s make the chain you created in Tutorial: Creating a Chain process some RAS messages.
We know that the format for the parser you used is “General Purpose Format A,” which is 5 to 7 values, separated by a tilde (~) character. The beginning of the message is marked with ^ and the end is the |.
Let’s send something incompatible first. Open test.txt in a text editor and enter the following string of characters: abcd#random bytes, then save the file.
You will see that the state of the chain hasn’t changed, and nothing has been added to the RAS Messages Log:
Chain is unchanged
However, you will see that new bytes have appeared in Raw Stream window:
New bytes in Raw Stream
Now replace content of the test.txt with the following meaningful string:
^Lana Del Rey~Summertime Sadness~03:54~Song~Test~Summertime Sadness~EMI Music|
…and save the file.
You will see that the colors of the blocks have changed and a new message appears in RAS Messages:
New message in RAS Messages
Now check what data is coming out of each block.
First is the File (double-click the File block):
The file block
You see hex data of the message plus bytes from the previous message that were not parsed and therefore not marked with color. Note the left column with addresses. These addresses correspond to the global stream address shown in the Raw Stream area.
Next the parser:
The Parser
You see key\value pairs. You can think of a key as a variable name. You can assign any name in the configuration. The value is coming from the RAS message. Now it maps the parser variables to the cue point attributes.
Now check to see how it’s done in the mapping processors. The first mapping processor configuration is as follows:
First mapping processor
It maps the value “Test Mount” to the stw_mount attribute of the cue point (for more information, see “Cue Point Attributes”), so this value is always constant.
Then it maps {title}, which is the title variable from the parser, to the cue_title attribute.
Accordingly {length} and {cartNumber} are mapped to cue_time_duration and program_id.
Now check output of mapping processor #1:
Mapping processor output
You see that stw_mount is Test Mount, cue_title is Summertime Sadness (the title key of the parser’s output), cur_time_duration is 03:54 (the length key) and the program_id is Test (the cartNumber key).
Each processor has a white list and a black list, which check the appropriate parser keys. For example, the second mapping processor is skipped because it expected the category to be either COM or BREAK* (* is a wildcard symbol; for more information see VB “Like” Syntax), but it was Song.
Mapping processor #2
The third processor maps a few more fields. The chain you created assumes that all messages containing category=COM or BREAK* are break messages and everything else is a song. It sets appropriate attributes:
Mapping Processor
In the output window of the processor you can see that it added those mapped values to the message (preserving everything that was there before):
Mapping Processor output window
The Time Span processor converts the minute:second time format into milliseconds:
The Time Span processor
And finally the HTTP Output block creates cue point and sends it to the Media Proxy. You can see the cue point in the data window:
HTTP Output Connector
