# Using Services in Rules

**URL:** <https://forum.shopware.com/t/using-services-in-rules/67874>\
**Category:** Programming (EN)\
**Created:** [23. Juni 2020 um 12:30 UTC](https://forum.shopware.com/t/using-services-in-rules/67874 "2020-06-23T12:30:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hansibert](https://avatars.discourse-cdn.com/v4/letter/h/8e8cbc/32.png) [@Hansibert](https://forum.shopware.com/u/Hansibert)\
**Post date:** [23. Juni 2020 um 12:30 UTC](https://forum.shopware.com/t/using-services-in-rules/67874/1 "2020-06-23T12:30:28Z")

</div>

Hello

I have created a custom rule. It generally seems to work (admin part is working, I get the right config from admin, the rule is constructed and `match` is called). Nice!

For the evaluation of my rule (the implementation of `match`) I need to use some services (services from my own plugin, the config of my plugin, some repositories, …). How can I get those services?

- **Injection in ` __construct` with „services.xml“ does not work!** Yes, I receive the services as arguments to `__ construct` but the `private $someService` variables are overridden somewhere after having been set in the constructor. Maybe this happens somewhere in the core where the values from the config form in the admin are set. All these variables are `null` when `match` is executed even though I set them to a non-`null` value in the constructor.
- **`$this-\>container` is not defined.**

The following snippet illustrates what I am trying to do:

```
class DemoRule extends Rule {

	/**
	 * @var int
	 */
	protected $myInt;
	
	private $someService;
	
	public function __construct(SomeService $someService) {
		$this->someService = $someService;
		// Here `$this->someService` is defined.
		// `$someService` really is an instance of
		// `SomeService` and not `null` (as requested in
		// "services.xml").
	}
	
	public function getName():string {
		return 'some_name';
	}
	
	public function match(RuleScope $scope):bool {
		// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
		// `$this->someService` is now `null`.
		// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
		
		// Did something weird happen when `$this->myInt` was
		// magically set?
		
		return false;
	}
	
	public function getConstraints():array {
		return array(
			'myInt' => array(new Type('int'))
		);
	}
}

```

Maybe there is some last-resort way of obtaining a service instance (something like `Shopware()-\>Container()`)?

My questions: How can we use services in a custom rule (e.g. how do we get our plugin config, repositories and custom services)?

---

<div class="post-metadata">

**Author:** ![Almare](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@Almare](https://forum.shopware.com/u/Almare)\
**Post date:** [27. Juli 2020 um 12:18 UTC](https://forum.shopware.com/t/using-services-in-rules/67874/2 "2020-07-27T12:18:46Z")

</div>

You don’t have access to the container nor the services. This part of the rule builder design. You can only use the already provided variables to make a decision (false/true).

---

<div class="post-metadata">

**Author:** ![Hansibert](https://avatars.discourse-cdn.com/v4/letter/h/8e8cbc/32.png) [@Hansibert](https://forum.shopware.com/u/Hansibert)\
**Post date:** [3. August 2020 um 09:33 UTC](https://forum.shopware.com/t/using-services-in-rules/67874/3 "2020-08-03T09:33:53Z")

</div>

> [@Almare schrieb:](https://forum.shopware.com/profile/10657/Almare "Almare")
> 
> You don’t have access to the container nor the services. This part of the rule builder design. You can only use the already provided variables to make a decision (false/true).

That is exactly the problem!

E.g. we can’t access the plugin configuration, we can’t access information from the DB because we can’t inject/fetch a repository (e.g. own associations will not have been added to the customer/address, whether some historic data is present is a pure question of luck), we have to repeat all the calculation code because we can’t access our own services, we can’t even write anything to the log, …

Only the simplest of rules could be implemented like that (it seems the Shopware authors thought of the rules they were going to implement before they decided which data to make available; of course it works then…). And all of it seems to be due to some relatively minor implementation issues in the core. I have create an issue for this: [Shopware Issuetracker](https://issues.shopware.com/issues/NEXT-9347). It’s in the „Backlog“, maybe some day we can write serious risk management rules without resorting to dirty tricks.

&nbsp;