Robert, We saw this in the v6.3 Mid-Tier (all releases/patches) using Apache/1.3.31 with ServletExec web server on Solaris.
I see the root issue as: ARS's naming conventions are more broad than the "web" URL standards. ARS's Mid-Tier design calls for the "ARS Form name", and View names to be part of the URL. ( Which produces the natural conflict due to the naming standard differences.) BMC's answer is basically: If you change the ARS names to be "URL" compliant, then things should be ok. My response: That makes total sense. However, we purchased an application set that "does not require us to know how to do web development". So why do we need to know what a URL even is? Why does the out of the box application not account for such things already? How supported will the next upgrade be after you changed the names of Forms and Views? I think I see two ways to try to fix this: I can imagine that the Mid-Tier could be made "smart enough" to be able to deal with the current Mid-Tier URL structures. Likely requiring better encoding and decoding techniques from inside ARS packaged clients. The "WebAlias" concept also springs to mind, but they dropped support for that. Hum. They obviously have something better in mind, maybe we will see it in v8? But until then, we remain "broke" for forms that have "bad URL names". I can also image that the Mid-Tier URL structures could be altered to allow the values to be pass as parameters to avoid the URL issues too. Did we maybe miss this issue in a "known issues" list? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 3/14/07, Robert Molenda <[EMAIL PROTECTED]> wrote:
Environment(s)... ITSM 7 Out of the Box (all apps) Windowz 2003 SQL 2005 JRE 5 IIS 6 ServletExec (on sandbox) and Tomcat (on Dev/Test/Prod) Scenario: There are many views in ITSM 7 which have the slash - / - character in them. These work just fine in WUT, but on WEB they can fail. Here is the catch, they work FINE with IIS + ServeltExec, but FAIL with IIS + TOMCAT... It seems the IIS + TOMCAT configuration takes the %3A (Ascii for /) and reconvert it back into the / and well, that just gets the directory name(s) all wacked out and poof 404 error page not found :-( BMC Response>> We have seen this issue recently with other customers. The simple workaround is to change the view name and remove the / from it and all the associated workflow. I am searching for the Defect regarding this issue and if I am unable to locate it, I'll create a new defect and enter your well detailed steps. They have created a NEW BUG ID: SW00262100 SO, if you have IIS6 + TOMCAT you can reference the above # and bump the customer reference count up :-) so maybe it hits some ITSM 7 patch by the time we go to production... yah' right I will not hold my breath :-( <SOAPBOX> Same ole' thread of "who is testing this product" BMC or their consumers? Same ole' thread about "known development standards and things NOT to do", however the admin tool allows you to do. Same ole' thread about "create your own fix" (and please let us have it :-) )... Yes, we know the work around, we are not "stupid" but if this is the answer, then include the Workflow Analysis Tool FREE with your ADMIN TOOL! Without "extra tools", how should one tell "this workflow is used" (Sure run the sync search database update) but that will not tell you what active links open up forms. Yah sure, go directly to SQL and.. .and.. </SOAPBOX> HTH as an FYI Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions.
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
