ssossossosso

Forums

Covering OroCRM topics, including community updates and company announcements.  Subscribe

Open-Source CRM software Forums OroCRM OroCRM – Programming Questions Relation OrderDenormalizer & DateTimeNormalizer

This topic contains 4 replies, has 2 voices, and was last updated by Jaimy Jaimy 2 years ago.

  • Creator
    Topic
  • #8400
    Jaimy
    Jaimy
    Participant

    Hi fellow Oro’ers,

    I’ve been trying to get a grasp at the ImportExport and Integration bundle for a new entity which I need to import from a Magento instance. So far the data is coming correctly to our OroCRM install and it will go through the processor and so on… But, the Denormalizer which I’m using should use a DateTimeNormalizer, since there is a datetime field. Oro has provided a nice serializer for it, the DateTimeNormalizer, but it will fail to process the datetime field since the field is not being imported as the DateTime::ISO8601 format.

    Since OroCRM has the ability to import orders, which also has datetime fields I’m trying to recreate the same for this entity. Unfortunately the normalizer which I try to use for the datetime normalization is not being used, instead the default is being used and will throw an error at me.
    The error is “Invalid datetime “xx”, expected format Y-m-d\TH:i:sO”. I do understand why this error is thrown, but what I can’t figure out is how I suppose to “overrule” the default DateTimeNormalizer. I did however register my custom datetime normalizer as a tagged service with “oro_importexport.normalizer” as a tag.

    From the logging I did I see the following:

    • The custom DateTimeNormalizer and the custom EntityDenormalizer are in the Normalizers array
    • The custom DateTimeNormalizer is being initialised but the “denormalize” method is not being called
    • The custom DateTimeNormalizer returns a 1 (true) for “supportDenormalization”
    • The ConfigurableEntityNormalizer (I’ve extended this one, like the OrderDenormalizer) sees that there is a datetime field and than will use the default DateTimeNormalizer

    The question is that I don’t see anything in particular which hints how the OrderDenormalizer is using the OroCRM DateTimeNormalizer instead of the default, does anyone know what and where this is happening? I’ve being trying to figure this out for a few days and cannot seem to find the answer :<.

    Thanks in advance!

    Kind Regards,

    Jaimy Casteleijn

Viewing 4 replies - 1 through 4 (of 4 total)
  • Author
    Replies
  • #8406
    Dmitry Khrysev
    Dmitry Khrysev
    Oro Core

    Hi, Jaimy

    ImportExport bundle extend default DenormalizerInterface and NormalizerInterface. In extended supportsDenormalization and supportsNormalization was added one more parameter $context which is import-export context. You can add some specific check in your custom normalizer to prevent it from normilizing-denormalizing values in context other than you import. As example take a look at OroCRM\Bundle\MagentoBundle\ImportExport\Serializer\Normalizer\DateTimeNormalizer

    All normalizers are ordered by priority DI tag parameter from higher to lower. If default DateTimeNormalizer “answers” earlier just increase priority of your custom normalizer.

    #8408
    Jaimy
    Jaimy
    Participant

    Hi Dmitry,

    Thank you for your answer. I understand what you are saying I think, but to clarify if I understand correctly:

    You are saying the OroCRM\Bundle\MagentoBundle\ImportExport\Serializer\Normalizer\DateTimeNormalizer is being called only because there is an exception for it for the ‘orocrm_magento’ processorAlias and because the field of the Order/Customer etc.. is a DateTime field?

    I’ve spend the weekend rewriting the connector (it was based on OroCRM 1.1) and it works with the custom DateTimeNormalizer. So I think we’re in the clear right now.

    Could you please confirm the clarification as mentioned above?

    Thanks in advance.

    Kind Regards,

    Jaimy Casteleijn

    #8409
    Dmitry Khrysev
    Dmitry Khrysev
    Oro Core

    Yes, right. Seems in your case you have another processorAlias and Magento’s DateTimeNormalizer was not used. You can extend it and rewrite supports* methods for your case.

    #8410
    Jaimy
    Jaimy
    Participant

    Hi Dmitry,

    I think I understand now thank you very much. It took some time to understand how the serializers were connected to each other and your explanation makes it clearer. Thanks!

    Kind Regards,

    Jaimy Casteleijn

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.