Azure Lab Services - publish a lab does not work - azure-lab-services

I can create the lab, but publishing the lab does not work.
The publication takes between 5 and 6 hours and has no result - the lab is not published afterwards. (normally the publishing lasts less then 1 hour - and it is published afterwards)
If you look into the log, you only see the entry that the publication has started.

I know this is an older post but I wanted to let you know that this appears to be an issue with the service. In the future, if a lab created with Azure Lab Services gets stuck in a 'publishing' state and never finishes, the best route is to raise an Azure support ticket to get Microsoft to look into & fix it.

Related

qbXML - Error Recovery / Clearing - Out Of Memory - ClearAllMessageSets

I'm working with a Magento 2 plugin that syncs data to QB Desktop using XML.
There was a ton of work done for the plugin to work with current Magento setup, but there's a new error that shows up when a lot of data is being synced (500 products for example).
It looks like there are some products that have errors during sync but QB is not cleaning the errors out from memory.
The products are being synced in a batch - 1 request contains 50 products/items. Some of the product have errors, some not.
QB Posted about this here:
https://developer.intuit.com/app/developer/qbdesktop/docs/develop/exploring-the-quickbooks-desktop-sdk/error-recovery#using-error-recovery-in-qbxml-based-applications
But, there's no actual example that can be used.
Has anyone experienced this or has an example of how to handle the errors?
The SDK also not very clear about what to do:
https://static.developer.intuit.com/qbSDK-current/doc/pdf/QBSDK_ProGuide.pdf
All I want to do is - clear the memory in QB and let it process next request without plugging up the memory.

undo editing standard process in Powerapps

I'm using PowerApps with Dynamics 365. While I was practicing on Powerapps I had edited the "Lead to Opportunity" process and deleted one of the stages, I thought that the effect of deletion will be only on my app and solution, but I was surprised that the stage disappeared also from Sales hub and Sales team member apps too.
Please, what can I do to return the original process?
If you just need that OOB BPF, try exporting in a solution from another environment and import into your affected organization. That should solve the problem.
There is no soft delete, once saved and published - it overwrites, that being said - take a backup in a solution (zip file) and keep it aside, else do “save as” before doing any customization. Even better, keep a lower environment for POC, R&D without disturbing your Prod replica Dev environment.

Arcgis server CreateReplica REST API of feature not working

I created Feature class in enterprise geodatabase (SQLServer2014 express). Feature class is sync enabled and published successfully.
Now I can not generate offline geodatabase from Arcgis Android SDk.
I can see ' Create Replica ' from 'Supported Operations' from 'http://xyz:6080/arcgis/rest/services/MyFeature/FeatureServer'
I tried 'http://xyz:6080/arcgis/rest/services/MyFeature/FeatureServer/createReplica' rest api from feature service. it creates job but no results shown.
Server logs show following error
Error executing tool.: ErrorMsg#SyncGPService:{"code":400,"description":""} Failed to execute (Create Feature Service Replica).
Log source is 'System/SyncTools.GPServer'
First, make sure that there's nothing needed at the DB level where your data is stored. Taking the server out of the equation, can you run the Create Replica tool in ArcMap/ArcGIS Pro against the data source, and does it succeed? If that works (and other operations like Adds, Updates, Deletes etc.), then put ArcGIS Server back in the equation.
What are your ArcGIS Server log levels set at? It may be beneficial to up the logging level to Verbose or Debug, try to create the replica again, and consult the logs to see if more helpful information is returned.
You may also want to check and see if your version of ArcGIS Server needs to be patched. For example, at 10.5.1 there was a patch released specifically for Sync issues.
If all else fails, Esri Support may be a good place to find some help as well.
Have you looked at the requirements for making your data available for offline use? See this link in the ArcGIS Server documentation.
Specifically you need to enable archiving and include Global IDs on the dataset, but there are more details at the above link.
For future reference, and in case that suggestion doesn't work, the Esri GeoNet ArcGIS Enterprise place is a good spot to ask these questions.

TFS 2015 slow to populate Incoming Requests after update

My organisation recently applied an update to TFS 2015 (14.102.25423.0 according to the 'About' page of the web interface) that resulted in the 'My Work' tab in Visual Studio 2015 taking up to one minute to populate. I played around with the queries and managed to narrow the problem down to population of the 'Incoming Requests' section of that tab. Under the hood, this is executing the following WIQL query.
SELECT [System.Id], [System.Links.LinkType], [System.Title], [System.State], [System.Reason], [System.AssignedTo]
FROM WorkItemLinks
WHERE (Source.[System.TeamProject] = #project and Source.[System.WorkItemType] in group 'Microsoft.CodeReviewRequestCategory' and Source.[System.AssignedTo] <> #me and Source.[Microsoft.VSTS.Common.StateCode] <> '1')
and ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
and (Target.[System.WorkItemType] in group 'Microsoft.CodeReviewResponseCategory' and (Target.[System.AssignedTo] = #me or Target.[Microsoft.VSTS.Common.ReviewedBy] = #me) and Target.[Microsoft.VSTS.Common.StateCode] <> '2')
ORDER BY [System.CreatedDate] desc, [System.Id] mode(MustContain)
I've reproduced the slowness using the TFS REST API described in https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql (passing the WIQL query above in the body of the POST request).
The following code review selectors are slow to populate: My Code Reviews & Requests, Incoming Requests.
The following code review selectors are fast to populate: My Code Reviews, Recently Finished, Recently Closed.
The problem is occurring for all users, not just my user.
No one on the team has more than a few code reviews open at any one time.
The problem started occurring practically overnight i.e. on Friday the queries were completing in a second or so, on Monday the queries were taking up to a minute.
Our TFS environment is hosted on Windows Server 2012 (non-R2).
Our TFS environment is backed by SQL Server 2012, SP3 (11.0.6020).
The upgrade to TFS2015.3 was completed as per Microsoft instructions and no issues were encountered and there are no messages in the logs to indicate anything is wrong.
Does anybody have any suggestions about what might be causing this slowness and what can be checked in order to narrow the performance problem down further?
The Team Explorer in Visual Studio provides a dropdown selector for specifying which state of code reviews one wants to list. The available choices are:
My Code Reviews and Requests (open)
My Code Reviews (open/mine)
Incoming Requests (open/others)
Recently Closed (closed)
Recently Finished (finished)
( Annotated each entry above with the state and ownership for clarity.)
According to the description of your performance issue, since this is occurring for all users, seems there are a large number of code reviews in your team. When you open the My work tab , the loading of the various code reviews cause a performance issue.
For this situation, you can try this workaroud: switch over to my code reviews in that Team Explorer drop down selector. After this, please double check whether the issue is gone or still exist.
Answering my own question here... My organisation ended up escalating this through Microsoft and eventually found that there was an issue with out of date statistics causing bad query plan generation. The query that was used to retrieve code review details was taking more than 60 seconds each time it was run.
The queries below will most likely make a significant different to performance if you encounter the same problem.
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCoreLatest] WITH FULLSCAN
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCustomLatest] WITH FULLSCAN
For reference, there's a duplicate of my original post on Microsoft Connect here: https://connect.microsoft.com/VisualStudio/Feedback/Details/3107261. The comments from Microsoft in this post indicate a number of people were seeing similar behaviour.

Having Different Users and Metrics For Resolving and Closing Issues in Jira

In Jira, we are currently trying to model the way our company does Software development versus software testing. We generally have QA open tickets, Software Dev picks up the tickets (assigns it to themselves), and then QA verifies the tickets after Dev team has resolved it. What we are concerned about is being able to track both Resolutions as well as Closes.
For example, assume two Jira users person A (Software Dev) and person B (QA)
B: opens ticket
A: Fixes issue and resolves ticket
B: closes ticket.
At the end of the day, we want to be able to see
A: Issues Resolved: 10
B: Issues Closed/Tested: 10
Is there a way to do this in Jira?
Use the following JQL:
# resolved from the beginning of the day
resolution = Done and resolutiondate > startOfDay()
# closed from the beginning of the day, assuming that closed issues can't be edited (default)
status = Closed and updatedDate > startOfDay()
Having said that, we ended up doing something quite different. here is the workflow:
QA opens tickets (in the QA project) after reviewing support issues.
The QA have a special transition in their workflow - pass to developers. When doing this, the original issue moves to waiting for dev state where it can't be modified manually, and a duplicate issue is created in the DEV project. All issue field are being copied. in case this issue has already been assigned than the original DEV issue is re-opened.
Developer pick this issue and resolve it. Once the issue is resolved, the original issue from the QA unfreezes - moves to QA after dev state where it's editable again.
The QA team picks up this issue, check if they where resolved and closed them or moves them back to waiting for dev if needed.
This way we could have report of how many issues were closed, opened, resolved, picked up by the dev team, waiting for the dev team and so on.
To achieve this functionality we used custom fields to save the fields that where passed from the two types of issues, link between the two issues, and used Jira Scripting Suite for the issue and link creation, as well as Behaviours Plugin for filed verification.
In case you need support for Jira > 5.2 instead of Jira Scripting Suite use Script Runner