Update: We were able to resolve this issue.The cause of the issue was that when we changed the "Use Legacy Event ID Ranges” System Parameter to false during our upgrade, we restarted all of our web server services, but we failed to restart the assystEnterprise services which are running locally on our integration servers. Since our MBR and ETM use local installations of assystREST to log events, they were getting the negative values. I assume this was a feature put in place to ensure there are no conflicts if that parameter is changed but the service was not restarted on one or more servers. I have confirmed the events are now logging correctly.
Hi Paul,Thanks for the quick answer. I knew it was something simple I was missing.Using if (! outbound.self.bonds[0]) is giving me an exception (javascript IndexOutOfBoundsException - Index: 0, Size: 0) if the bond doesn’t exist. This makes sense since that statement is trying to access the first item in the array, which is empty if there are no bonds.I ended up doing this: if (outbound.self) { if (outbound.self.bonds.size() === 0) { false; }else{ true; }}else { false;} This seems to work. Cheers,Duncan
Hello. IFS does have a sample configuration for the user gateway (file name: ContactUserV11_2Beta.json). We had to get this from our IFS Partner (consultant), so they likely won’t give it to you directly.I found the sample channel to be overly simple, but have been able to use it as a starting point for developing the mappers to do what we need them to. We already have a separate integration utility for managing our user alias accounts via ETM, so we are only looking to use this part of it to create the actual Contact User records from AD.ETM 1.6.1 does have an LDAP channel source option. I haven’t explored using this yet, but it may eliminate the need to pull the AD data through powershell or some other way.Hope this helps.Duncan
Hello. Thank you, we figured it out.For anyone in a similar situation, the workaround that we have implemented is to set up the app deployment in InTune to do the following:Deploy the assyst Self-Service Mobile App (without the serverURL appconfig, as it does not work) Deploy a web shortcut URL which points here: https://<URL>/assystnet?assyst.client=aceThe icon and name for the web shortcut can be configured to any value, and having the “?assyst.client=ace” appended to the end of the URL results in the mobile app launching automatically when the shortcut is clicked. If, by chance, the app is not installed on the device when the shortcut is clicked, the user will be presented with options to launch assystnetmob or assystnet.
Hi. Task routing can be done based on a number of things, including custom lookups (Single-Select Lookup fields). If you put a custom lookup on your form, you can use the dynamic task expression to route the task based on the client’s selection.https://wiki.axiossystems.com/assyst11-6Wiki/index.php/Dynamic_Task_Expression An example of this would be:if($new.W(“SVD”).shortCode=”SD”, “SERVICE-DESK”,$NO_VALUE)Where “SVD” is the shortcode of the field, and “SERVICE-DESK” is the shortcode of the SVD. The “SD” value here is the shortcode of the lookup value. Once you have your dynamic expression, you can tell the Process Designer to use the value generated for the SVD assignment by adding $DYNAMIC_TASK_VALUE to the SVD expression. Hope this helps.Duncan
Hi, can you try the following please: select usr.id from usr as Usr where Usr.csg.shortCode = 'HEALTH' and Usr.usr_flag1 = 'APPROVER' In the select statement you should always set the table alias to be different then the actual table name. In this case I just changed it to a capitol U. Hello. Thank yo for the reply, however it does not solve the issue. As I stated, we know that the expression we are using works, as it is in use elsewhere in our system and it works on this form if the total number of custom fiends is less than 236. The lookup is only failing when we increase the number of custom fields on the form to 237 or more. Duncan
Hi Martin. Tanks a lot for your reply- I was able to get the index from Gary at IFS after quoting your ticket number. For anyone else who is having similar issues, the index to add is below: CREATE NONCLUSTERED INDEX incide_dx_372714 ON [dbo].[incident] ([parent_event_id]) This, along with running the dbArchive tool directly on the DB server instead of on a web server, has greatly reduced the processing time for archiving. We ran a test batch of 1000 records, and it took about 4 minutes (compared to about 70 minutes before adding the index). Great improvement.Can you describe a bit more about your issue with your database disconnecting? Are you running multiple instances of the dbArchve tool at once, or do you just mean that with so many events to archive, the sheer number of batches is causing the issue? We have only tested small numbers so far (up to 2000 records).Also, have you tried changing the database.batchSize value? If so, what value have you found works best? It looks like IF
Hi Steve. Due to our large user base, we are currently running eight (8) action processors in our environment. However, all eight instances are running the same AP rules.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
