Yes, I concur with Prema that it is worthwhile to investigate if you really need the data from the security header to be able to select the correct response for an incoming request. The simplest solutions are always the best.
But in case you cannot go with simplest, some thoughts below:
What intrigues me is that you get requests which can have these different security structures. Code executes always in the same order, so I guess you have 2 different kinds of clients calling this virtual server? Do you have information on the clients? Is it the same component that produces these 2 different WS Security structures? If not then you could think of providing 2 virtual services, basically copies of each other, except for the configuration of the WS Security DPH.
Let me first explain that best practice would be to place all your data protocol handlers in the Listen step. This is where they functionally belong where they work on the incoming request object (focusing primarily on the operation and the arguments) and transform that object more and more towards a structure that is similar to the structure of the transactions defined in the virtual service image such that proper matching can take place.
But a DPH is just a filter, you need to tell it what it needs to filter to do its job – i.e. a lisa.vse.request object – and as such you can add it to a Do Nothing step just as well.
1. Listen step
If securityAttributeOrder == “Signature-TimeStamp” then go to 2.a
If securityAttributeOrder == “TimeStamp-Signature” then go to 2.b
(this should never happen)
2.a. Do Nothing step
Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)
Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)
2.a. Do Nothing step
Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)
Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)
Hope this helps,
Cheers,
Danny