DX Application Performance Management

Expand all | Collapse all

CEM transaction recording

Jump to Best Answer
  • 1.  CEM transaction recording

    Posted 11-20-2017 11:59 AM

    Hi Team


    I have some http transactions identified by url like these:







    Recording these transactions with CEM, I see always the first part of the url:




    the reason should be that these are fragmented url and only the part to the left of # char is sent to the Web Server.

    How I can differentiate these transactions in CEM ? or I should considerate all of these as only one transaction having the first part of the url ?






  • 2.  Re: CEM transaction recording

    Posted 11-20-2017 12:52 PM

    Dear Antonello:

    FYI, I plan to get to a blog on CEM recording this week . 


    I would like APM Admins/Customers to have a chance first to respond. Have you seen this issue before? If so, what did you do to resolve this ? Or how would you proceed to troubleshoot? Thanks in advance for your help

    Hal German

  • 3.  Re: CEM transaction recording

    Posted 11-20-2017 02:03 PM

    Hi Hal


    I never see this issue before, I really don't think this is a CEM issue but a normal behavior that CEM and similar tools has with a fragmented url.

    From documentation, the only part the client and server exchange during transactions is the resource part of the url:



    and right part is an anchor interpreted by the browser to position in the document, so that the only information that CEM is able to see is the left part of the url, that is always the same.

    If this is true, CEM has no way to differentiate these transactions, the data exchanged between browser and server is always (https://www..../sol-static-comunicazione/index.html) an the logic that differentiate the transactions is on the browser.

    Since it is the first time I meet this situation I wanted a confirmation of my assumption.
    Best Regards

  • 4.  Re: CEM transaction recording
    Best Answer

    Posted 11-21-2017 08:40 AM

    Dear Antonello: 

         Including JMertin  hikodavis  Guenter_Grossberger  Lynn_Williams  to get their take. 

         A # is a valid character in a URL according to the RFC.


    See if adding a # here helps -- Set the Global Delimiter for Path Parameters - CA Application Performance Management - 10.5 - CA Technologies Documentat… 


    If the above suggestion fails and you hear back from no one else, please consider opening a case and providing a TIM log with HTTP parameters/components on 


    Hal German

  • 5.  Re: CEM transaction recording

    Posted 11-22-2017 12:54 PM

    Hi Hal

    I'm waiting an answer from developers to understand how these urls are composed and which application framework they are using, in the mean time I would try your suggestion, but after configuring the # as path parameter delimiter the transation discovery doesn't recognize the transactions ( at this moment I can't do a recording session because I don't have the application account).

    So I want to setup the BT manually for this url:




    to define the path parameter, which is the name and pattern part assuming # as path separator?


    (CEM path parameter screenshot)

    Thanks and Regards


  • 6.  Re: CEM transaction recording

    Posted 11-22-2017 01:21 PM

    Dear Antonello:

     Re-read the docs:


    You can specify more than one delimiter in the Path Parameter Delimiters field. For example, you have two business applications. In one business application, you want to use a semicolon as the delimiter. In another business application, you want to use a colon as the delimiter. You can specify both in the Path Parameter Delimiters field.

    The first matching delimiter is used, and others are ignored.

    So my read is you can set / and #  as path parameter delimiters . But it hits the / and will then ignore the # 


    I am sure there is another case like this in the past . 

  • 7.  Re: CEM transaction recording

    Posted 11-28-2017 05:14 PM

    Hi Hal


    I done other recording sessions and transaction discovery after changing path parameter delimiter to /# or #/ but the url part after the # never appear as parameter in transaction signature.

    Seems that for this application the string after the # is a client-side parameter used by javascript.


    here another example of this kind of url:

    Repurposing the Hash Sign for the New Web 


    Anyway, to be sure, I still waiting an answer from developers.

    The question is whether browser agent can help in this scenario.

    Thanks and Regards