I am using RTC enterprise version 6.0.4.
I am using rtc plain java api to retrieve all changesets for a component using IChangeSetSearchCriteria. Using the same api I can get all changesets in a server If I don't apply the component filter criteria.
I was going through some more investigation and came across this url, which returns all changesets in a server :
https://server-url:port/ccm/rpt/repository/scm?fields=scm/changeSet/*
So I just wanted to understand RTC on data base level is it possible if somehow a component is deleted and still changesets exist in RTC DB, so when we use above url , it returns list of those changesets too ?
Or Is there any java api (or url as above) which can give me list of all changesets which are not associated any of the component ?
Related
I'm having real trouble getting Informatica PowerCenter or Developer to call a URI based REST API and I'm doing it for something simple (JIRA's API). Basically I want to call JIRA's worklog REST API which is a different URL for a list of issue ids and write it to our DB.
https://docs.atlassian.com/jira/REST/6.2/
/rest/api/2/issue/{issueIdOrKey}/worklog
Informatica PowerCenter supports only HTTP transformation which is only a simple GET. Unfortunately the latest version is still stuck in the 'old' query type URL building where they append inputs into search strings. E.g. if I have a "key" input field with value "ABC-1" and the URL is jira/rest/api/2/search it would actually build the URL on the fly into jira/rest/api/2/search?key=ABC-1. While some of JIRA's API works this way, some use the URI way e.g. jira/rest/api/2/ABC-1/worklog which requires embedding the value into the URI. There's no way I can get this to work :-
if I do jira/rest/api/$key/worklog it still converts the URI into jira/rest/api/$key/worklog/?key=ABC-1 so $key does not get replaced
even if i pre-build the URI outside the mapping it's not feasible as the URI needs to be dynamic to the list of JIRA keys and anyway because it appends ? at the end JIRA throws an error (because ? is a reserved key word for this API)
HTTP transformation does not support NTLMv2 authentication which our company's JIRA instance may upgrade to shortly
Last resort is to use a Java transformation in which Informatica has quite little value add. This also means I need to somehow pass in the JIRA user password for authentication which is a separate challenge (versus just storing as a HTTP connection)
Informatica Developer supports REST Web Consumer Transformation but has similar limitations with only building query type URL. Even worse I can't even dynamically build the URL since it's fixed to the HTTP connection object URL.
Am I straight outta luck?
I got the query and here I would like to answer about this. I can write here only points and it might be you won’t be able to understand that thing properly. So Here I am putting link of blog where the task "how to informatica read rest api is mentioned in detail step by step with video tutotial. Some examples are also there. Feel free to visit
https://zappysys.com/blog/read-json-informatica-import-rest-api-json-file/
Hope it will help.
Does anyone know how to create a branch using the VSO Api. The documentation for Branches doesn't include a "create".
I have been experimenting with doing it via the ChangeSet Api without much success.
This is TFVC, not Git.
Just as what you see in "Branches" page, there isn't any way to create branch with the Rest API. And mostly, you can only read/get the information with the Version Control API for now.
I would recommend you to use Client Object Model Reference if you want to manage the Version Control programmatically. To create a branch, use the "CreateBranch()" method in Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer class.
The REST API apparently does allow one to create branches.
The confusion is that people think that this would be a PUT operation on the Branches endpoint of some kind.
It is not.
In the REST API, a branch is just one more kind of change that is checked in as part of a changeset.
It took me a long time to discover this, myself; and I was using the old SOAP API in the belief, shared by everyone else it appears from what I can find in Q&As on the WWW, that this wasn't part of the REST API.
Of course, using the SOAP API prohibits using .NET 5, because the assemblies only come for .NET Framework.
An abandonware API on an abandonware runtime is not a satisfactory way to talk to source control. ☺
The terrible Azure DevOps documentation gives no clue as to this, except for 1 obscure not-even-a-complete-sentence hidden in a minor class: "List of merge sources in case of rename or branch creation."
The only other clue is what appears in the JSON, from a get changeset changes, that describes the changeset of an already-made branch.
The (also abandoned) Azure DevOps sample code does not contain examples for even deleting an item, let alone branching.
Changesets are checked in via the changeset creation endpoint.
The individual change is a TfvcChange in the changeset's list of changes where:
the version control type (which is a set of flags) contains the branch flag; and
the merge source for the change specifies the source item and the range of changeset numbers.
Branching an entire tree appears to be a matter of branching the directory and all of the files and directories in the directory.
In C♯ or PowerShell, this is a TfvcChange with a VersionControlChangeType of Branch, in a TfvcChangeset passed to TfvcHttpClientBase.CreateChangesetAsync().
I am not able to figure out how should I handle the names of transitions so that it is aligned to the best practices of RESTful API in case of resource expansion.
For instance, if I want to fetch all the orders for a particular customer the URI should be like https://api.website.com/customers/1000/orders.
I am able to make the transitions restful for a single resource i.e. customers or orders (as it was demonstrated in the Example App file in Moqui.) but was unable to find any example which will solve the purpose of resource expansion.
The problem that I am facing is while designing the transitions as per the best practices of a restful API. The ExampleApp.xml only has examples for a single resource i.e. Example Entity.
If I take the case of the data model used in HiveMind regarding Project management then the URI should be like this according to the best practices
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone for a particular Project - https://api.website.com/projects/DP/milestones/DP-MS-01 (Here, DP is the Project Id)
For fetching a Tasks of a particular Project- https://api.website.com/projects/DP/tasks/DP-1
Now if I am designing an API in Moqui framework, this is how I have to name the URIs
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone of a Project- https://api.website.com/projects/DP/DP-MS-1
For fetching a Task of a Project- https://api.website.com/projects/DP/DP-1
So you can see that these URIs are confusing as I am not able to differentiate between the URI for fetching a milestone or a task.
I can still make the URIs as per the best practices of restful API design by checking the path-parameters (i.e. if tasks is in the path parameter then execute the task related operations and similarly for milestones). But this approach will not be a clean one as its maintenance will become difficult if the parameters in the URIs are too many like https://api.website.com/projects/DP/milestones/DP-MS-1/tasks/DP-1/worklogs/DP-1-WL-2/party.
This is just an example scenario in which I want to get the party/person who has added worklog for a task in a particular milestone of a particular project. This is the case of one data model i.e the WorkEffort.
But what about party, customers, orders, products etc. data-models? Designing an API will become an extremely tedious job for the developer of the API.
So I was just asking if there was another cleaner approach that is implemented in Moqui which I could use as reference?
In the latest version of Moqui Framework (not yet released, just available in the GitHub repo though will be part of the next release) there is now an automatic entity REST interface to do find and CrUD operations.
It supports patterns like that described in this question and many others, for some examples see the comments in the rest.xml screen file (that handles the entity REST requests):
https://github.com/moqui/moqui/blob/master/runtime/base-component/webroot/screen/webroot/rest.xml
The concept in Moqui that handles this is path parameters. The easiest examples of it are in the RESTful service examples in the ExampleApp.xml screen:
https://github.com/moqui/moqui/blob/master/runtime/base-component/example/screen/ExampleApp.xml
The example request, in a comment in that screen, with curl looks like:
curl -X GET -H "Authorization: Basic am9obi5kb2U6bW9xdWk="
http://localhost:8080/apps/example/ExampleEntity/TEST2
The transition that handles this request looks like:
<transition name="ExampleEntity" method="get" read-only="true">
<path-parameter name="exampleId"/>
<actions>
<entity-find-one entity-name="Example" value-field="example"/>
<script>ec.web.sendJsonResponse(example)</script>
</actions>
<default-response type="none"/>
</transition>
Note the use of the transition.path-parameter element, and that this transition only applies to requests with the HTTP GET method. Everything after the transition location in the URL is treated as a path parameter and put in context fields, like "exampleId" above, in the order of the path-parameter elements.
In your case you would have 2 path parameters, a customer ID and the "orders" string telling it to retrieve orders for the customer.
Can anyone help me in getting the list of changesets or the files which are modified using oslc.
Iam using rtc ccm.
Iam able to get it through workitem, but I want to access all changesets directly from scm or any method to get the UUID for all changesets
This url used for achieving the above problem, but I'm not sure it is using OSLC concept in it.
.com/ccm/service/com.ibm.team.scm.common.internal.rest.IScmRestService2/historyPlus? n=25&path=workspaceId%2F_Dh7kMAHIEeSZzL8CZgHcOQ%2FcomponentId%2F_j7JnAbl2EeOYP5vHPrH3vA
It returns the change sets without the need of workitem.
if any one find any other (using OSLC & not using API) way please post it here
I have the need to add a licence field to the APIs published by the API manager.
It does not seems to be any extension point beyond the api.rxt file in the resource folder.
If I modify the file and run the application the carbon app correctly show the added field, but nor the publishe nor the store are able to get the field and there is no way to get it also with REST APIs since it calls a method of a class that (in later versions) outputted fields positionally.
Is it possible to add the field, without running the risk of crashing the API Manager?
Which is the correct way?
Thanks
This change cannot be done without modifying the code. When an API is created from the Publisher app, it gets stored in the registry. The api.txt you modified, only defines the structure of this stored artifact. It may add a new field to the artifact, but to correctly populate that field, you need to modify several methods in APIProviderHostObject and APIProviderImpl + several Jaggery scripts.