Forum Widgets
Latest Discussions
Azure ADF ServiceNow connector can't retrieve table columns but same login can do in REST API
I have tried to create a pipeline using copy activity to extract data from a table in our ServiceNow dev platform. I have first used the latest version of the ServiceNow connector. However, it didn't work. When I tried to import schema, it shows below error message: Failed to load. The API request to ServiceNow failed. Request Url: https://airtrunkautemp.service-now.com/api/now/table/sys_dictionary?sysparm_query=name%3dfacilities_request^ORname%3dsm_order^ORname%3dtask, Status Code: Forbidden, Error message: {"error":{"message":"Insufficient rights to query records","detail":"Field(s) present in the query do not have permission to be read"},"status":"failure"} Activity ID: 5a99e871-893d-4426-809e-0b22654248f8 Then I tried to use the legacy version of the ServiceNow connector, extract full table data using query. After I executed the pipeline, only 1 column sys_id is returned. I have contacted the ServiceNow support for the issue, they checked and got back me the access login has no issue. Then I wrote python to use REST API to retrieve data from the same table, it works, I could extract all table columns without the insufficient rights issue. Does anyone have this experience before? How did you solve it?
What service principal is used to authenticate Logic Apps to Azure resources?
This question is a bit more academic than practical, but I'm just trying to enhance my knowledge of how Azure authentication works under the hood. The default way to authenticate managed Logic Apps connections is through an OAuth popup asking you to grant permissions. Based on my reading of the Azure docs, this means that you're granting access to the delegated permissions of a service principal. For connectors that access the Graph API, such a service principal in your tenant with the correct delegated permissions: However, I'm struggling to find an equivalent service principal for connectors that use the Azure Resource Management API to interact with services like Log Analytics, sentinel, Logic Apps, etc. I do see a service principal called Azure Logic Apps, but it doesn't have any permissions associated with it. My understanding is that it would need to have the delegated permission user_impersonation to access Azure resources: So my questions here are What Service Principal is used for the OAuth connection to the Azure Resource Management API? If the Azure Logic Apps service principal is used, how is it able to connect to the ARM API without any permissions? Is there some Azure magic happening under the hood here?
Test failover for Azure SQL database
Hi I want to use a failover group to protect an Azure SQL server, for DR purposes, but I'm unsure how to perform a test failover. Can I use a recovery plan perform a test failover, keeping the primary node up and running for production, whilst the secondary is available for DR testing? Cheers Alex
How to sync date and time formats between Azure DevOps and Jira?
Jira Cloud and Azure DevOps have different APIs that support different data formats, even for the same type of data. Azure DevOps uses the HTML format, while Jira uses Wiki. When transferring date-time information between both platforms, transformers need to work behind the scenes to convert between both formatting styles. That’s the only way to get coherent data. But, this conversion is not available by default due to the lack of compatibility. So, a third-party tool is needed to bridge this gap. In this article, I’ll discuss how to sync date and time formats between Azure DevOps and Jira Cloud. We'll use a third-party integration tool called Exalate to implement this use case. Use case requirements If your Jira and Azure DevOps instances are hosted in different time zones, and you need to manipulate the date-time fields so that the same date is kept, here is how we do it. Let us assume the two teams are 5 hours apart. Here is what we can do: “Due Date” and “Start Date” are custom date-time fields in Azure DevOps “Start date” is a custom date field in Jira “Due” is the standard due date field in Jira We would like to add 5 hours to the Jira timestamp when they are received in the Azure DevOps instance. Then, we would like to subtract 5 hours from the Azure DevOps timestamp when they are received in Jira. How to use Exalate to sync date and time formats between Azure DevOps and Jira cloud? Exalate comes with an AI-powered scripting engine that allows you to write mapping rules for any connection. It supports the Groovy language, which you can use to write the transformation algorithm for the date-time information. To implement this use case, you need to install Exalate on both your Jira Cloud and Azure DevOps instance. Then, set up a connection in the Script mode. Once connected, click Configure Sync and navigate to the Rules tab, where you’ll set up sync rules. In the Rules tab, you’ll find default scripts for syncing basic fields like summary, description, comments, and attachments. To sync custom fields or behaviors, you’ll need to add your own scripts. The Rules tab is divided into: Outgoing Sync: Defines the information sent from Jira to Azure DevOps. Incoming Sync: Maps the information received from Azure DevOps into Jira. The same exists on the Azure DevOps side. Jira outgoing script replica.customFields."Start date" = issue.customFields."Start date" replica.due = issue.due The script for the data going out of Jira is being fetched from the custom field named “Start date”, while the due date is going over as the replica.due expression. Jira incoming script import java.text.SimpleDateFormat import java.text.DateFormat import java.util.Calendar import java.util.Date def datePattern = "yyyy-MM-dd HH:mm:ss"; DateFormat formatter = new SimpleDateFormat(datePattern); dateString = replica."start" dateString = dateString.replaceAll("T"," ").trim(); dateString = dateString.replaceAll("Z"," ").trim(); date = formatter.parse(dateString); def timestamp = date.time Calendar calendar = Calendar.getInstance() calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, -5) def updatedTimestamp = calendar.timeInMillis issue.customFields."Start date".value = updatedTimestamp dateString = replica."duedate" dateString = dateString.replaceAll("T"," ").trim(); dateString = dateString.replaceAll("Z"," ").trim(); date = formatter.parse(dateString); timestamp = date.time calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, -5) issue.due = calendar.getTime() The code snippet above allows you to set the datePattern and parsing it through a formatter. It also fetches the timestamp down to milliseconds from the calendar. The calendar.add(Calendar.HOUR_OF_DAY, -5) expression specifies that the timestamp coming into Jira should be at least 5 hours behind the original time obtained from Azure DevOps. Azure DevOps outgoing script replica."start" = workItem."Microsoft.VSTS.Scheduling.StartDate" replica."duedate" = workItem."Microsoft.VSTS.Scheduling.DueDate" This code snippet fetches the start and due dates from the default Microsoft Azure DevOps Server (formerly VSTS or Visual Studio Team System). Azure DevOps incoming script import java.text.SimpleDateFormat import java.util.Calendar import java.util.Date def convertJiraTimeToAdoTime(String dateString){ if(dateString == null) return String inputFormat = "yyyy-MM-dd HH:mm:ss.S" String outputFormat = "yyyy-MM-dd'T'HH:mm:ss'Z'" // Create SimpleDateFormat objects for the input and output formats SimpleDateFormat inputDateFormat = new SimpleDateFormat(inputFormat) SimpleDateFormat outputDateFormat = new SimpleDateFormat(outputFormat) // Parse the input date string into a Date object Date date = inputDateFormat.parse(dateString) def timestamp = date.time Calendar calendar = Calendar.getInstance() calendar.timeInMillis = timestamp calendar.add(Calendar.HOUR_OF_DAY, 5) def updatedTimestamp = calendar.timeInMillis // Convert the Date object into the output format return outputDateFormat.format(updatedTimestamp) // String } // does not set the field String inputDateString = replica.customFields."Start date"?.value workItem."Microsoft.VSTS.Scheduling.StartDate" = convertJiraTimeToAdoTime(inputDateString) inputDateString = replica.due workItem."Microsoft.VSTS.Scheduling.DueDate" = convertJiraTimeToAdoTime(inputDateString) This code snippet converts the incoming date-time information into a string before parsing it as input into the date object. It then fetches the date from the calendar to be 5 hours ahead of the time fetched from the Jira Cloud instance. Once you’re done, review the scripts to make sure everything is in order before publishing the changes. That’s all! Your date-time formats are now in sync between Azure DevOps and Jira Cloud. Using script-based solutions, like Exalate, can seem overwhelming at first, but if done correctly, they can be very effective for your integration needs. Have any specific use case that requires handling different data formats? Just ask our integration engineers for a walkthrough of what’s possible or drop a comment here.
How to reduce downloading time for releasing pipeline
When I do a deployment task on a given deployment server, it downloads all linked artifacts for the entire release. So I'm downloading a ton of stuff I don't need. For Example, if it taking 10 minutes to complete the task and out of 10 minutes, it takes 8 minutes just to download artifacts. Is there a way to avoid downloading unnecessary artifacts?Entra ID Service not running?
hello everyone, we get a notification on our email that the Entra ID Sync service is not running, while it is set to automatic. then 30 minutes later, at the next scheduled sync, it resolves itself. our event viewer shows 1 export error with event ID 6100, that was an user were the inheritance wasn't set up properly, we fixed that, but that did not fix the error in the title. we googled, but really only found "turn on your service and set it to automatic" which is not that helpful. i checked using AI, but that did not go anywhere either. "your internet might have been down" yeah thank you, if that was the case, we would have noticed a wider spread outage.. we thought it might be a throttling issue, but it happens at seemingly random times, so not only during daily start up. so we are kind of at a loss to how to properly fix this, any suggestions?
