Hi @InfFilipV welcome to IFS Community.

For your problem no 1 you can use below format in CIFX file. Remember to define this in each and every installation in the CIFX. The problem 3 looks like a bug to me. Have you tries reaching IFS support?

    <LANGUAGES>
      <LANGUAGE>
       <LANGUAGE_CODE>cs</LANGUAGE_CODE>
      </LANGUAGE>
      <LANGUAGE>
       <LANGUAGE_CODE>en</LANGUAGE_CODE>
      </LANGUAGE>
      <LANGUAGE>
       <LANGUAGE_CODE>es</LANGUAGE_CODE>
      </LANGUAGE>
      <LANGUAGE>
       <LANGUAGE_CODE>nl</LANGUAGE_CODE>
      </LANGUAGE>
      <LANGUAGE>
       <LANGUAGE_CODE>pl</LANGUAGE_CODE>
      </LANGUAGE>
     </LANGUAGES>

Thanks.

Hi @InfFilipV, 

Regarding point #3:
We have the same problem and it is quite annoying.
Have you managed to find a solution?

regards

Janos

Hi @jasahu,
unfortunately no.

But, we had this issue also in delivery process, sometimes Ext was not loaded and dynamic dependency modules was not loaded very often.

Solution Developer before delivery checkout deploy.ini from harvest, and because there is problem with not downloading GET files, it ignore them and use Core one from Archive.

So we check-in GET version of deploy.ini into _STD package and it helps (or we manually adding this deploy.ini files as ManualInsertFile to the delivery - and before build changing build from fresh to up-to-date).

This could help also in deploy on local machine.

I spend last year on previous versions where we does not using GET, so I did not try solve this issue.

Only my actual idea without try:

Maybe checkout of GET deploy.ini into workfolder and making file writable (to avoid rewrite by SD) will help.
 

Filip

Hi @InfFilipV ,

I understand, it does not look that good :)

Recently I created a case on LCS regarding this and in contact with them, progress is not that fast, but hopefully we can solve it:

LCS Case:
G2249983

I am not sure that you have the rights to see that, if not, I will summarize it to you if you are interested

Hi @jasahu,

Finally, I think I found only way to solve this situation like this:
I created Merged archive folder, that contains Core, GET and MEE.
Core subfolder contains only core files, GET subfolder contains GET files on top of Core files and MEE subfolder contains MEE files on top of GET files on top of Core files.

I also created RRC file that contains all three markets.

In CIFX I then use only one record for module with market I need.

For Example:

<MODULE>
   <NAME>ACCRUL</NAME>
   <VERSION>10.0.0</VERSION>
   <MARKET>GET</MARKET>
   <VERTICAL>None</VERTICAL>
   <CPS>11</CPS>
</MODULE>

We are currently testing it on few environments, but I think it’s only way.

Maybe there can be problem if you want use MEE without GET, but now only module where are all three markets is documentation.

BR
Filip

Hi @InfFilipV,

This is good news, thanks, I will consider it when next projects will start.

On the other hand, we got this official answer some time ago (sent you in direct email at that time, August 2021):

The community post is updated and following is the expert advice.

ISD does not support having multiple versions of the same component. It is not intended to be used like that.

In particular with the Global Extension the expectation is that the GET components are not included in the RRC/CIFX file and should also not be fetched from the archive directly. Instead the GET components should be merged and checked into harvest.

An RRC file can contain contain components in multiple archives. This is for example used for the HR components which are in the MEE archive. As the MEE components are all completely new components and there is no overlap this is save to use and this also works OK in ISD. Only when having the same component in both Core and another Market/Archive then it is not supported.

Hope the explanations are clear for you, we have to adjust with this design scope and this is the final solution from the IFS RnD.

You can refer the article from here:

https://community.ifs.com/ifs-methods-and-tools-238/isd-doesn-t-support-extension-rrc-locations-12335?postid=46521#post46521

Kindly note I will be closing this case now and please raise a case if you need any further issues.

Many Thanks,

Asanka Francis.

IFS Support.

 So according to the above, in two recent projects, we put all GET and MEE into Harvest and it works fine.

But I will check your solution next time too, because that would be the best.

Summarized answers/solutions:

1. Right format of languages in CIFX file is this:

   <LANGUAGES>
      <LANGUAGE>
         <LANGUAGE_CODE>en</LANGUAGE_CODE>
         <CLIENT>true</CLIENT>
      </LANGUAGE>
      <LANGUAGE>
         <LANGUAGE_CODE>cs</LANGUAGE_CODE>
         <CLIENT>true</CLIENT>
      </LANGUAGE>
      <LANGUAGE>
         <LANGUAGE_CODE>de</LANGUAGE_CODE>
         <CLIENT>false</CLIENT>
      </LANGUAGE>
   </LANGUAGES>

   For APP10 languages should be also in Order/Config File:

   [languages]
   en
   cs
   de
   [components]
   wrksch 8.0.0;12
   ...

2. It looks like it doesn’t matter on this configurations
3. CIFX (and maybe also Order/Config file) should contains only one record per “Module Name”.
   So never:

   <!-- Bad! Do not use this way -->
   <MODULE>
      <NAME>FIXASS</NAME>
      <VERSION>10.0.0</VERSION>
      <MARKET>GET</MARKET>
      <VERTICAL>None</VERTICAL>
      <CPS>12</CPS>
   </MODULE>
   <MODULE>
      <NAME>FIXASS</NAME>
      <VERSION>10.0.0</VERSION>
      <MARKET>Core</MARKET>
      <VERTICAL>None</VERTICAL>
      <CPS>12</CPS>
   </MODULE>

   But only one of them:

   <MODULE>
      <NAME>FIXASS</NAME>
      <VERSION>10.0.0</VERSION>
      <MARKET>GET</MARKET>
      <VERTICAL>None</VERTICAL>
      <CPS>12</CPS>
   </MODULE>

    

   <MODULE>
      <NAME>FIXASS</NAME>
      <VERSION>10.0.0</VERSION>
      <MARKET>Core</MARKET>
      <VERTICAL>None</VERTICAL>
      <CPS>12</CPS>
   </MODULE>

   Solutions:

   1. IFS expectation: components differ than Core should be merged and checked into harvest.
   2. My solution: merge Archives to one, so harvest will be smaller and there is no need of checking files on every UPD, only standard Conflict solving in process of Update analysis. 
      Script for merge is attached

Thanks to @Amila Samarasinghe  and @jasahu