Hello Guillaume -
I don't think you will be able to use GeoEvent, out-of-the-box, to do what you are trying to do.
While the SOAP protocol does use XML to structure its requests and responses, SOAP messages are not the type of event structure GeoEvent is expecting when XML is used to format event data provided by a real-time data stream. You might configure a 'Poll an External Website for XML' to poll a SOAP service, but the GeoEvent's input will only make a single attempt to parse the response it receives.
When a GeoEvent input polls an external server, it expects a single response to its request, consistent with the architectural style of REST. The data structure, or byte payload, sent to GeoEvent in response to its request is parsed by the input's adapter (a transport is responsible only for delivering the byte payload to the adapter). The adapter expects a specific format (JSON, XML, Delimited Text) and uses a GeoEvent Definition to take attribute values from the response and construct a GeoEvent object.
There is no provision in the event ingest workflow described above to perform multiple actions or operations with a data provider's service. Integrating a SOAP toolkit into your solution to handle the token acquisition and data request is one approach. You also might be able to use the GeoEvent SDK to implement a custom transport which will handle the token acquisition, data request, and session closure. This might be preferable if the SOAP toolkit uses Java.
If you plan on using an external batch script to handle the service request and write the data to a system file for GeoEvent to then ingest, please be aware that there are several problems inherent when working with file-based input. One example is that GeoEvent may attempt to acquire a handle to a file (and begin reading the file) before the external process is finished writing the file to disk. Another example is related to the issue above; GeoEvent needs to read the contents of a file into memory in “chunks” and may encounter a problem emulating a data stream when retrieving blocks of event data from a system file.
Inputs which watch a system folder for files are generally intended to prove that event filtering and real-time analytics you have designed into a GeoEvent Service behave as intended. Files give you the ability to repeatedly send a small sample of event data to GeoEvent to test the behavior of a GeoEvent Service before transitioning to a production configuration in which real-time data feeds arrive via a stream - such as an HTTP/POST from an external server or as a reply to a query made on an external server's URL.
Sorry this reply is coming to you so late.
Hope that it is of some help.
- RJ