Can you share the ESMS configuration files and the Enterworks.properties file it references? If you have any sensitive data, you can redact it if desired.
Precisely Software Inc.
Original Message:
Sent: 03-24-2023 10:16
From: Joshua Swett
Subject: Enterworks Services Micro Service
Thanks Brian,
I went ahead and tried out some of the API's, but unfortunately I get some messages back from the new API endpoints saying "No Token or Cookie for Reauth".
I took a look through the ESMS source and it seems that our problem now is coming from the assumption that authentication is done through the /enable-api/login and /enable-api/reauth endpoints. Unfortunately for us, we've never been able to utilize those APIs and have only ever been able to get the /webcm/rest/oauth/token endpoint to work.
For the /enable-api/login we get a message "Panic Recovery err=runtime error: invalid memory address or nil pointer dereference" and success = false. And the /enable-api/reauth we don't get any messages, just a success = false.
I'm wondering if you've ever seen that with other customers or know of a reason/solution why the login and reauth endpoints wouldn't work? I'm hoping that fixing that would be easier than re-writing the ESMS source to only use the oauth authentication.
Any ideas?
Thanks!
Josh
------------------------------
Joshua Swett
Steelcase, Inc
MI
Original Message:
Sent: 03-24-2023 04:43
From: Brian Zupke
Subject: Enterworks Services Micro Service
Josh,
The errors you are reporting are actually expected. I was informed the errors have no impact on the operation of the micro-service. Because of that and because the core functionality of the service performed as expected, I have not pursued any troubleshooting to attempt to resolve it. I basically just ignore it, which I suggest you do the same.
------------------------------
Brian Zupke
Precisely Software Inc.
Original Message:
Sent: 03-23-2023 10:05
From: Joshua Swett
Subject: Enterworks Services Micro Service
Hey Brian,
Good news & bad news.
The good is that by changing the enable2020.serverName property to our server hosting RabbitMQ, I was able to finally get a valid connection established.
The bad is that I am still getting the same error about unable to load the wrapper.dll file when I start up the ESMS service. I've verified it's in the proper location on the server running ESMS (D:\Enterworks\ESMS\lib\). I've attached the error logs I'm getting. It says that the file might not be readable by the current user, although I've made sure that there's no security settings preventing access to that folder. I'm wondering if there might be a versioning issue maybe? I'm pretty stumped about this.. do you have any ideas on how to get passed this error?
Thanks!
Josh
------------------------------
Joshua Swett
Steelcase, Inc
MI
Original Message:
Sent: 03-23-2023 01:53
From: Brian Zupke
Subject: Enterworks Services Micro Service
Josh,
I double-checked the ESMS source code, and discovered the configuration document has an error: the enable2020.serverName needs to point to the server that hosts the Rabbit MQ server, not the enable-web-server-service (it doesn't matter what the services are named as connections are made using numbered ports).. The value of this property should just be the server name (or IP address), not a URL.
The property was originally created to provide access to the EnterWorks via the REST API by the components referred to as the Services Framework. But efforts to use this property did not move forward, so I opted to re-purpose it for the example micro-service. In hindsight it would have been better to create new properties and have them explicitly include "rabbitMQ" in their names.
Please keep in mind a primary intention with the ESMS is to provide an example that can be used as a starting point for creating your own Micro-service while possibly being usable as-is. If you look at the source file RPC.java, you will see where the enable2020 properties are being used.
------------------------------
Brian Zupke
Precisely Software Inc.
Original Message:
Sent: 03-16-2023 09:10
From: Joshua Swett
Subject: Enterworks Services Micro Service
Hey Brian,
Thanks for the clarification. Unfortunately, I'm still getting the same errors in the ESMS log file upon starting the service.
I'm wondering if you can just verify this is all correct?
- We have a distributed environment, EPX and Tomcat are installed on server1 and our web server service is installed on server2
- By the way, I'm not sure if it makes a difference, but our web server service is called enable2020-web-server-service instead of enable-web-server-service. Would this make any difference?
- On server1 where EPX and Tomcat run, I updated the sharedConfig.properties file that's used by Tomcat with the scheduledImport property
- Also, on server1, I updated the Enterworks.properties file that's used by EPX
- We already had the enable2020.serverName so I didn't touch that. But I'm curious, in the documentation, it said it should be the server name that hosts the enable-web-server-service (so I would think that's server2). But the value for that property was already the server that's hosting EPX and Tomcat (server1). I left it as is because I was afraid to break anything that was already using that property. Does this sound right? Or should I change that to be server2 (where our web server service is running)? If so, could this impact other services negatively?
- For enable2020.userName and enable2020.userPassword, I set the values to what we use to log into our RabbitMQ application. This one seem straightforward.
- For esms.baseURL, I've tried a few different things here
- First because in the documentation, it's the same server as the enable2020.serverName just with "http://" in front, I first started with http://server1
- I also tried http://server2 since that's where the web server service is actually running
- I also tried some combination of the above variations, including port numbers, an ending "/", an ending "/webcm/", etc.
- All the above seemed to result in the same error messages when installing and starting up the service, so I have a suspicion that this could where the issues may be coming from
- Then this morning, I also added the esms.userName and esms.userPassword with the credentials of a new admin user I set up in the Enterworks UI, based on what I understood in your last message.
- After most of the above sub-bullets, I ran the uninstall/install/start/stop scripts on server1 to check the status of the ESMS service
- I configured the web server service to have the updated customQueues and customPaths properties on server2
- Then based on my understanding of the documentation, I deployed the "deployment" folder with jar and html files to both server1 and server2
- Added the new ESMS queue in RabbitMQ
Does anything in all of the above stick out to you as a red flag as to what may be preventing the service from starting up correctly? My suspicion is it's somehow related to the esms.baseURL or the enable2020.serverName. But wondering what your thoughts are.
I really appreciate your guidance on this! We have other teams here at Steelcase very excited to utilize the simplified CRUD APIs.
Thanks!
Josh
------------------------------
Joshua Swett
Steelcase, Inc
MI
Original Message:
Sent: 03-16-2023 04:30
From: Brian Zupke
Subject: Enterworks Services Micro Service
Josh,
It is recommended to have a dedicated local user for accessing the REST API from ESMS. This login is used by ESMS any time it needs to access the REST API itself. It allows for calls to ESMS To get started and avoid any kind of permissions issues, you can have the user be assigned to the Administrator role. This way non-administrator users who invoke actions in widgets that are routed to ESMS won't be restricted when ESMS accesses resources (such as launching a scheduled import). In other words, a user who does not have access to the Scheduled Import Jobs repository will be able to indirectly create a record in that repository through ESMS.
You could set that user up to have restricted access, but the only process that will be using that user is ESMS and all access is controlled. It is easier to assign to Administrator so security is never a hurdle. If you add your own endpoints to ESMS, then depending upon what those endpoints do and what access of EnterWorks via REST they perform, you may want create a dedicated group with only the needed access and assign it to the ESMS user.
------------------------------
Brian Zupke
Precisely Software Inc.
Original Message:
Sent: 03-14-2023 10:09
From: Joshua Swett
Subject: Enterworks Services Micro Service
Hi Brian,
Thanks for the updated .zip! I skimmed through the EnterWorks_Services_Micro_Service_Example.docx and it looked like the most notable config change was related to additional Enterworks.properties properties for esms.userName and esms.userPassword. It says the values for those should be the REST_API_User. I'm not really sure who that would be - is that a new user that I should set up that would be dedicated for this ESMS API layer? And if so, would that user just have Admin security access?
Thanks for the guidance!
Josh
------------------------------
Joshua Swett
Steelcase, Inc
MI
Original Message:
Sent: 03-14-2023 01:22
From: Brian Zupke
Subject: Enterworks Services Micro Service
Josh,
There have been some reported issues with the package associated with ETT 125 (the previous ETT sessions were earlier versions of the ESMS package so the one for 125 should be used). I have attached the new file bundle that will also be updated on ETT 125 tomorrow. The key differences are the source files and the ESMS.jar file and the EnterWorks_Services_Micro_Service_Example.docx has been updated to include additional configuration steps. Please let me know if you have any further issues.
------------------------------
Brian Zupke
Precisely Software Inc.
Original Message:
Sent: 03-13-2023 16:14
From: Joshua Swett
Subject: Enterworks Services Micro Service
Has anyone successfully installed and deployed the Enterworks Services Micro Services layer in their environment? I'm following along in brown bag sessions 020, 108, 117, & 125.
I've gone through all the steps to configure, install, and deploy, but when I start up the enable-esms-service, I get some errors in the ESMS.log about connection refused and unable to load the D:\Enterworks\ESMS\lib\wrapper.dll file.
I've verified that all files have been copied to their correct target destinations during installation and that our Enterworks.properties file has the RabbitMQ login credentials. So I'm not really sure what else I might be missing.
I've attached the ESMS log file for comparison in case anyone may have had similar issues.
I appreciate any suggestions anyone might have!
Thanks!
Josh
------------------------------
Joshua Swett
Steelcase, Inc
MI
------------------------------