Hello Simon -
We have an item in our backlog to develop a processor which will do what I think you are describing - take X/Y (or lat/lon) points from an asset's last reported position, treat them as vertices, and use the vertex to update a polyline feature to build a track line.
The Add a feature and Update a Feature outbound connectors will only work with the geometry of the target feature service's feature layer. If the service's feature layer has point geometry, the X/Y (or lat/lon) values received will either add new or update existing point features. If you wanted to use these GEP outputs to update a polyline or polygon the Geometry received with the event would need to be a polyline feature or a polygon feature.
With the 10.2.x releases you might be able to use an Incident Detector processor to build a track line. You would select Polyline for the processor's Geometry Type to configure the processor to build and update a polyline rather than point features. You will also need to make sure that the Incident Type is Cumulative (not PointInTime) ... and set the processor's Expiry Time to a sufficiently high value that the incident will not be automatically closed when no updates are received for a period of time; the default is 300 seconds (5 minutes).
Update: March 2019
I am retracting my advice above to possibly use an Incident Detector processor to build track lines for assets whose positions are being periodically reported as point locations. This approach would rely on the Incident Manager – a server-side component to which you have read-only access through the GeoEvent Server administrative API – to maintain an audit history with a guid, timestamp, and point geometry, for every event record received which satisfies the Incident Detector's opening condition. The polyline geometry output from the Incident Detector processor is built from this audit history. I didn't think about it at the time, but it obvious to me now that maintaining an open/ongoing incident record for all assets you are tracking in order to have Incident Detector output an updated polyline geometry is going to consume more and more RAM until the JVM heap is full. Unless you include a way of periodically closing incidents so that GeoEvent Server can use its ability to maintain a fixed number of "ongoing" and "closed" incidents with a reasonable audit history, using an Incident Detector to build a track line is a very bad idea. Sorry ...
The correct approach to this problem is to use GeoEvent Server to receive and persist locations reported in real-time, allow feature records to accumulate in a feature class, then use GeoAnalytics Server to periodically run a batch analysis and reconstruct tracks. You can read more about that capability here: Reconstruct Tracks
Hope this information helps -
RJ
