none
Application Trunk RRS feed

  • Question

  • The documentation for the UAG beta and the UAG "Eval RTM" refer to a trunk type of "Application Trunk".   Appears to be directly analogous to the "basic trunk" in IAG.   However appears this option is not available in the Eval RTM.  Where did it go?   Is there a known workaround for creating a basic trunk to publish a single web app AND that does not use HAT?  (maybe using adfs trunk type or using the public host name field newly available in the template called Other Web Application (application specific hostname)")

    I'm working on very first UAG eval for a customer and this is a feature I need...

    Thanks,
    Mark

    Wednesday, January 6, 2010 11:17 PM

Answers

  • Hi Mark !

    The "Application Trunk" does not exist in the RTM version.
    To achieve one-to-one you can create a portal trunk, and then add an application of type "Other Web Application (application specific hostname)" as initial application.
    This template allows you to publish application with "AAM like" functionality (meaning not using classic HAT) with an external hostname of its own.

    HTH,
               Ophir.

    Thursday, January 7, 2010 1:34 PM
    Moderator

All replies


  • Right click on HTTPS and select create new Trunk.
    From there it gives you the option Portal Trunk or Application Trunk.


    Ohhh, RTM sorry about that, I have so many versions of UAG running here at the moment. Trying to remember whats differant in each build is a nightmare.
    Thursday, January 7, 2010 1:19 PM
  • Hi Mark !

    The "Application Trunk" does not exist in the RTM version.
    To achieve one-to-one you can create a portal trunk, and then add an application of type "Other Web Application (application specific hostname)" as initial application.
    This template allows you to publish application with "AAM like" functionality (meaning not using classic HAT) with an external hostname of its own.

    HTH,
               Ophir.

    Thursday, January 7, 2010 1:34 PM
    Moderator
  • Thanks Ophir!

    Thats sort of what I was thinking.  I'll play around with it today and post back here later with an update.

    Thans again,
    Mark
    Thursday, January 7, 2010 3:14 PM
  • Ophir,

    I tried publishing 3 apps in one portal each with their own public url.   2 worked great, 1 did not.   From what I could tell, the one that didn't work (Primavera) seemed to be because the app includes a "base" tag in the header.  Seems the UAG was confused and decided to sign this URL and use the portal URL, instead of using the appropriate public url for the application.  This then posed problems for all the subsequent relative url's that then tried to make requests, as they used the wrong base.  I suspect this is just a bug and can be fixed?

    In the interim I tried several variations of trying to publish the app using both generic templates (one with HAT, and also one with public url).   If I put the one with HAT higher in the application list, I can then seem to get it to work by intially typing in the apps public url, BUT the URL reverts to a signed portal url just after login, which isn't desired.  

    Let me know if you have any other thoughts on the bug encountered or potential workarounds.

    Thanks!,
    Mark
    Thursday, January 7, 2010 4:41 PM
  • I've also found another item which appears to be bug.  Not sure if it is specific to the applications public url or not.

    From outside the request sequence looks like the following in httpwatch:

    request                                                         response

    https://publicurl.company.com                        301 redirect to https://publicurl.company.com/path//

    https://publicurl.company.com/path//              302 redirect to http://publicurl.company.com/path/page.htm

    http://publicurl.company.com/path/page.htm   Error if redirect trunk does not exist


    Note I also see an event in UAG monitor that shows on the request that includes the doubleslash, that the doubleslash is removed and converted to single slash.  This in itself is not a problem, but it appears in the same request/reponse where it removes the double slash, that UAG lets the redirect response back thru to the client with http instead of https.

    I confirmed that if I manually request https://publicurl.company.com/path/  and the UAG does not need to do the doubleslash discard, that the 302 redirect response is properly traslated to https, and hence the subsequent request for the page.htm works fine.

    I'm checking with the application owner to see if they have the capability to remove the double slash and therefore not trigger this bug, but may or may not be possible, and seems long term should be fixed in UAG anyway..

    Thanks,
    Mark
     

    Friday, January 8, 2010 4:56 PM
  • Hi Mark,

    I could not repro any of the issues you mention. Both the BASE and the "//" seems to work fine in my lab.
    This sounds like an application specific issue and not a generic bug, and require much more debugging. I recommend to contact CSS for further investigation...


    Ophir.
    Sunday, January 10, 2010 4:21 PM
    Moderator