I had generated a service interface in IR (PI 7.1) but when checking in ECC i couldnt see it in sproxy. The 'G' rfc seems okay and all basic setting and connections seem to be fine. Need some help to fix this please?
I had included my service interface into a namespace http://sap.com/xi/HR within the SCV SAP HR 6.04 where there were some already created service interface visible in SPROXY but not the one I just created.
Just want to be sure, do I need to complete the configuration for the service interface to be visible in SPROXY? or just activating the IR should work?
Related
Background:
I have used developed an OPC server based on LightOPC (https://github.com/Sayen/LightOPC). This works perfectly fine as a local executable. The only problem is that I want multiple clients to connect to the same instance of the exe so they can share data. Currently, even if the DCOM settings are such that it runs as a specific user, it seems that sometimes multiple instances of the exe start. The only solution has been to set it to run as the Interactive User. However this has an issue where it won't run if no user is logged in. I believe the right way is to make it run as a windows service.
Question:
How can I take my DCOM local executable and make it into a service?
Things I tried:
Based off of this question: Create Windows service from executable I used the NSSM( the non-Sucking Service Manager ) to make my exe into a service name MYOPCSERVICE.
Then based on some other googling and examining other OPC servers that run as services, I modified the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\AppID{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} (where X's are my AppId) and added a "Local Service" key with the value of "MYOPCSERVICE".
After doing this, when I used DCOMCNFG, my DCOM Application shows up as Application Type = Local Service.
However, after adding this registry key, when I try to start the service or connect to the OPC server, the service fails to start with "CoRegisterClassObject() failed. Exiting..."
I found this document: https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coregisterclassobject which has the following:
As of Windows Server 2003, if a COM object application is registered
as a service, COM verifies the registration. COM makes sure the
process ID of the service, in the service control manager (SCM),
matches the process ID of the registering process. If not, COM fails
the registration. If the COM object application runs in the system
account with no registry key, COM treats the objects application
identity as Launching User.
I don't know if this is the issue, and I also don't really understand what it means. What is the "process ID" being referred to? Is this the 1-4 digit integer that all Windows processes have? Or is this the name of the service and does it have to match the name of the executable or the class or the AppId?
Update:
I have been experimenting more, and I am starting to get the feeling that it isn't possible to use NSSM to make the COM executable into a service. It seems like the exe of the service needs to be the one that calls CoRegisterClassObject. I have made a simple service based off of Simple Windows Service in c++ https://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=499465 and when I do so, I can successfully call CoRegisterClassObject with the AppId of {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} if this AppId registry key contains the string LocalService = MYOPCSERVICE.
I think Windows is enforcing a rule that only the exe registered as a service (which is nssm.exe) is allowed to call CoRegisterClassObject. However nssm spawns another exe (the local OPC executable) and it doesn't pass along this ability. Does this sound accurate? Is there any work around besides having to write all my own service handlers?
I have a ColdFusion11 environment with two app servers defined. The default cfusion server was created with a Windows system service wrapper to go along with it; the second app server, for some reason, was not.
The SC tool was later used to create a Windows service wrapper for the second app server; however, when the 2nd app server is controlled within the cfusion Enterprise Manager instance, it does not use the Windows Service wrapper to control it. Is there a configuration file I can amend that will instruct CF to invoke the Windows service wrapper to control this second service? This is particularly important as this 2nd server instance has a logon identity that must be used at startup, but if the server is restarted within the CF console, the identity is obviously not used.
In effect, I need to tell the cfusion enterprise manager to use the Windows service wrapper to control the 2nd app server instance, not to just control it directly. I'm assuming there is a configuration setting buried deep within the bowels of CF that would allow me to specify this.
I've tried searching the XML configuration files, looking for a non-obvious setting within them that might point to a startup configuration parameter, but so far have found nothing. Something must control how a secondary app server is managed, so I thought I'd ask here for some insight.
For the sake of anyone else who might encounter this situation, I've discovered the answer. It has nothing to do with changing the configuration of the application server itself.
When the ColdFusion11 administrator console is told to start an instance of another application server within the Enterprise Manager, it first queries the Windows Service Control database for a defined service of the exact name "ColdFusion 11 Application Server [AppServerName]" (without the brackets). If it finds such a service, CF automatically invokes the service wrapper and starts it. Absent that, a direct invocation of the CF instance commences.
The solution to the issue for an app server created without a Windows service wrapper is, when the 'sc' utility is invoked to create the service, to provide a service name that exactly matches the format above.
I have a Delphi Application accessing a web service on the Internet.
The provider of said service has now changed to a cloud based infrastructure and came to me with the following request:
"Please configure networkaddress.cache.ttl in the file $JAVA_HOME/jre/lib/security/java.security as follows: networkaddress.cache.ttl=60"
Accordung to the web service provider this is necessary for the service to deliver correct results under all circumstances.
He has checked the connection of my appication and it appears to him that once started it sticks with the same IP-address.
Restarting the Applications did solve this for once.
I have been importing the WSDL using the wizard provided by the IDE so I am using an instance of THTTPRIO to access the web service.
The THTTPRIO-instance is created in FormCreate() of the main form.
The Application is running 24/7 and accesses several methods of the web service regularly.
Does the Delphi SOAP framwork use DNS caching at all?
If yes, is there a similar property like networkaddress.cache.ttl in Java?
Is there a good workaround for the issue (e.g. reinstancing the wrapper class just before every call to the service instead of only once in FormCreate)?
EDIT:
The Application is compiled using Delphi 10.1. Berlin (originally developed with Delphi XE7). It is running on an Windows 7 machine.
Have you found DnsFlushResolverCache?
In order to clear DNS resolver cache like what IPCONFIG /flushdns
does, programmatically:
Requires dnsapi.dll which requires Win2000 or later. As usual, MS does
not document the API
Source: http://brannockdevice.blogspot.de/2006/04/winxp-flushing-dns-programatically.html
I've been digging into the source code a little and I believe I found an answer.
The Delphi SOAP framwork doesn't seem to do any DNS caching on its own.
It's just that the connection to the web service is done with the first request via the Windows InternetConnect() function and the resulting handle ist stored and reused from then on.
Here's a little more background information on this:
The THTTPRIO class communicates with the web service through an instance of THTTPReqResp:
property HTTPWebNode: THTTPReqResp read GetHTTPWebNode write SetHTTPWebNode;
THTTPReqResp calls the Connect() method before every request which again uses a WinApi function to estabish a connection and stores the resulting handle in a field:
FInetConnect := InternetConnect(FInetRoot, PChar(FURLHost), FURLPort, PChar(FUserName), PChar(FPassword), INTERNET_SERVICE_HTTP, 0, NativeUInt(Self));
But - the Connect() method only does this if it is not already connected - the following code is found just at the beginning of the Connect() method:
if (FConnected) then
Exit;
By doing so the connection just stays open from the first request on.
Following requests are simply using the stored handle from InetConnect.
For my problem with the cloud service it should be sufficient to create my own instance of THTTPRIO and pass it to the function returning the web service interface:
RIO := THTTPRIO.Create(nil);
FM := GetFleetManagerAPISoap(FALSE, '', RIO);
Then I will just disconnect each time before calling any web service function:
RIO.HTTPWebNode.Connect(FALSE);
In theory that should finally lead to a fresh connection via InternetConnect() and hopefully my problem will be solved.
(Still have to test this, though)
I think that you can set it globally in Windows registry.
Open regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
In the right pane, add the following value:
Name: DefaultTTL,
Type: REG_DWORD,
Valid Range: 1-255
Restar the computer.
https://technet.microsoft.com/en-us/library/cc957530.aspx
I'm a newbie
My boss asked me make a iscsi target server by C++ using windows api (run on windows server 2012)
project requirements
- create iscsi target
- connect target with a vhd
I was find alot, but only fond
iSCSI Discovery Library Functions
Volume Shadow Copy API Interfaces
i was created a file .vhd anh truy with WINAPI AddIscsiStaticTarget windows api but cannot add into "File and storage service"
Thank you and Best Regards
Sr because my english
The first link in your question is to the API for configuring the iSCSI client component, not the iSCSI server component.
The second link is to the Volume Shadow Copy API, which I don't think is relevant either. That's used for the intelligent snapshotting of volumes, usually in order to run a backup.
To manipulate the iSCSI target server component, use the iSCSI Target Server Provider API.
Since you're dealing with a VHD file, you might also need the Virtual Hard Disk API.
It is a lot of work to write an iSCSI target. I have written both target and initiator ... the initiator and be very simple if it wants and can be written very easy. But if the target usually has to work with lots of initiators which make it much more difficult to write. Given that, if you write your own very simple initiator then you could write a simple target which only works with your initiator.
I am trying to swap configuration files in and out of my web api to interact with different WCF webservices. I found the solution to change my webconfig files at run time in the following link.
Config Swapper Class
This works great when called from a command line application substituting in my new configuration file but when i call the config file changer from my API I Get the following Error.
"Could not find default endpoint element that references contract 'OldDominionWebServices.RateDelegate' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element."
This is the endpoint I am trying to reference
<endpoint address="https://www.odfl.com:443/wsRate_v4/RateService" binding="basicHttpBinding" bindingConfiguration="RatePortBinding" contract="OldDominionWebServices.RateDelegate" name="OldDominionWebServices" />
I know what the error says, but am unsure as to why this would be thrown in a web api with the configuration file swapped, but not thrown when using a console application that does the same thing. In the case of the command line app the assembly that uses this web service is referenced as part of the solution, where as with the api the assembly is loaded via reflection. I have seen some suggestions that I need to use the Fully qualified domain name in the contract for the endpoint, but this still results in the same error.
I'm hoping this is something simple that I have overlooked, Thanks in advance!
Good question!
Short answer: You can't swap configurations, because web applications use a hierarchy of configuration files that is used in initialization when AppDomain starts, so this would require the restart of AppDomain, and all your in-memory changes would be lost (and this is how that "Config Swapper Class" assembly is intended to work - do everything in memory).
Details:
I did some digging and here is what I've found:
It is not related to the way you load assembly with "Config Swapper Class" assembly, there is nothing there that could be affected by this.
There is no point in restarting AppDomain if your actual configuration lives in memory - all changes would be lost. Probably you could think of another idea of where to store your configuration other than in web.config?
The mentioned assembly (great stuff, BTW!) works in console application, because internally it uses ConfigurationManager, which itself uses ClientConfigurationSystem realization of IInternalConfigSystem interface. Web applications use WebConfigurationManager, that uses other realization of that interface - HttpConfigurationSystem.
So, the "Config Swapper Class" assembly will not help you in web application because it operates on different set of internal classes.