I'm working with UIPath to automate some processes in Microsoft Dynamics AX 2012. When I use UIPath to indicate a button to press or a field to type into, UIPath gets a brainfreeze (stops working) and just chews on it for 3-6 minutes before it has completed. It works, but it take a ridicolous amount of time to make a process, as this is the case at every click. There is no problem when the process is running from orchestrator - it is only during development and only in AX. In all other programs it only takes a split second.
Does anyone know what causes AX to be this slow and how to fix it?
I have attached a video here, where you can see the issue: Link to video showing performance issues
Thank you in advance
This probably happens because the UiPath activity tries to load the whole table (including what is not directly visible) into memory. To workaround this, you might just filter your table in a way that you just have a few rows visible before you Indicate on screen the specific element.
Note that a similar behavior might occur during run time if there is a lot of data to capture.
UI Framework needed to be swithed. Pres F4 to go switch to AA before hovering over AX.
We have a TableView showing a large amount of data. It is a typical use case to select the whole table for some further processing.
This can be done via Ctrl A keybinding. Since the table content is quite large, this selection can take a second or two, which tends to irritate users.
How can I show a Wait Cursor between pressing the keys and the time the selection is actually showing up?
Displayed data might be lazily fetched, depending on the RAM available, so this might be a source of the delay. But I am not sure about this, it might as well be just the "selection" itself.
I am imagining to catch the select-all-event, call scene.setCursor(WAIT), selectionModel.selectAll() and scene.setCursor(DEFAULT) again. But I don't know how to do that nor if that would be even the right approach.
I am new to Autosys and facing difficulty setting up some jobs. I have a box job containg a few command jobs. One of those command jobs may or may not run. The problem is when this job doesn't run(it remains in activated state), it keeps the box running. I have to terminate this job or the box every time such situation arises.
Is there a way to handle this?
Thanks
The answer depends on how your jobs are supposed to work, so posting JIL or a more detailed description would help, but:
You can add a "box_success" JIL attribute on your box job to define conditions that will cause the box to complete even without all the jobs running or completing.
You could consider moving the optional job outside of the box so that this issue goes away. But consider that the box could then complete while the optional job is running so make sure that you don't then have jobs running out of sequence or overlapping when they shouldn't.
I want to be able to recover my queries that I used previously. I was wondering if there is a way for me to get them using sql assistant.
Is there any way I could do that?
A record of all your previously submitted queries should be recorded in your "history database". If you do not see the window, try clicking the menu bar sequence View -> Show History. If you click on one of the rows in the SQL Statement column, the contents will be copied into the Query window.
I have a web application at work that is similar to a ticket working system. Some users enter new issues. Other workers choose and resolve issues. All of the data is maintained in MS SQL server 2005.
The users working to resolve issues go to a page where they can view open issues. Because up to twenty people can be looking at this page at the same time, one potential problem I had to address was what happens if someone picks an issue that someone else picked just after their page loaded.
To address this, I did two things. First, the gridview displaying the issues to select uses an AJAX timer to update every second. Once an issue has been selected, it disappears one second later at most. In case they select one within this second, they get a message asking them to choose another.
The problem is that the AJAX part of this is sending too many updates (this is what I am assuming) and it is affecting the performance of the page and database. In addition, the updates are not performing every second. I find the timer to be unreliable when working to trigger stored procedures.
There has to be a better way, but I can't seem to find one. Does anyone have experience with a situation like this or have suggestions to keep multiple users from selecting the same record to maintain? I really do not want to disable the AJAX part entirely because I feel the message alone would make the application frustrating to use.
Thanks,
Put a lock timestamp field on the row in the database. Write a stored proc that returns true or false if the expiration timsetamp is older than a specific time. Set your sessions on your web app to expire in the same time, a minute or two. When a user select a row they hit the stored proc which helps the app to decide if it should let the user to modify it.
Hope that makes sense....
Two things can help mitigate your problem.
First, after-selection notification that the case has been taken is needed regardless of your ajax update time frame. Even checking every second doesn't mean two people cannot click the same case at what they perceive to be the same time. In such cases, one of the users needs to be notified that their selection is invalid even though it appeared valid when selected. This notification doesn't need to be elaborate; keeping a light, helpful tone can improve user perception even in the light of disappointment. And if you identify the user who selected that record already, that will not only help your users coordinate in future but also divert attention from your program to the user who snaked the juicy case. (indeed, management may like giving your users the occasional collision as it will motivate them to select cases faster)
Second, a small tweak to how you display your cases can reduce selection collisions. Adding a random element to display order and/or filtering out every other case on display will help your users select different cases naturally. Human pattern recognition and task selection isn't really random so small changes to presentation can equal big changes to selection behavior. Reductions in collision chance keeps your collision notifications rare (and thus less frustrating to your users). This is even better if your users can be separated into classifications that can help determine useful case ordering/filtering.
Okay, a third thing that will help you over time is if you keep a log of when collisions occur (with helpful meta data about the collision—like who was involved and selection timing). Armed with solid collision data, you can find what works and what doesn't. Over time, you can hone your application to your actual use cases as well as identify potential problems early. Nothing reassures your users more than being on top of a problem (and able to explain your plans to solve it) before they're even aware it exists.
With these mitigating patterns, you'll probably find you can safely reduce your ajax query timeframe without affecting user experience. And with useful logging, you'll have the assurance that any tweaks you put in place are actually working (or not—which is maybe even more useful to know).
I did something similar where once a user opened a ticket (row) it assigned that ticket to that user and set a value on that record, like and FK to that particular user, so if anyone else tried to open that ticket (row) it would let them know it has already been assigned to someone else.
If possible limit the system so that they just get the next open issue off the work queue as opposed having them be able choose from all open issues.
If that isn't possible, I suppose you could check upon the choosing of an issue to see if it is still available. If it's not available, then make it disappear after the user clicks on it. This way you are only requesting when they actually click on something as opposed to constant polling of the data.
Have you tried increasing the time between refreshes. I would expect that once per 30 seconds would be sufficient. 40 requests/minute is a lot less load than 1200/minute. Your users may not even notice the difference.
If they do, how about providing a refresh button on the page so the users can manually refresh the list just prior to selecting an item to avoid the annoying message if they choose.
I'm missing to see the issue, specially after you mentioned you are already flagging tickets as in progress/being maintained and have a timestamp/version of the item.
Isn't the following enough:
User browses the tickets and sees a list of available tickets i.e. this excludes ones that are in the db as in progress. If you want the users to also see tickets in progress, you indicate it clearly in the ticket status and disable the option to take it.
User either flags a ticket as in progress explicitly or implicitly by opening the ticket (depends on the user experience / how its presented to the users).
User explicitly moves the ticket to a different status i.e. completed, invalid, awaiting for feedback, etc.
When the items are retrieved at 1, you include a timestamp/version. When 2 happens, you use a optimistic concurrency approach to make sure that if 2 persons try to update the take the ticket at the same time only the first one will be successful.
What will happen is that for the second person, the update ... where ... timestamp = #timestamp will not find any records to update and you will report back that the ticket was already taken.
If you want, you can build on top of the above to update the UI as tickets are grabbed. This could be by just doing a full refresh of the current page of tickets after x time (maybe alerting/prompting the user), or even by retrieving a list of tickets changed for the page of tickets being showed with ajax. You still have the earlier steps in place, as this modification its just a convenience for the users.