# A Framework to Model Bursty Electronic Data Interchange Messages for Queueing Systems +
## 3 Results
### Framework
#### 3.1.1 Feature: Identification-Selection  
Within the log files, there was a lot of structured and unstructured text. We had access to XML elements of a message. We analysed the attributes to understand potential features associated with an EDI message. We hoped to glean if attributes have a relationship with other attributes and identify a structure of the attributes. A hierarchical structure emerged; using this, we built a taxonomy identifying the source of the attributes. Figure 4 displays the results for the different attributes we identified from the log files.  
We note two entities in blue that show where in the logs we found the attributes. The \"Log String Parsing\" entity is where we glean keywords from the structured text sentences, and the \"XML Attributes\" entity is where all the attributes were identified from the XML documents.  
Within the log string parsing entity, only the \"Category\" attribute has a hierarchical dependency on the \"Action\" attribute. When analysing the XML Attributes, we note that every message has an attribute of \"Mode\". \"EventLinked\" and \"DocumentLinked\" are two child attributes of \"Mode\". We found inconsistencies between the child attributes of \"EventLinked\" and \"DocumentLinked\". We observe this in Figure 4. For example, an attribute of \"Ack Status\" is only associated with a \"DocumentLinked\" attribute. It is not associated with an \"EventLinked\" attribute. After investigating the different attributes and looking at their content, we deemed some attributes as being potentially more useful to analyse than others. In the colour grey, we denote the attributes we removed from our initial analysis. We retained 13 attributes. Table 5 is a data dictionary to understand  
Figure 4: Message attribute taxonomy.  
the information behind each selected attribute from the message attribute taxonomy in Figure 4.  
To explain further, some of the important attributes we chose were as follows: the ID attribute, as it was an important attribute that defined the unique id of a message; the queue id allowed us to understand when the message was sent to the queue; and the reference id allowed us to understand which customer was sending the message. We paid particular attention to the action and category attributes, as these were the attributes that defined what type of translation the message was foregoing. Different translations may suffer from longer processing times. We briefly describe the reasons we chose to remove some of the attributes that we denoted in the colour grey:  
* \"Reference ID\" and the \"Sender Alias\" both display the message sender. We chose the \"Reference ID\" over the \"Sender Alias\", as the \"Sender Alias\" is sometimes null and is optional.
* Source file size gives the size of the document before any splitting is done. We noted that this was an optional value and was only enabled on a few inbound protocols.
* The direction of a message was either inbound or outbound. In a previous analysis, the direction had no impact on modelling.
* The \"EventDetails1\" and \"EventDetails2\" are IDs associated with a message. In most cases, using the \"ID\" gave the relevant information required.
* The \"System\" attribute was not used, as the \"System\" always displayed the same \"System\" name for all messages.
* Due to the number of envelopes associated with a message, we did not use the \"Envelope Name\".  
Now that we identified the features for modelling, we now attempt to build out a classification model that may influence the modelling capabilities in Section 3.1.2.