16

I would use the token service to test the other two, thus ensuring that all 3 of them are working. To do so, though, you need to be able to create a specific HTTP request, setting the method and headers, etc. There are lots of tools out there; I typically use the Postman Chrome extension. Test the token service by getting a token you can use with the other ...


13

Yes you can re-use the Broker database for the discovery-service. The reason why we provide it separately is so in the future we can have different options. You can imagine you can register different capabilities in the discovery-service that perhaps do not require a broker db in the future. Also putting this in a different database offers different ...


11

The issue was I had Java 9 installed and Web 8.5 only supports Java 8. Just removed Java 9 and installed Java 8 and it worked fine.


8

Are you using the default service configurations? Is this graph in-use or running idle? You can try reducing the maximum memory used by the Discovery Service down to 128Mb (see the bin/install.ps1 or install.sh script for the -Xms and -Xmx settings). Try setting them to: "-Xms64m", "-Xmx128m" The deployer can be adjusted dependent on the size of transport ...


8

Your assumption that the first two responses are OK, but the third is not is correct. When OAuth is enabled (the default), all CD microservices (except the token service) expect an OAuth bearer token in the HTTP Authorization header (as described by Peter) and will return an invalid grant error if such a bearer token is not provided. If you get such a ...


7

The cleanest way to do this is by passing parameters to the InstallService.ps1 script. The parameter passing convention deviates from the standard Powershell approach, so you need to be careful with it. What I do is to have a separate script called Invoke-InstallService.ps1 which lives in the bin directory alongside SDL's InstallService.ps1. Here's what it ...


7

If you want to create two separate CD Environments (with their own set of microservices, incl. Discovery Service), they need to have separate databases. If you want to minimize the number of databases, you could combine the Discovery Service DB with the Content Data Store. I wouldn't recommend that, though; it is better to keep your infrastructure data ...


7

For the environment you are explaining, it seems that you are using the same discovery database for all the groups. AFAIK all the discovery services, are part of a content delivery envireonment, and they need a diferent discovery database. If you are using the same discovery database for more than one delivery environment, when you update and register the ...


7

Using Fiddler I found out that the TokenService was registered on the localhost domain. That's why the webapplication (which was running on my local machine) couldn't access the TokenService on the development server. See screenshot below: I configured the TokenService with a domainname and now it works.


6

You have both discovery pointing to Same DiscoveryDB, When you run update for a discovery(say staging) then all it's capabilities get registered in this DiscoveryDB At the time of publishing to two targets, two discovery are used to determine the respective deployers but as they refer to same DB to get Deployer Capability they both use the deployer ...


6

I'd forgotten to install one of the prerequisites. It was my own fault. Java was not installed on the Content Delivery Server.


6

It's not I'm afraid. If your Discovery Services (and associated Microservices) were on three separate servers, then you could use the 'localhost' workaround described by Quirijn here: USING SDL’S MICROSERVICES IN A WEB FARM However, the URL of the Content Service is stored in the Discovery Database just once (i.e. the last one that was registered), so ...


6

If the URL of your Discovery Service changes, you can use the Set-TtmCdEnvironment cmdlet to update the URL in Topology Manager. No need to destroy things. :-) BTW: publish state is still stored in the CM DB, so if you would recreate the Topology Manager DB, there would not be a need to republish anything.


6

I dug into the code and it appears as though while it says the DestinationName is optional, I was getting a null pointer in the code on it. DestinationName The name of this particular Capability instance (optional) I added a DestinationName for both of the capabilities, and then tried to register all of the capabilities which was successful. <Role ...


5

I fixed this by making all the CDaaS services start Automatic (delayed) so I am guessing they all needed the SQL database to be fully up and running before they could start, although that is a guess. Either way they work fine now. I also had to change the dependencies in the Live services because the installService.ps1 is hard coded to make the ...


5

The solution, as suggested by Quirijn and Raúl, was to replace the string (local) in the serverName property with the machine name. I've just checked my 2013 server to confirm that I have used (local) in my storage configs there without any problems. It seems this is a new "gotcha".


5

Your understanding seems to be quite OK. If you want to minimize the number of DBs, you could combine the Discovery and Content Broker DBs, but I wouldn't recommend that; it's more convenient to keep your content and infrastructure info separate. It is essential that each CD Environment has its own Discovery Service (DB). With Topology Manager, the ...


5

It is in discovery\bin\installService.ps1 script: $serverPort="--server.port=8082" You can firstly uninstall your service, change this setting and install it again.


5

I was having a similar issue in a Windows environment with SDL Web 8.1.1. What got me past the error was removing these two attributes from the ConfigRepository element in the cd_storage_conf.xml I used to run the discovery update: ClientId="registration" ClientSecret="encrypted:xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX" Since I am not using OAuth, I guess ...


4

Sync-TtmCdEnvironment is the best way to fix it. make sure discovery.svc is accessible from your CMS


4

There was an issue due to SecureRandom in unix platforms which caused timeouts when generating OAuth token. This was fixed as a hotfix and available in latest 8.1.1 hotfix release. Applying hotfix should fix this issue.


4

Which ClientId and ClientSecret are you using in your OAuth credentials. The user registration has no permissions to publish content to the Content Deployer. If you are using the default users and their roles you need to use this user cmuser where the default password is CMUserP@ssw0rd. Please make sure you update these passwords. You can find the default ...


4

Please check my Question (and answer) here The trick is to add TokenServiceUrl (TokenServiceUrl="http://10.177.4.83:8082/token.svc") as it somehow gets deleted when you do a quickinstall: <ConfigRepository ServiceUri="http://10.177.4.83:8082/discovery.svc" ConnectionTimeout="40000" CacheEnabled="true" ...


4

Refer to the SDL documentation on Scaling Content Delivery here http://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v1/GUID-5570B671-C4CD-4CC9-943B-489E5390C13E


4

If you are using the quickinstall.ps1 powershell script for CD installation, then use the -auto-register switch as mentioned by Nuno. In case you have done the installation without this switch, then compare the cd_storage_config.xml for Discovery service from the Installation media (\Content Delivery\roles\discovery\standalone\config) with the one available ...


4

As mentioned in the documentation (http://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v1/GUID-654563D2-F38B-43C9-851C-0C1104FBA2AA), you can use PowerShell, and depending on your database navigate to one of the following folders on the installation media: Database\MSSQL\ Database\Oracle\ Then type the following command to create a new Discovery ...


4

As Nuno commented, you can still get access to the raw data using the (public) OData V2 endpoint (CIS Content Service). Alternatively, you can get access to your DXA View Model data formatted as JSON (try adding ?format=json to the URL of a DXA Page).


4

The error was the symbol '-' in app.config in keys oauth‐client‐id, and oauth‐client‐secret, it's binary representation was not correct.


3

I had a similar problem and got the same initial PowerShell error message: WARNING: TCP connect to localhost:8082 failed WARNING: TCP connect to localhost:8082 failed WARNING: TCP connect to localhost:8082 failed WARNING: TCP connect to localhost:8082 failed ... WARNING: TCP connect to localhost:8082 failed ERROR: Unable to start service during timeframe of ...


3

I have noted that in my cd_ambient_conf.xml of discovery service, OAuthEnabled was set to false but Rules Enabled was set to "true". Making both of them to true or false (disbaling oAuth as per doc) resolved the issue.


Only top voted, non community-wiki answers of a minimum length are eligible