The best way to achieve this depends on what you want to do with the username/message payload after you have queried the Oracle Db. The answer also assumes that you have a correctly working flat-file schema with the Unique Id being extracted from the flat file into its own element within the schema/resulting message, lets call this field 'UniqueId'. I'm also assuming that there is only a single message per flat-file (if this isn't the case things are a bit more complicated).
Within you flat-file schema, mark the UniqueId element as a Distinguished Field. The will make access to the value easier in an orchestration. Create a Receive Port and Location, with a flat-file disassembler configured to use your flat-file schema.
Next create an orchestration that uses your Receive Port to on-board messages. Within the orchestration, create a new SELECT message for your OracleDb. For the WHERE clause, use the value in the distinguished field from the incoming message - you can use dotted notation here, e.g. FlatFileMsg.UniqueId. This last step will need to be done within a Message Assignment shape within the Construct Message shape of the OracleDb Select message.
If you don't want to go the distinguished field route, you could simply map to the Oracle SELECT message within your orchestration. Either route is acceptable, but I try not to invoke the mapper for simple messages.
Send the Oracle Db SELECT message via a request/response port to your Oracle Db and you should get a User Id returned. Perform whatever action you need to accomplish with the UserId.