Event Reference

Welcome to the event reference section. Here, you'll learn about the required and optional properties of events, and the different ways events can be constructed. This section specifically address Product based events, which would include a Product serial number.

Required Elements

At a minimum, each event you construct should include the following elements:

• Product: A product with a serial number.
• Timestamp: The date and time the event took place, in UTC format.
• Machine Name: Name of the client or machine generating the data.
• Result: A overall result of the event.

Product

A product is composed of the following optional and required properties:

Status

The product's status property represents the overall result of the event. There are four possible values that can be used to describe Status:

• PASS: Product was tested and passed the test.
• FAIL: Product was tested and failed the test.
• ERROR: An error occurred during the test. The test may not have been completed.
• LOG: No test was performed during this event.

Note that each event also must be associated with one of the Routes you defined in the Doodlebase Configure App. This information, however, is not part of the XML itself, rather, you will define it with your authentication header using a RouteKey and Password.

Event Elements

Elements are the building blocks of your event. You can think of elements as the actions that describe what happened during the event. You can optionally include the following elements to describe your event:

• Variables: Numeric measurements.
• Attributes: Non-Numeric measurements.
• Components: Components of the product that were added during the event.
• Symptoms: Errors or issue descriptions.
• Files: Images, audio, video, and/or files.

Depending on the nature of your event, you'll chose different combinations of these elements. For example, an assembly step may only utilize components, whereas a test step may focus on variables, attributes, and symptoms.

Element Reference

Refer to the element reference below to understand the required and optional properties that make up each element.

Variable

Variables represent numeric measurements. Typically, variables are values measured during test steps such as resistance or capacitance. Variables may or may not contain specification limits, which are used later for Statistical Process Control Analysis.

Attribute

Attributes represent non-numeric measurements. Attributes have a wide range of use cases. Typical uses of attributes include attributes about the client such as software version test mode, or can be other useful information such as operator name or the author of the test program running the test.

Component

Components are Parts/Items/Products that are attached to a parent product. You should only include components in your event if they were added during the current event.

Any component with a serial number is also added as a product. This means you have the ability to make hierarchical relationships between your products and components when querying your data.

Symptom

Symptoms are descriptions of errors or failures that occurred during the event. They are used to construct defect Pareto reports, and are typically involved during manufacturing test process steps. Symptoms can describe errors, product defects, or test software exceptions.

Symptom Category: Note that symptom category typically plays an important role in Pareto charts. Usually, engineers prefer to group common symptoms by a related code or category of failure/error. This can be helpful if a reporting user wishes to construct a Pareto chart based on common categories of symptoms. In this case, use symptom category property to make this type of visual possible.

File

You can include one or more files such as images, audio, pdf documents, or any binary file type with an event. Files are not included in the XML itself. Instead, you include them in a ZIP folder with the XML file you created. You then send this ZIP file in your HTTP Post request to your Network.

For more information on sending files, see the Load Concepts section of the documentation.

Shared Properties

Some properties play a special role and are shared among multiple elements. Read the following information to learn how they can be utilized for reporting and root cause analysis.

Status

You'll notice that variables and attributes contain a status property. This is used to describe the outcome of the value. This is important for root cause analysis. For example, if an event fails as a whole, there may be multiple measurements that failed or encountered an error within the event.

Run

You'll also notice that variables and attributes have a run property. Run is an optional property you can use to describe the sequence in which variables and attributes were measured. For example, test systems typically go through a series of "test steps." Using the run property to identify the sequence of the test the measurement is a part of. Run is particularly helpful in diagnosing Test Program errors.

Category

Use the category property to group related variables and attributes together. This is beneficial when constructing queries, because a user can specify a single categorical value to pull all related variables and attributes.

Next Steps

Now, you should have a foundation understanding of the different ways you can construct events, and how you can map your raw data to the event format. See the Load > Transformer page to understand how Transformer helps you load your data, or, if you already have loaded data, see the View > Concepts section of the documentation.