Auto number with specific start value in CUBA Framework - cuba-platform

How can I start the auto number from any specific value say, 1000 in CUBA platform?

In the running application, go to Administration > JMX Console, find the app-core.cuba:type=UniqueNumbers MBean and invoke its setCurrentNumber() method, passing your sequence name (say abc) and desired starting number (1000).
If you need to do this programmatically, obtain a reference to the UniqueNumbersAPI bean available on middleware and invoke its setCurrentNumber() method.

Related

Is there a way to set up number of users for different thread in JMeter 5.3?

I am currently working on testing small API in our company and I need to randomly distribute a number of calls on all methods of that API. I am using 5.3 version of JMeter, company security politics, so we do not have newer versions if that matters.
Because number of methods is around 15 my idea right now is supply .properties file to JMeter, which will contain overall number of calls to API, then, through JSR223 sampler in SetUp Thread Group I will set properties with random amount of users in thread. However, I encountered a problem in doing so: I successfully set all properties, but I cannot access them, when calling ___property function in another Thread groups.
Is there any method to set those properties by script and access them through JMeter function?
Edit: Adding the code I am using in SetUp Thread Group to add properties
jmeter_properties.load(new FileInputStream(new File('env.properties')));
def allUsers = jmeter_properties.get('number.of.users') as Integer;
def random = new Random();
def thisUsers = random.nextInt(allUsers);
allUsers = allUsers - thisUsers;
props.put('getProjectById.users', thisUsers);```
I'm not sure whether it's expected behaviour or a bug in JMeter which should be reported via JMeter Bugzilla, but I do confirm that:
Your code is correct
The generated value cannot be referenced either by __P() or by __property() functions calls
However if you use __groovy() function the property is resolved just fine, so if you do something like:
${__groovy(props.get('getProjectById.users'),)}
in the 2nd (or whatever thread group) you will get the outcome you're looking for

How to switch between different properties files based on request at runtime?

Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.

WebSphere 8.5 Shared Java Custom Properties

I have a clustered environment that has two WebSphere Application Servers.
In side the Process definition > Java Virtual Machine > Custom properties section for my servers I store several properties.
Is there any way to share values in this section between two app servers?
I don't think you can share JVM custom properties among multiple servers. However, you can create WebSphere variables (Environment > WebSphere Variables). When you create a variable there, you can choose a scope that will allow the variable to apply to multiple servers. That variable won't work the same as a JVM custom property, so what happens next depends on how the variable is used. If you need to access the variable inside the application, see this link:
http://www.slightlytallerthanaverageman.com/2007/04/02/access-websphere-variables-in-j2ee-applications/
If you need it to act like a JVM custom property, WAS might do variable expansion on JVM custom proerties. Say you defined a WebSphere variable named "WAS_VAR_X" and needed that variable to be set as a JVM property named "jvmPropertyX." You might be able to define the JVM custom property with:
Name: jvmPropertyX
Value: ${WAS_VAR_X}
I haven't tried this myself, so if you try it and it doesn't work, reply so I can edit the answer.
Maybe you can use database/cache(redis, etc) storing the share value.
When the app startup, load properties from database/cache(redis, etc).
Also you can change the properties and the other server can load new shared values.

Enable debug logging when inserting ApexTestQueueItem records via the SOAP API

I'm inserting several ApexTestQueueItem records into an Org via the Partner API to queue the corresponding Apex Classes for asynchronous testing. The only field I'm populating is the ApexClassId. (Steps as per Running Tests Using the API)
After the tests have run and I retrieve the corresponding ApexTestResult record(s) the ApexLogId field is always null.
For the ApexLogId field the help documents have the Description:
Points to the ApexLog for this test method execution if debug logging is enabled; otherwise, null
How do I enable debug logging for asynchronous test cases?
I've used the DebuggingHeader in the past with the runTests() method but it doesn't seem to be applicable in this case.
Update:
I've found if I add the user who owns the Salesforce session under Administration Setup > Monitoring > Debug Logs as a Monitored User the ApexLogId will be populated. I'm not sure how to do this via the Partner API or if it is the correct way to enable logging for asynchronous test cases.
You've got it right. That's the intended way to get a log.

Configure Service Settings in Windows 7 programmatically using VB.NET

If you edit a service in Windows 7 and go to the Log On Tab, there is an option to "Allow service to interact with desktop". I'm trying to ensure that it is set for a certain service using VB.NET. Does anyone know of a way to do this?
Note: Doing this during the install of a program is not an option. It has to be done at run time.
Call ChangeServiceConfig with SERVICE_INTERACTIVE_PROCESS. The benefit of using Windows API is that it should takes care of the notification and consurrency part and invalidate the cache in other programs that uses service controller, and when something goes wrong, you get an error code back. Generally speaking you should not access the registry if you can use API to get/set a setting.
Service configuration is stored in the registry, under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
With a key for each service.
It appears that the third to last flag within the Type value corresponds to the 'interact with desktop' value.
For example, a service set to NOT interact with the desktop has a value of:
Type REG_DWORD 0x0000010 (16)
whereas that same service, when set to be allowed to interact with the desktop has a value of:
Type REG_DWORD 0x0000110 (272)
I can't say that this is guaranteed as I've not done any testing, but it may be a good place to start. You'd need to restart the service before the changes to this value take effect.