MobileFirst development server - analytics REST services - ibm-mobilefirst

I'm running the development server under MobileFirst Studio 7.0 and I can see the analytics console with data reflecting my application's activities.
Previously in my production servers I have been able to interrogate the status of the Analytics engine by using REST requests such as
http://localhost:9500/_cluster/health?pretty=true
The port 9500 being configurable by JNDI entry
<jndiEntry jndiName="analytics/httpport"
value="9501" />
this value defaults to 9500, while the transport port defaults to 9600.
In my development server I don't seem to be able to access these REST services Looking at the ports I can see that 9600 is active but 9500 is not, and the JNDI entry seems to have no effect.
I'm only seeking to do this for educational purposes, but am I missing something here? Is the REST capability expected to work in the development server? Is there some additional config I need to do?

In MobileFirst Platform Foundation 7.0 this port was blocked for security reasons. However, some customers found it useful using that port so in a coming iFix there will be an option to override the security setting allowing you to view your analytics data on that port.

Related

MobileFirst: can multiple Servers use same database

One of my client has installed two MobileFirst servers on separate machines but have kept same databases for both to use. For example, databases are WLAdmin, WrkLght, WLReports, WLAppCenter and both servers are pointing to them.
It works well in past but today we seen Runtime synchronization failed exception and console was showing.
FWLSE3000E: A server error was detected.
So is this okay to have same database for multiple servers to use ?
Our Environment:
MobileFirst 6.3
WAS Liberty Core v8.5.5.4
Oracle 11
On both servers same application is deployed and there is no clustering. Only a load balancer is configured to just distribute the traffic.
Since Worklight/MobileFirst 6.2, a configuration with two "independent" servers using a shared administration data base is called a farm of servers and requires some additionally configuration. It is no longer enough that both servers share the data base, it is also needed that both servers can communicate to each other through JMX.
The situation in MobileFirst 6.3 for the farm of servers is in my personal opinion not optimally user-friendly, as some XML configuration file is needed to be shared among all servers (this is often error-prone), hence I recommend to upgrade to MobileFirst 7.0 where this XML configuration file is superfluous and the configuration is much easier.
The documentation for configuring a farm of servers can be found here:
MobileFirst 6.2: Server Farm in 6.2
MobileFirst 6.3: Server Farm in 6.3
MobileFirst 7.0: Server Farm in 7.0 (strongly recommended)
A server farm can be configured with Websphere Liberty Profile or Full Profile, or with Apache Tomcat.
An alternative to a server farm is using IBM Websphere Application Server Network Deployment (WAS ND) with clusters (see WAS ND configuration for MobileFirst 6,3). This works only with Websphere Full Profile, not with Websphere Liberty Profile. In this case, you do not really have two independent servers since they must both belong to the same cluster and are controlled by the same Websphere Deployment Manager. WAS ND handles all details of JMX communication automatically for you.
Final note: what I say above holds for the MobileFirst Server and Runtime. For IBM Application Center, the situation is slightly different since it does not require any JMX. Having two independent servers with Application Center sharing the same data base should work without problems.

Publishing a MVC App in Azure Web App

This is my Azure configuration:
I have a Virtual Network with a couple of subnets and a gateway
configured to allow point-to-site.
There is one Virtual Machine with SQL Server (2014) installed. There
are some databases in there already. SQL Server is set up to allow
SQL Server and Windows Authentication mode. This VM is in the Virtual Network
I have an empty Azure Web App
I deployed my main MVC WebApp to the empty Azure Web App and looks good, except when it tries to retrieve information from the database.
Is it a connection string error? or there can be something else...
My connection string looks like this:
<add name="MyEntities" connectionString="metadata=res://*/Data.MyModel.csdl| res://*/Data.MyModel.ssdl| res://*/Data.MyModel.msl;provider=System.Data.SqlClient;
provider connection string="
data source=tcp:10.0.1.4;
initial catalog=MyDataBase;
persist security info=False;
user id=MySystemAdmin;
password=SystemAdminPassword;
multipleactiveresultsets=True;
App=EntityFramework""
providerName="System.Data.EntityClient" />
Here is the error thrown by the azure web app...
So it seems to be related to either the way I'm providing the connection string or the end-points/firewall configuration.
Check your connection string against this connection string for Entity Framework designer files (https://msdn.microsoft.com/en-us/data/jj556606.aspx#Connection)
Just from a quick glance I see two possible errors:
Semicolon missing added after provider=System.Data.SqlClient (the example on the page I provided the link to doesn't have one)
The IP address you specify to connect to is a local one (10.0.0.1) and should be the IP/DNS name of your database in Azure.
Not sure if this is the issue or if StackOverflow just clobbered your markup. In addition you talk about a lot of gateways so I would check to make sure you can talk between your systems. Finally posting error messages and capturing exceptions about what's actually going on will help diagnose the error because at this point it's all guesswork.
Hope that helps.
What the guys said above plus:
The Web App needs to have a hybrid connection to the VNET the VM is if you want to use the local IP address, otherwise you have to use the PIP.
Check the firewall on the VM if the proper ports are open. This has to be both on the VM firewall and the endpoints. Also, if there are any ACLs on the VM, you have to check those too.
The other answers gave me the guidelines to find out the solution.
I'll try to describe the steps I followed:
Using the new azure portal (portal.azure.com currently in preview) I
established a connection between the Azure Web App and the Virtual
network:
Home > Browse > Click on Azure Web App name
In the Azure Web App blade click on Networking tile
In Virtual Network blade, click on the Virtual Network where the database is located (it's important to mention that the Virtual Network ought to have a gateway previously configured)
My intention was to provide certain level of security to the VM with
the databases by placing it inside a Virtual Network, so I had not
considered opening ports. Turns out that it's necessary, so, in the VM:
I enabled the TCP/IP protocol for SQL Server using the Sql Server Configuration Manager (How to? here)
Then I created a new Inbound Rule opening the 1433 port, but only for private connections (very nice).
It was not necessary to create an endpoint in the VM for this port (very happy with this).
Finally, I published the the app to the Azure Web App using the connection strings as shown in the question (with internal database IP)
Final touch: in the new Azure Portal > Azure Web App > Settings, I was able to enter Connection Strings. Settings created in the portal are not overwritten; so now I'm sure this Azure Web App will always use the correct connection string.
Final note: in theory (not tested yet) the internal IP will not change as long as the VM is not Stopped (Deallocated).

How to solve management service not starting up in Worklight 6.2

I have installed Worklight 6.2 on Linux, using Liberty 8.5.5 and DB2 10.5. Created the DB2 databases for WRKLGHT and WLREPORT. Have executed the Server Configuration Tool and successfully created a Worklight Server configuration (did not have any errors in the Console view when running the Ant tasks, tables were created successfully in the database, and configuration shows deployed status in the SCT). Created a runtime environment in the SCT, also seemed to succeed (no errors in Console view, tables created/updated, runtime environment shows deployed in the SCT). Stopped and restarted the Liberty server.
Can hit Worklight admin at (/worklightconsole) and log in successfully using my demo user, however it then indicates there are no runtime environments. When trying to access runtime environment at /worklight/console (which should be the correct URL given how I created the runtime config in SCT using my Worklight project WAR), I get various errors: first "Service unavailable since initialization is not yet complete." then after retrying for about a minute or two I get "javax.servlet.ServletException: java.lang.RuntimeException: Timeout while waiting for the management service to start up at com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForInitialization(AuthenticationFilter.java:561)".
Seems the management service is not starting up successfully. Upon reviewing the messages.log I see the following error precede it: "FWLSE0242E: Failed to synchronize application runtime information. The servlet initialization failed and the servlet will deny serve. The most common reason is a failure in JMX communication with the ''worklightadmin'' service. You need to restart the web application after fixing the problem. [project worklight]" and this creates an FFDC log.
I know this is a lot of information but trying to be complete. Anything I should check to fix the JMX communication issue and get the management service starting?
Thank you for the replies back. Turns out there is an issue with Liberty (I was on 8.5.5.0) and the IBM JDK I was using (1.7_64). Swapped out to the Oracle JRE (1.7.0_60-b19), pointed Liberty to use it, and the problem was solved. I am pursuing a fix with the Liberty team through IBM Support for this issue.
I cannot give a unique solution, but I can explain the situation and this may lead to a solution.
The runtime servlet initialization tries to contact the Worklight Admin service. The Worklight Admin service is a web application that must be running when the runtime starts. The runtime was not able to find the Worklight Admin service. It waited a while, in case that the Worklight Admin service is just starting up, but then gave up due to a timeout because within a given time, it could not find the Worklight Admin service.
Possible reasons:
the web server is not at all configured to run the Worklight Admin service. In your case, this seems not the problem, since you can access the Worklight Console. You should also see in the log file whether the Worklight Admin service did start.
the worklightadmin service might never start up ... this could be a configuration problem, e.g. with the WLADMIN data base. This could also be detected from the server logs.
when the runtimes and the Worklight Admin service start up together, it might be that the Worklight Admin service simply takes too long to start. Let's say you have 100 webapps, and the runtime starts first and the Worklight Admin service starts last, it could be that the 98 other webapps take too much time to start. In that case, make your web server lighter ... run only Worklight on that webserver, nothing else.
the Worklight Admin service starts, but the runtime cannot communicate with it. This indicates that the JMX communication is misconfigured. Follow the documentation of the webserver how to configure JMX. For liberty, see http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_admin_restconnector.html?cp=SSD28V_8.5.5%2F1-5-2-10-1&lang=en

5.0.6 - Changing Adapter domain and port configuration after deploy through configuration - for QA and Testing team in development process

I have seen some questions about dynamic adapter configuration at run-time
how to pass domain,port number,username and password from user input to worklight http adapter
With a Worklight Adapter can I change the domain and port for a procedure at runtime?
but my question is about adapter configuration after deploy on WL server 5.0.6 from external - not at runtime from code.
Our scenario is that in our enterprise development and testing process requires the QA and Testing team to change the destination host and port for the adapters from mockup-backend to testing-backend to production-backend regularly during testing.
of course, this should happen through configuration and not re-compile and re-deploy.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6?
Can this be changed in the WL database tables?
Can this be changed in the WL server filesystem somewhere?
since we did not find any solution to that yet, the developer team is already thinking about using the Adapter only as dumb facade and implement all connection to the backend-services in Adapter-side Java using the Java URL and Connection classes.
Then it would be easy to read a configuration file from the file system in Java to change the backend destination URL and ports in this file.
It would even be easy to read the URL and port from a property in the worklight.properties file in JavaScript and pass it to Java to connect.
I would like to avoid having developing all backend connection code in Java. I would rather see the project use the actual Adapter connectivity features, but I am also not sure how to convince the team since it is quite easy with just 4 lines of code in Java. The advantage of using the Adapter connectivity that can not be configured is hard to see over a own Java implementation in Adapter-Java code.
Thank you.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6? Can this be changed in the WL database tables? Can this be changed in the WL server filesystem somewhere?
In Worklight 5.0.6, as written in the questions you've linked to in the question, an adapter's connectivity settings cannot be altered. They are stored in the packaged adapter and cannot be read from anywhere else during runtime nor after deployment.

Getting MSDN PeerChannel "SecureChat" running on Windows Server 2008 R2

I can only get this SDK sample of PeerChannel SecureChat to work in the following scenarios in a basic home network:
Locally among instances running on the same machine, or
Among Windows 7 machines
I cannot get this to work between my Windows Server 2008 R2 and any other machine (no exceptions are thrown, but the nodes never find each other and thus don't go "online"). I CAN ping the IPv6 addresses among all machines. The executable has a firewall exception rule, but I have also tried disabling the Windows 2008 firewall completely. The PRNP Service is running.
Is it possible to get it working? How?
Does it work on YOUR 2008 machine?
My best guess: I notice that in the Windows 7 machines, the "Peer Networking Grouping" and "Peer Networking Identity Manager" services are present. The "Peer Networking Grouping" service's description there and online talks specifically about enabling multi-party conversations, but related to Home Groups. This service is missing in the Windows Server machine.
So, I suspect the missing service as the reason that the SecureChat sample won't work on the Windows Server machine, but I don't understand why Microsoft would lock out Peer Channel from working on the Server product. Could this be the reason?
Thanks!
Try enabling these services on the server:
Peer Name Resolution Server (Install through Server Management)
Peer Discovery Server (Install through Server Management)
Simple Service Discovery Protocol Service (SSDP Service)
Then simply ensure that the Firewall Rules are modified; by default they block IPv4 / IPv6 Teredo Tunneling driver. IPv6 needs to be supported as it is required by PNRP.
Also you should be able to configure your service in two ways; through Internet Information Systems (IIS) or as a Windows Service. Your best bet will be to use IIS, you can find an article here on how to configure it: Hosting and Consuming WCF Service
Those are the few tips I can think of to get it running. Hope that helps.
This MSDN page mentions this subtle detail of Windows implementation of PNRP:
Any two clients running the same version of PNRP can locate each other
using this protocol...