Answer the question
In order to leave comments, you need to log in
What is the best way to dynamically generate models from C # in 1C?
Our project is growing and we are redoing the architecture.
We sell digital products.
We have the generation of these products in PDF where everything is tied to and there is 1C where you need to enter sales data with the same fields. I am not a 1C specialist, I was provided with a SOAP endpoint and documentation, where xml models in Cyrillic appear in requests. At first, everything was fine, we manually compiled models from the product aggregate through XDocument, generated xml and sent it to the endpoint, and also made up a model for PDF generation from this aggregate by replacing words in the template. Now we want to kill two birds with one stone, how to dynamically generate both those and those models. If everything is simple with the PDF part, then 1C with Cyrillic kills the most.
As a result, a few ideas came up:
1. Record paid orders in the database and simply transfer the IDs of paid orders to 1C, and 1C on its side will take paid orders from the database of the mapping model.
Pros:
- everything is encapsulated in 1s and Cyrillic hell is hidden from us
- development is faster, we just put it in the database and pull 1C
Cons:
- Not dynamically. For each product in 1C, you will have to manually prescribe the mapping logic.
2. Make it modular, for each product create a class library with mapping for 1C and frame it with an interface.
Pros:
- For each product in 1C, you will NOT have to manually prescribe the mapping logic.
Cons
- this responsibility is shifted to us and again there is no dynamics
3. Write a configuration for each product with field mapping
{
"PayDate" : "ДатаОплаты",
"RentPrice" : "СтоимостьАренды"
...
}
Answer the question
In order to leave comments, you need to log in
To be honest, I don't see a problem with using Cyrillic as classes in C#. It works, although it does not look very good (well, beauty is a subjective concept).
If you recommend one of their options - I would choose the third option. Why - in my experience, it is difficult to start up in 1C and all gestures there are very costly (paying for a specialist if he is not on staff, response time to a task in general, debugging interaction - you may have out of sync in time and problems of joint launch of integration tests etc.).
The third option is good because you can do both a manual mapper and a mapping on a structured document (json, xml, etc.). I don't think it will be particularly difficult, even with nested models.
This option will allow you to respond much more quickly to possible nuances, and, which is also important, the rules of the Transform part can also be made in the form of a page where they can be affixed to an ordinary employee, without involving a programmer.
Of course, everything I wrote is based on my guesses and, perhaps, all this is not required. But, this option gives you the most freedom in the future, I think.
ps
Again, a customization option on your side may allow you to use the Automapper view libraries, for example - but there, most likely, only through code generation.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question