What you describe I see folks doing all the time - by accident. Consider the event data illustrated below (ignore the empty lines, they are there only to help make the data more readable). If an Input such as "?Receive text from a TCP Socket"? were configured with the Incoming Data Contains GeoEvent Definition parameter set 'Yes', and the Create Fixed GeoEvent Definitions parameter also set 'Yes', GeoEvent Processor would receive the first event for flight SWA2706 and look for an event definition with that name. Failing to find one it would create a new one. The next event for flight SWA724 would likewise fail to find an existing event definition with that name and create a new one. This process would continue for the first nine events (as the tutorial's data only has nine uniquely identified flights) before existing event definitions would be found by name and used.
You can imagine how, if an analyst did not have significant control over the data being received, that dozens and dozens of event definitions could conceivably get created which differ in name only. I included an illustration of this following the sample event data below. Best practice is to know the format of the event data you expect to receive, create a suitable event definition for that schema, and couple an Input with a specific event definition to receive the expected data. Normally you wouldn"?t expect the event schema of data coming over a dedicated channel to change, and if a provider were sending different classes of events over a single channel you would probably only want to take one particular class of the data being provided. The ability to configure an Input to create event definitions for you based on data discovery is intended to make the product more generic and more user-friendly. But it does not absolve you of your responsibility know and understand the structure of the data you expect to receive.
Dear Sunderman, Thank you for your reply, What I meant here is not the GeoEvent Definition, I will give you an example to more explain my question, Suppose I have a Csv file output, and the following input
My Definition Schema as follow TrackID, Speed, XY, DateTime, etc..
Now the output will save the coming input to some file, say AVL2014-1-1.csv the AVL is the file name prefix, I just want to make the file name prefix dynamic and it will be taken from the input data, in my case the TrackID. if I have TrackID=TRC123Y, the the file name will be TRC123Y-2014-1-1.csv or if I have TrackID=TRC444X, the the file name will be TRC444X-2014-1-1.csv The prefix of the output file is dynamic and taken from the Input it self. this will help to find the output data for TrackID TRC123 in one and separate file.
Thank you for clarifying what you were trying to accomplish. My apologies for misunderstanding...
At the 10.2 / 10.2.1 release, the Output connector supporting logging event data to a CSV system file won't support what you are trying to do dynamically ... unless you know in advance the track IDs of the vehicles being reported by your AVL system.
For example, if you knew that vehicles TRC2478, TRC290, and TRC2812 were expected to report, you could use filters to isolate events for each reporting vehicle and direct those vehicle reports to separate Output connectors. You would need to specifically configure each Output connector to write to either a file or sub-folder dedicated to a specific vehicle.
If the track IDs of the vehicles being reported by your AVL system are not known, then pre-configuration of Output connectors and addressing the need with event filtering is obviously not an option. In that case you would have to develop a custom transport using the GeoEvent Processor SDK. Your custom transport could parse the outbound stream to discover the track ID, determine if a system file/sub-folder had been established for that vehicle, and take appropriate action. The ability for a transport to query an outbound stream for a track id was developed for the 10.2.1 product release.
As a side note, Notifications (e-mail, SMS message, etc.) have been enhanced to enable service designers to retrieve address information from event attribute data in order to dynamically direct notifications to recipients. This capability will be available in the 10.2.2 product scheduled for release in March 2014. If similar capability is important to your successful adoption of GeoEvent Processor when working with system file output, please post the idea to the ArcGIS Ideas portal (http://ideas.arcgis.com). Community support for an idea helps us prioritize future product enhancements.
Be sure when submitting ideas to tag the idea with "GeoEvent Processor" and check the "ArcGIS Server" category.