ECS Integration with AppDynamics Issue - openshift

Currently, I got a task about integrating ECS openshift with AppDynamics.
Here is my situation, I have Integrated my project with AppDynamics . I can’t see my project on appDynamics Dashboard, but I can see it on the Tier and node. i have checked the router for openshift,it’s not available ,so i want to ask you guys if it is the reason why i can not see my project on the AppDynamics Dashboard ?

If your Nodes are showing under "Tiers & Nodes" this means that the Agents are reporting to the AppDynamics Controller.
If however there is nothing shown in the Application (or Tier, or Node) Dashboards this means that there are no registered Business Transactions relating to that Application (or Tier, or Node).
Dashboards (or flow maps, more accurately) generally show a view of registered Business Transactions (not simply of entities which are known to the Controller).
Have a look at the docs for an explanation of what a Business Transaction is and how these can be configured should none be detected OOTB:
https://docs.appdynamics.com/21.2/en/application-monitoring/configure-instrumentation/transaction-detection-rules
https://docs.appdynamics.com/21.2/en/application-monitoring/business-transactions

Related

How do I know which NetSuite integration option to choose (suiteTalk, suitelet or restlet) for integrating NetSuite to our third party application?

I am trying to integrate our third party application with NetSuite. I want to be able to import sales invoice details generated from our third party system (which uses REST API) into the NetSuite invoice form.
The frequency of import is not too crucial- an immediate import will be ideal, but sending data once a day is fine as well.
I want to know what I have to use to do this API integration - SuiteTalk, RESTlet or Suitelet.
I am completely new to this topic and after a few days of research, I learned that there are 3 options for an API integration with netsuite (Suitelets, restlets and suitetalk which comprises REST and SOAP based web services). I also learned that there are scheduled scripts and user events, but I'm not too clear on the idea.
I need some help identifying which integration option I should choose.
Any and all information about netsuite API integration is appreciated!
I would avoid REST/SOAP. SOAP is outdated, and REST is incomplete and difficult to use.
Suitelet's are for when you want to present your own custom UI to frontend users, like a special new kind of custom form not relevant to any particular record. Probably not what you want.
What you probably want is to design a restlet. A restlet is a way for you to setup your own custom url inside NetSuite that your program can talk to from outside NetSuite. Like a webpage. You can pass in data to the restlet either inside the URL, or inside the body of an HTTP request (e.g. like a JSON object), and you can get data back out from the body of the HTTP response.
A restlet is a part of SuiteTalk. The method of authenticating a restlet is the same for the method of authenticating a request to the REST API. So, learning about SuiteTalk is helpful. The code you use to write the restlet, SuiteScript, is the same kind of code used to write suitelets and other kinds of scripts.
So you will want to learn about SuiteTalk, and then, in particular, SuiteTalk restlets.
this is a really subjective issue.
It used to be that SOAP/SuiteTalk was a little easier in terms of infrastructure and since Netsuite's offerings are ever changing the REST/SuiteTalk might fill this space in the future.
Since Netsuite deprecated the Full Access role setting up integrations almost always involves the integrator having to provide a permissions spec. The easiest way to do that is via a Bundle. For token based authentication (TBA) there also needs to be an integration record from which you need Consumer Id and Secret Tokens.
So as of this writing the set up for SOAP/SuiteTalk and RESTLets is roughly the same. The easiest way to communicate these is with a bundle so if you are a Netsuite dev with a dev account you can set these up in a bundle and have your customer import them.
So equal so far but differences:
SOAP/Suitetalk is slow. IMO not suiteable for an interactive interface
SOAP/Suitetalk the code is all in your external app so changes to the code don't require any changes in the target account.
RESTlets can be pretty speedy. I've used these for client interactions.
Updates require re-loading your bundle or overwriting your bundle files in the target account (with the resulting havoc if an admin refreshes the bundle)
RESTlets give you access to the features of the account on which you are running so that code can run appropriate chunks For instance features such as matrix items, multi-location inventory, one-world, pick/pack/ship, volume pricing, multi-currency will all change the data model of the account your code is running against. RESTlets can detect which features are enabled; SOAP/SuiteTalk cannot.
So really the only advantage at this point that I see for SOAP/Suitetalk is that code updates don't require access to the target account.
Who is making the changes? If it is your NetSuite developers, then your options are SUITELET or RESTLET.
If its your third-party application team, they own the code and the process and do all their work sitting outside of NetSuite - your option is SUITETALK/SOAP. Of course, they need to know something about NetSuite, but your business analyst would be sufficient to support them. As of 2020.1+, there is also support for native REST APIs in addition to SOAP in case you still want to use REST, but not write your own RESTLETS.
As the above comments mention, Suitetalk does perform a little slower than calling RESTLETS. So that maybe one of the deciding factors.
You may consider SUITELETs for integration only if you want to bypass all authentication schemes, by setting the suitelet as public. Highly inadvisable though.
If the third-party application supports REST APIs, you could call them directly from within NetSuite - either from user events or from scheduled scripts.
You can also consider iPAAS platforms like Dell Boomi, Celigo, Jitterbit, etc. These are general-purpose integration platforms, and make connecting one platform to another easy, with minimal coding. If your Company is already invested in these iPAAS platforms for other enterprise applications, then the choice is that much simpler.

API specific page in Azure API Management Developer portal

I'd like to have a page or a section of information that only is relevant to a specific API. Is that possible in the new portal?
In this case it has to do with information about event data that is sent out (to webhooks) when new items are created and that are then available in operations for the API. If it's not possible to have i an "API-specific" page, where would you put something like this?
I believe in this case you are trying to add some sort of static page or documentation to explain the functionality about a specific API. You may refer to this. As mentioned in the thread, you can try with swagger but in APIM portal it might not work immediately. Microsoft product team has confirmed that they working on improving support for OpenAPIv3. The ETA is about end of September.
However, you may also check the self-hosted gateway feature
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
Official Documentation

Considering Tyk API Gateway - open source version

Project background: Building an API driven Learning Management System. The back-end system will be receiving data from multiple systems and interfaces: web, mobile, VR.
Looking at API Gateways to front our APIs. Preferably an Open Source API gateway but need to be sure that the support and service is available. Tried out Tyk.io and it feels like it might be the way to go. Been reading other StackOverflow threads around this and looks like TYK's gateway fairs quite well against the likes of Kong and WSO2.
Main areas of consideration for us are:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting - combination of on-prem and cloud depending on compliance requirements of educational institutes (Probably rules of AWS' gateway)
It would be really helpful if anyone who is using or has used TYK.io for their production projects can share their experience, especially for enterprise clients/projects.
Full disclosure: I work for Tyk, so of course think that Tyk is the best fit for your project ;)
Seriously, though - Tyk can do all those things you’re after. Here are some links to the documentation for each item that is big on your list:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting
You can also post on the Tyk community for help, if you haven’t already, or search to see what else others have said.
The Tyk Open Source API Gateway will do everything you need, even outputting analytics to difference sources, like ElasticSearch, Mongo or just CSV.
In addition, you can also use our API Management Platform to control your open source gateway. The Tyk API Management platform includes a Dashboard with analytics and out-of-the-box developer portal. Tyk is free to use, under a developer license, to manage a single gateway node, ideal if you are doing a POC.
Hope this helps and please keep in touch to let us know more about your use case.

Apps monitoring on Openshift

Once I have deployed my application on Openshift, what is the recommended way / best practice of collecting the: 1) CPU, 2) network, 3) memory, 4) disk storage usage of the app? Basically to monitoring an app.
The best would be if they could be displayed in a time series format. Is it possible to link it with 3rd party service (e.g. New Relic) to do that?
Thanks.
I would say that new relic would be the best way to go for most folks. OpenShift does have a marketplace that brings in lots of different 3rd-party solutions like and makes them super easy to integrate. New Relic is available and best of all you can do it for free. You can go to marketplace.openshift.com to add new relic and there's even a KB that will walk you through it step by step here: https://help.openshift.com/hc/en-us/articles/203467070-How-do-I-add-New-Relic-to-my-application-in-the-OpenShift-Marketplace-.
For the sake of stackoverflow, here are the contents of that article:
1. Go to marketplace.openshift.com and login in
2. Locate New Relic
3. Click on "Try the Free Edition"
4. Complete checkout steps.
This will create your www.newrelic.com account. You can confirm this by going to
purchased products at the top of the page. Then to your new relic add-on and click on "New Relic". This should bring you over to newrelic.com and automatically log you in with your OpenShift marketplace account.
To add New Relic to an individual OpenShift application.
Click on Purchased Products
In the New Relic Section, you should have something like "newrelic_6a260 Standard" and a "add to apps" button.
Click on the "add to apps" button
Select the application you want to add New Relic to.
There are two other options you can use.
AppDynamics - I have used their tools and I really like it for monitoring. It is available as well through the Online Store
DataDog - I have not used them but I have seen the demos at their booth and it looks really good as well.
Would love to hear what you choose and your experience.
You should consider Sysdig Container Monitoring
Of all the tools mentioned, it's the only one that was purpose-built for containers. It uses the metadata from openshift to allow you to group containers dynamically into services (namespaces, deployments, etc).
It gives you host, container, and application metrics, including response time of containers and services using network data.
It provides custom alerting and dashboarding as well.
Finally, if you're the service provider, they have a functionality that enables "service-based access controls" - basically allowing you to limit data access to certain services, again, based on the Openshift's metadata.
Sysdig can be used as a cloud service or as on-premise software depending on your use case. Here is a link to their open shift commons briefing: https://www.youtube.com/watch?v=-w-OD78Hno0

Box api-content developer account to production ready account

I currently have a developer account setup in box and looking for steps to move it to production. I cannot find details on
If there is number of users allowed
How to turn production mode on
I am have setup initial account with auth redirect url. Configured my app key and token in my web application.
In terms of "productizing" I've heard a few different ways this term
1) To just make an app generally useable among consumers of the third party app, all that is needed is a functional integration with Box APIs. Assuming that you have implemented oAuth correctly and integrated our APIs functionally, there is no barrier to everyday users to using that integration between Box + third party app.
2) To make an app available to Box users ("productionalize" is a term I hear often), the best way to do this is through our gallery. Developers can follow these instructions for creating a listing in our App Gallery: cloud.box.com/appgallerylisting