Workflow Script Failure with “object reference not set to an instance of an object” error message

Question ID: 109338
0
0

Preconditions:

  • ALM Login id: XYZ having custom user group ABC
  • ALM Project Name: DEF
  • Operating System: Windows 10 64 bit
  • IE: Version 11
  • 2 ALM Users
  • No recent windows updates got installed in Application Server or client machines.

Issue Description:

  •               The first user was able to login to ALM Project: DEF with ALM Login id: XYZ having custom user group ABC without any issues from client machine having Operating System: Windows 10 64 bit, IE: Version 11
  • The second user was not able to login to same ALM Project: DEF with same ALM Login id: XYZ having same custom user group ABC from different client machine having same Operating System: Windows 10 64 bit, IE: Version 11

Receiving below workflow error messages when accessing Req_Fields, TestSet_Fields and other module Fields objects in the workflow

Refer to attached screenshots 1.jpeg & 2.jpeg

Has anyone faced this kind of situation earlier, could you please provide an idea on what might have caused this issue, your advice will be much appreciated.

 

I have tried the following:

  • Deleted TD_80 folder from the problematic machine along with its contents, reloaded application and reproduced issue from the second user machine, the issue got reproduced.
  • Deleted TD_80 folder from the problematic machine along with its contents, done ALM client registration & reloaded application and reproduced issue from the second user machine, the issue got reproduced.
  • Removed all ALM related files from second user machine using ALM Uninstaller utility, done ALM client registration in normal & shared deployment mode & reloaded application and reproduced issue from the second user machine, the issue still got reproduced.
  • Cleared all IE contents Browser History, View Objects, View files, Deleted TD_80 folder from the problematic machine along with its contents, done ALM client registration & reloaded application and reproduced issue from the second user machine, the issue got reproduced.
  • No error messages got recorded in Client & Server Debug logs while reproducing the workflow failure issue on the second user machine.
Attachments:
Marked as spam
Posted by (Questions: 28, Answers: 21)
Asked on February 19, 2020 11:28 am
34 views
Answers
1
Private answer

HI Sai,

I have a couple of suggestions....first is that a typo or is that the correct variable in the first screen shot as it says Req.fields(STATUT).  is that the correct name or should it be STATUS as in the second screen shot it is test.fields(CY_STATUS).  I would check that their spellings are indeed correct.   What can explain one possible issue is if these are in error, the system remembers where a user was at the last point in ALM and if the error was encountered then until the situation is cleared the user gets put back into that situation each successive log into ALM.  I have seen issues where this occurs and each successive log in after encountering the error have yielded the same results since the user was placed back at the same point and regenerates the error, but if able to navigate away from that situatuin, to say something like the defect module where the error isn't present in the code and they log out and back in they will not encounter the error again until they are back in the situation where the errant code exists.

The second thing I would suggest is to go into site admin, into the site projects tab, and select the project in question, run the maintenance routines:  right click and select maintenance>Verify Project and see if any issues are reported.  If all is good you can then right click the project and select maintenance>realign repository and see if that helps. I have had this correct issues in the past where added customizations and their dynamic and static pointers have gotten skewed and this realigns then and has fixed issues for the selected project as it only adjusts this particular project.  Remember it is always recommended to have a back up routine in place and to make sure backups of the project repository and the associated DB project schema before performing any maintenance as a precautionary measure.

Hope these suggestions help,

Dan

Marked as spam
Posted by (Questions: 0, Answers: 701)
Answered on February 20, 2020 9:53 am
0
Private answer

Hi @Dan,

Thanks a lot for your reply.

Actually, STATUT is a variable name and it stores the string value of Status field Labeled corresponding database column name. Same is the case with other variables defined in ModuleName_Fields(xxx) without parameters.

Please find below code:

Dim STATUT

STATUT = userfield("Status","REQ")

Function userfield(label,tablename)
  sql = "Select SF_COLUMN_NAME as thecolumn FROM SYSTEM_FIELD WHERE SF_USER_LABEL='" & label & "' "
  sql = sql & "AND SF_TABLE_NAME='" & tablename & "'"
  set req = requestRecordset(sql)
  if req.Recordcount > 0 then
    result = req.FieldValue("thecolumn")
  else
    msgbox "Error for the field " & label
    result=""
  end if
  userfield = result
end Function

We have noticed that by mistake someone changed value of DISABLE_COMMAND_INTERFACE  site admin parameter value from N to Y,So after changing DISABLE_COMMAND_INTERFACE  site admin parameter value from Y to N,  issue got resolved.

Setting DISABLE_COMMAND_INTERFACE   value to N means, all Non Admin users will be able to execute commands via Workflow without any issues just like Admin users.

Strange thing in my case is, when DISABLE_COMMAND_INTERFACE  parameter is Y,how come first user who logged in with non admin credentials able to execute workflow commands without any issue, and second user who is using same non admin credentials failed to execute SQL commands via workflow?

What would have caused this difference? Ideally both the first and second user who are using non admin credentials should have failed to execute the SQL commands in workflow script when DISABLE_COMMAND_INTERFACE  parameter is Y.

Please advise.

Regards,Srihari

Marked as spam
Posted by (Questions: 28, Answers: 21)
Answered on February 20, 2020 12:31 pm
Sai, good to know that it is resolved. I only asked about the spelling just to insure that it wasn't a spelling error and the value didn't exist causing the issue. As for why it worked the first time, I can only guess. It could be something as simply explained as whomever changed the parameter (which I am unsure if it static or dynamic), but if dynamic took a bit to update and this occurred between the first test and the second user test or that whomever changed it just so happened to change it during the time frame between the first test and the second. The other possibility I can think of (and this might not be even a possibility in this case) is that if the user is the member of 2 or more groups, then it is possible that during log in the system becomes confused and is unsure what group permissions to assign. The recommendation is to only be the member of one group so that the permissions are assigned correctly every time and the custom groups are built based off of the tdamin group (the highest level allowed) and the undesired permissions removed until what is left is the desired permissions as opposed to building them off of the viewer group and adding permissions, as they don't seem to always assign correctly that way, We have seen numerous issues with permissions when the user is the member of more than 1 group as it seems permissions aren't always assigned as desired.
( at February 20, 2020 12:50 pm)
Hi Dan, Thanks a lot for your valuable inputs. As per your provided explanation, below is the sequence which I have visualized. 1. DISABLE_COMMAND_INTERFACE parameter is set to N 2. Non Admin User1 accessing ALM project from Machine 1 having group XYZ is able to execute SQL queries from Workflow. 3. DISABLE_COMMAND_INTERFACE parameter is set to Y 4. Non Admin User1 accessing ALM project from Machine 1 having group XYZ is able to execute SQL queries from Workflow because of preserved cache and history. 5. Non Admin User2 accessing ALM project from Machine 2 having group XYZ is not able to execute SQL queries from Workflow because of non preserved cache and history. 6. DISABLE_COMMAND_INTERFACE parameter is set to N 7. Non Admin User1 accessing ALM project from Machine 1 having group XYZ is able to execute SQL queries from Workflow. 8. Non Admin User2 accessing ALM project from Machine 2 having group XYZ is able to execute SQL queries from Workflow. Thanks for help for helping me in understanding this inconsistent behavior. Regards,Srihari
( at February 20, 2020 1:35 pm)