The merge process within DevTest is designed to merge VSIs not VSMs; hence, the issue with the URI rules.
Please consider the rest of this post as an idea not a recommendation.
What if you could identify differences between the baseline VSM URI rules and the newly generated VSM rules. The analysis would be the basis for adding the new rules to the REST protocol via Workstation's IDE. The VSM XML file contains the rules in the LISTEN Step. If you open the baseline and the new VSM side-by-side in a text editor, you might identify the diffs. An example of the rules stored in a VSM follows:
<dataProtocol>com.itko.lisa.vse.stateful.protocol.rest.RestDataProtocol</dataProtocol>
:
<rules>
<rule> <operation>GET /something/catalog/item/{URLPARAM0}/</operation> </rule>
<rule> <operation>GET /something/catalog/department/</operation> </rule>
<rule> <operation>GET /something/catalog/generic/{URLPARAM0}/</operation> </rule>
<rule> <operation>GET /something/catalog/function/</operation> </rule>
<rule> <operation>GET /somethingElse/catalog/function/{URLPARAM0}/itemGroup/</operation> </rule>
<rule> <operation>GET /somethingElse/catalog/function/{URLPARAM0}/item/</operation>
RISKS:
I would recommend against updating the VSM manually for the following reasons.
1) If you manipulate the VSM outside of DevTest's control (i.e., using a text editor) so you could inject unwanted errors that make the VSM unusable / unreadable.
2) CA reserves the right to change the way we represent all components within the VSM when it is at rest without notification, so you are taking an inherent risk anytime you manipulate a DevTest asset outside of the product's editors (Portal, Workstation, etc.).
Fringe options (risks still apply):
1) Not certain this would help, but perhaps an XML Diff step that compares the baseline VSM to the newly generated VSM would help identify the URI rules changes / additions. Have not attempted this.
2) What if after the merge of the baseline and new VSI, you iterate over the Service and create a raw traffic file. Then replay the raw traffic file through the recorder to reset all URI rules. Problem with this approach is that an additional step is required to create the new baseline service.
Lastly, my earlier concerns about SIManager memory, CPU utilization, and overall run time to create your service still applies -- even if the resulting VSI elminates duplicate transactions.