The more I look at this (and I've spent a while at it now with SQL Profiler) the less certain I am that you'll be able to use a stored proc. The problem is two-fold and lies in the fact that the external mapper uses a parameterised query (this is good practice and helps prevent sql injection etc) and adds a variable number of parameters based on some internal logic, this isn't a problem when using dynamic sql as the parameters just get added to the in clause "where getter in (@p1, @p2, @p3...)", however, when you define a stored proc you declare the parameters up front, if the number of parameters from the mapper was fixed, this would be ok but it's variable. The best bet and one referenced in Arrays and Lists in SQL Server 2008 was to somehow force the connector to call the stored proc with the parameters passed as a single parameter formatted as a comma separated list, then split the list and insert to a temporary table using a udf and use the temporary table in a join etc. I can't see any way to do this. My previous answer of using a TVP doesn't work as it's not supported by the JDBC driver and it's not the way the mapper adds the parameters anyway. The last option is that if we knew the upper limit of the number of parameters that were being passed by the mapper we could declare that number of parameters in the stored proc and assign them a default value of NULL making them optional, insert the non-null variable to a temp table and join on the temporary table but that's subject to breaking if HP change the number of parameters etc.
If you're being asked to use a stored proc as a security measure i.e. the DBA doesn't want to give you access to the base table to run arbitrary queries perhaps you could come to a compromise by using a view and querying this dynamically instead?