Does BMC Remedy expose REST APIs - remedy

I want to integrate BMC Remedy with some other tool. So I am thinking of calling curl command to fetch some change request status from Remedy. Does BMC Remedy expose REST APIs ? How can we call them using curl ?

BMC has a Load of webservices as a default. You can read more on their documentation site regarding how they are exposed:
https://docs.bmc.com/docs/display/public/ars81/Web+service+standards
They are exposed as WDSL. You can ask your Remedy Admins to provide a list with the URLs etc. If you are running the ITSM suite, there are several ootb webservices, but depending on your needs, you may need to have some custom ones created...
Note that this is not an answer that fits all versions of Remedy. newer versions may expose REST APIs. As is stated in other answers, as of version 9.0, yes BMC exposes REST API. Both for ARS and CMDB. More info here.

AS of version 9.0, yes BMC exposes REST API. Both for ARS and CMDB.
More info here.

If you are not on version 9.0 yet, we have had a lot of success using ARAPI Community edition by VIPCON. It is basically a Java app that listens for HTTP requests and translates them into AR System API calls on the backend. The community edition is FREE but there is no support provided (which is more than fair).
Here is their introductory post to BMC Communities:
https://communities.bmc.com/docs/DOC-29073
And their GitHub page for the latest release: https://github.com/manyosit/arapi

Related

Integrating Paypal with .Net Core 3

I have a .Net Core 3 project and I want to integrate Paypal.
In past projects I was using Paypal package, but now I was reading their documentation and they recommend to use version 2 of their API. (Previously I was using version 1 with Paypal SDK). If I go to the nuget.com and check the Paypal package I see that version 2 of this package is still rc:
Version Downloads Last updated
2.0.0-rc2 143,570 2018-04-12T18:17:40Z
Now it has been almost 2 years in this, so it doesn't look promising. If I check their docs again I find that they recommend using following package: PayPalCheckoutSdk. Link to their docs. If I try to copy-paste an exampe it doesn't even compile (mainly due to some properties renamed). This really doesn't give a lot of confidence in using this package at all. My last resort would be just to call paypal API directly without using their provided SDK.
What is the best way to integrate paypal with my server running on .Net Core 3.1?
Options:
Use paypal 2.0.0-rc2
Use PayPalCheckoutSdk
Call API directly
Call the v2/orders API directly.
Server-side create: https://developer.paypal.com/docs/api/orders/v2/#orders_create
Server-side capture: https://developer.paypal.com/docs/api/orders/v2/#orders_capture
Follow the PayPal Checkout integration guide and make 2 routes on your server, one for the 'Create Order' and one for 'Capture Order' (see the optional step 5 in 'Add and modify the code'). Both of these routes should return only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as sending confirmation emails or reserving product) immediately before forwarding your return JSON to the frontend caller.
Pair those 2 routes with the frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server

Cross platform RPC integration for Corda?

Are there any plans to develop CordaRPCOps for cross platform interaction, for example, will there, or is where a way I could connect to a Corda node using RPC from Python or .NET?
Currently, no, beyond JVM languages. See the message from Corda's lead platform engineer that he wrote to celebrate Corda's third birthday:
I’ll ask for input again at the start of the Corda 5 cycle because
it’s very open to feedback, but here are some initial APIs we’re
thinking of upgrading:
...
If there is interest and adoption, support for more languages like JavaScript, C++, C# … probably using a mix of Graal and conventional
code generation. We might start looking for contributors to ‘own’
optimizing the experience in these other languages, rather than the
Corda team taking it all on.
...
In the meantime, you have several stop-gap options:
Using GraalVM for supported languages, as Nitesh comments above
Implementing a thin server that maps CordaRPCOps calls into HTTP methods (e.g. Braid)

OpenTSDB HTTP API programming

Someone has developed some OpenTSDB application to interface with HTTP API Rest?
I'm new both to OpenTSDB and both to HTTP programming.
Check out openTSDB2.0 documentation : opneTSDB documetation It has better support for adding and scanning nodes via HTTP api.
It sounds like you are looking for OpenTSDB clients. You will find a list of these on the Resources page.
If you want to monitor generic server statistics, these might already be implemented by one of the utilities, like tcollector. We use scollector, which is a part of Bosun (see the Resources page above).
Check the Documentation for OpenTSDB HTTP API. Scroll down to API Endpoints section, you will find enpoint URLs for put,aggregators,query,search, etc

Migrating from IBM MQ to javax.jms.* (Weblogic)

I've been looking for days about how one could migrate from using IBM Websphere MQ to rather only using the QueueManager within Weblogic 10.3.x server. This would save cost of licenses for IBM MQ. The closest I came was finiding an external link which stated that IBM examples existed that did something similar(moving away from MQ to standard jms libraries), but when I attempted to follow the link: http://www.developer.ibm.com/isv/tech/sampmq.html
it lead to a dead page :\
More specifically I am interested in
What classes to use in my attempts to replace the following, com.ibm.mq.* classes:
MQEnvironment
MQQueueManager
MQGetMessageOptions
MQPutMessageOptions
and other classes which don't have an obvious javax.jms.* alternative.
Some of the nuances & work-arounds I may encounter in this migration process.
The database we are forwarding the queue messages to is Oracle 11 Standard (with advanced queuing) if that changes anything, so basically we are looking to "cut out the middle-man", so to speak. Your learned responses will be highly appreciated!
You seem to use the MQI api for MQ, to which there is no replacement at hand. There is no other way than to actually rewrite your MQ application logic to use the JMS API.
A good way might be to first migrate into JMS using the same WebSphere MQ server, since it allows you to verify your results in a reliable way.
You ask for what classes to replace say MQGetOptions with. There are no single 1-to-1 replacement (there are even some aspects of MQI that JMS cannot easily replace). Most of the MQPutOptions and other options are available by setting parameters on sessions and messages in JMS. You really need to understand the JMS api before trying this switch.
Then, when you have jms working with WebSphere MQ, you can do as Beryllium suggests, but swapping the libraries to Weblogic, switch any reference to com.ibm.mq.jms.MQConnectionFactory;, configuring the new parameters and pray to any a available god - press run :)
I have completed an application which supported both JBossMQ and MQSeries/WebSphere MQ.
The MQSeries specific classes I required were
import com.ibm.mq.jms.JMSC;
import com.ibm.mq.jms.MQConnectionFactory;
import com.ibm.mq.jms.MQQueueConnectionFactory;
import com.ibm.mq.jms.MQTopicConnectionFactory;
These were sufficient to create the javax.jms.QueueConnection/TopicConnection.
As for WebSphere MQ, I connected directly.
As for JBossMQ I looked up the factories using JNDI.
So on top of this there is only JMS.
So the first step is to rewrite your application so that only the initializing part uses WebSphere MQ specific classes (the ones I have listed above)
Replace the remaining MQ specific part with a JNDI/directory lookup for a queue connection factory provided by your application server
Remove the MQ series specific parts from your source.
Here is a simple example which shows how to send a message.

Self hosted S3 alternative [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking for an S3 alternative which relies on a RESTful API, so that I can simply insert links such as http://datastore1.example.com/ID and they are directly downloadable.
I have looked at RIAK and Bitcache. They both seem very nice: http://bitcache.org/api/rest but they have one problem. I want to be the only one who can upload data. Else anyone could use our datastore by sending a PUT Request.
Is there a way to configure RIAK so that everyone can "GET" but not everyone can PUT or DELETE files except me? Are there other services which you can recommend?
Also adding Bounty :)
Requirements:
RESTful API
Guests GET only
Runs on Debian
Very nice to have:
auto distributed
EDIT: To clarify I don't want any connection to S3 I have great servers just lying around with harddrives and very good network connection (3Gbps) I don't need S3..
The Riak authors recommend to put a HTTP proxy in front of Riak in order to provide access control. You can chose any proxy server you like (such as nginx or Apache), and any access control policy you like (such as authorization based on IP addresses, HTTP basic auth, or cookies, assuming your proxy server can handle it). For example, in nginx, you might specify limit_except (likewise LimitExcept in Apache).
Alternatively, you could also add access control to Riak directly. It's based on Webmachine, so one approach would be to implement is_authorized.
Based on the information that you have given, I would suggest Eucalyptus ( http://open.eucalyptus.com/ ). They do have an S3 compatible storage system.
The reliable, distributed object store RADOS, which is part of the ceph file system, provides an S3 gateway.
We used the Eucalyptus storage system, Walrus, but we had reliably problems.
If you are looking for a distributed file system, why don't you try hadoop hdfs?
http://hadoop.apache.org/common/docs/r0.17.0/hdfs_design.html
There is a Java API available:
http://hadoop.apache.org/common/docs/r0.20.2/api/org/apache/hadoop/fs/FileSystem.html
Currently, security is an issue - at least if you have access to a terminal:
http://developer.yahoo.com/hadoop/tutorial/module2.html#perms
But you could deploy hdfs, put an application server (using the Java API) in front of it (GlassFish) and use Jersey to build the RESTful API:
http://jersey.java.net/
If you're interested in building such a thing, please let me know, for I may be building something similar quite soon.
You can use the Cloudera Hadoop Distribution to make life a bit more easy:
http://www.cloudera.com/hadoop/
Greetz,
J.
I guess that you should ask your question on serverfault.com , as it's more system related.
Anyway, I can suggest you mogileFS which scales very well : http://danga.com/mogilefs/ .
WebDAV is about as RESTful as it gets and there are many implementations that scale to various uses. In any case, if it is REST and it is HTTP then whatever authentication scheme that the server supports should allow you to control who can upload.
You can develop it yourself as a web app or a part of your existing application. It will consume HTTP requests, retrieve their URI component, convert it to S3 object name and use getObject() to get its content (using one of available S3 SDKs, for example AWS Java SDK).
You can try a hosted solution - s3auth.com (I'm a developer). It's an open source project, and you can see how this mechanism is implemented internally at one of its core classes. HTTP request is processed by the service and then re-translated to Amazon S3 internal authentication scheme.

Resources