You are here: Home Page » Automation » BXF

BXF

Jan 1, 2012 12:00 PM, BY EUGENE DIANA

Follow these steps when implementing the standard.

Logical steps exist to follow when implementing the Broadcast eXchange Format (BXF) standard at a station. As a prerequisite, understanding what BXF is and is not, in tandem with being in accord with the benefits of utilizing it, can only help. This article begins the understanding process by addressing key human factors that may arise if the going gets tough along the way.

The standard

The BXF standard is the outcome of the collaboration of many seasoned clients and vendors in the broadcast industry. The goal was to promote a common language of electronic interaction among systems that mostly already communicate with one another inside the facility. Specifically, BXF includes a combination of a detailed, wide-ranging, well-considered, mostly vendor-agnostic xml schema, and a recommended-practices document. Taken together, the standard proposes structure, sets boundaries and offers patterns that cover many of the possible business functions that require system-integration.

BXF is not a specific, predefined set of messages. Instead, it acts as a framework within which the implementing system can use the logical parts to achieve its desired end. That said, it was built in a way that can guide the user toward an intuitive understanding of that framework's purpose. Additionally, BXF-compliant systems are not required to communicate on a transport-level using any specific protocol (for example, ftp, web-services), nor at any specific interval, nor synchronously or asynchronously, nor using data-encryption or not. It is the payload that is relevant to BXF.

This shows the major branches of the XML schema. The branches consist of many message functions, ranging from managing schedules to performing your cooperating system’s heartbeat. All of these combine to ensure availability no matter the message path.

Figure 1. This shows the major branches of the XML schema. The branches consist of many message functions, ranging from managing schedules to performing your cooperating system’s heartbeat. All of these combine to ensure availability no matter the message path.

The allure of using BXF also involves the inherent capability of providing data-validation for all messaging between systems. The XML schema (“grammar rules” for the BXF language) can be used to ensure that messages are not only structurally sound, but valid in the sense that the data being passed within the XML tags is legitimate given a specific field of data and regardless of the message's path. (See Figure 1.)

For example, suppose the system sends the following message: 12/10/2011. While this may be well-formed XML, it is not consistent with the definition of the xml tag called “SmpteDateTime.” Therefore, when this portion of the message is judged against the schema, it will fail. This means sending systems can take much of the responsibility in sending only “valid” and “well-formed” messages, thereby isolating much of the potential data issues (and their resolution) to the sending system.

Another of the inherent abilities of BXF includes acknowledgement or negative-acknowledgement (ack/nack), which is performed by the receiving system and sent in response to every message. This feature allows systems to give to each other, and end-users, the sense of confidence that their message “made it” to the receiving system, thereby reducing manual communication between departments and further isolating the location of any integration problem.

Understanding business workflow

The next aspect to consider is which business functions will be covered by using BXF. Let's say in order for the traffic/sales system to start building program/break formats, the content's metadata is first needed from the program management system. When traffic finishes adjusting the formats, this information needs to be returned to the program management function.

Program grids are built using the content and its associated formats, and a rough schedule is sent to traffic so media buy contracts can be fulfilled. As media is acquired and prepared for air, the program management routine again refines the schedule for traffic.

These are just a sample of messages between two systems, with the associated ack/nack lifecycle, automated error-responses and appropriate feedback for the end-users. But, the systems are talking the same language, and if one system gets replaced, the next can step in and have a good idea of where things stand if it is already BXF-compliant.

XML schema

Figure 2. This shows a specific, well-defined message path in the XML schema. This layout is advantageous because it allows for easy troubleshooting and/or ensuring the program is running correctly. The highlighted portions correspond to the chart in Figure 1.

Once the business workflow is outlined, the particulars of using the xml schema itself need to be understood. The major branches consist of messages related to transferring content, managing a broadcast schedule, content sub-structure (formats), content metadata, and the configuration of the communicating system…not to mention the ability to perform various types of queries, as well as simply perform a heartbeat of your cooperating system to ensure availability no matter the message path. The steps taken are also well-defined, making it easy to ensure the program is running correctly. (See Figure 2).

An additional detail that is related, but technically beyond the purview of BXF itself, involves what message-transport methodology most suits your software system. Normally, the receiving system is the first to propose how it prefers messages to be sent to it. So, be prepared to be flexible in how your messages get delivered.

In addition, decide how you would prefer your system to receive messages. Will it be a SOAP web-service, or a file-reception system or something else? If it is simple and clearly-defined for the consumer (i.e. the sending system), then you are halfway there.

Be prepared to think about communicating with such systems no longer in a batch-oriented way, but instead, event-by-event. The BXF/xml schema has this perspective built into its core, with an eye on the ability to affect a single event's destiny, in a running play-list for example. Or, the system may need to provide instant feedback to the traffic system via “asrun” once a single event has been executed by automation.

Finally, commit to implementing BXF and doing it right. This involves appreciating some of the technical boundaries and checks and balances that are provided when working with a community-developed xml-based standard.

Realize that BXF is still in its first version, and although people with multiple perspectives have contributed, the community is eager for thoughtful input. The standard benefits from others digging in and proving its mettle. Your situation may deem that an addition or change is needed in order to handle a particular business situation. But, all told, BXF is possible, feasible, rewarding, cool and used by a range of vendors, so you won't be alone.